1

Rapport projet de synthèse

Supervision de réseau ferré
Équipe : NEKER Dimitri, ROZANE Driss, HAMITI Sofiane,
DEMRI Amir, DOUCOURE Oussy

Rapporteur : LORANDEL Jordane

Tuteur technique : GRIGNON Romuald

Encadrant gestion de projet : LIU Tianxiao

Année: 2018/2019

2
Remerciements
Nous adressons dans un premier temps un grand remerciement à notre tuteur
technique, Monsieur ​Romuald Grignon pour le temps consacré à nous aider et à nous
accompagner au sein du projet. Sans compter ses conseils, solutions techniques et outils
de gestion de projet qui nous ont été bénéfique à travers notre parcours et qui le seront
pour la suite. Il nous a permis de bien dégager toutes les contraintes et obligations liées
au développement. Et de pouvoir mettre en place un processus optimal dans le cadre
d’un projet informatique tel que le nôtre.

Nous remercions également en particulier notre encadrant de gestion de projet, le

Professeur ​Liu Tianxiao​, pour son suivi régulier et ses conseils tout au long du projet. Il
nous a aidé à assurer une bonne gestion de projet.

Sans oublier l’entreprise « L’Atelier du train » qui nous a renseigné les informations
importantes à prendre en compte dans un contexte de réseau ferroviaire afin de
démarrer le projet avec un maximum de certitudes.

Nous adressons un remerciement particulier à Monsieur ​Jordane Lorandel notre

rapporteur qui a pu nous apporter des réponses et qui s’est montré disponible et réactif
à nos questions.

Nous sommes aussi redevables à Madame ​Maryse Zindovic et ​Zinedine Galouz dans la
rapidité et gestion de nos commandes. Et nous remercions Monsieur ​Ghiles Mostafaoui
pour la participation à la soutenance finale.

Enfin je tiens à féliciter les membres de l’équipe pour leur implication, leur patience et
leur bonne humeur collaborative. Et l’ensemble des membres, professeurs, élèves qui se
sont impliqués de près ou de loin dans notre projet.

Ce fut pour nous un grand plaisir de travailler sur cette véritable expérience de
réalisation et de gestion de projet de grande envergure.

3
 Table des matières

Remerciements 1

Table des matières 2

Introduction 4
Contexte du projet 4
Objectif du projet 5
Mise en scénario 7
Plan du rapport 9

Présentation et spécification du projet 12

Fonctionnalités attendus 12
Conception globale du projet 14
Architecture technique 14
Architecture Logicielle 17
Problématiques identifiées et solutions envisagées 18
Observation architecture du système 18
Environnement de travail 19
Environnement matériel 19
Environnement logiciel 20

Algorithme IA 21
Problématiques identifiées et solutions envisagées 21
Génération topologique 22
Matrices aléatoires et graphes générés 22
Rails d’aiguillage 23
Recherches pour les algorithmes d’IA 25
Recherches pour la génération d’itinéraire 25
Recherches pour l’apprentissage de chemin et prédiction 26
Génération d’itinéraire 27
Choix de l’algorithme 28
Solution personnalisé 29
Apprentissage de chemin et prédiction 29
Première implémentation : Chaînes de Markov 29
Solution personnalisée 30
Implémentations et tests 30
Générations topologiques 30
Algorithmes IA 31

4
Modélisation de la maquette 32
L’art d’un réseau ferroviaire de train miniature 32
Cartographie du système 35
Représentation logiciel de la maquette 37
Tests et Implémentations 38

Acquisition vidéo et traitement d’images 39

Etat de l’art 39
Comparatif des différents protocoles 39
Traitement d’images 40
Démarche 41
Implémentation et tests 41

Mécanismes de liaisons 42
Etat de l’art 42
Première implémentation et tests 42
Gestion des messages 43
Problèmes et solution 44

Produit final 46
Interface simulation 46
Supervision du système 46
Résultat final 46

Gestion de projet 47
Gestion de projet agile 47
Méthode mises en oeuvre 47
Cycle de vie : Planification 48
Gestion des ressources humaines 48
Aspect développement du projet 48
Aspect documentation du projet 48
Analyse, prévision et réparation des risques 48
Gestion des besoins 48

Conclusion et perspectives 49
Conclusion 49
Perspectives 49

Bibliographie 51

5
 Table des figures
Image n°1 : Utilisation du logiciel sur topologie virtuelle 9
Image n°2 : Démonstration et utilisation de la maquette 10
Image n°3 : Fonctionnalités de notre système pour l’administrateur et le superviseur 12
Image n°4 : Schéma explicatif de la vue utilisateur (à modifier ??) 14
Image n°5 : Composants dédiés à la simulation logiciel sur topologie virtuelle 15
Image n°6 : Composants dédiés à la simulation logiciel sur la maquette 16
Image n°7 : Architecture système fonctionnel 17
Image n°4 : Schéma logiciel 18
Image n°9 : listes de tronçons générés via la matrice de graphe 22
Image n°10 : graphe généré depuis la matrice de graphe 22
Image n°11 : SubRail - rail de bifurcation - 1 23
Image n°12 : SubRail - rail de bifurcation - 2 24
Image n°13 : CrossRail - croisement de R1 et R2 24
Image n°14 : CrossRail - Séparation du rail R1 24
Image n°15 : CrossRail - obtention des rails R1a et R1b 24
Image n°16 : CrossRail - obtention des rails R2a et R2b 25
Image n°17 : CrossRail - ajout de la rail central 25
Image n°18 : Représentation d’une chaîne de Markov par sa matrice d’adjacence 27
Image n°19 : Comparatif d'itinéraire : Mise en place de l'environnement 28
Image n°20 : Espace alloué 35
Image n°21 : Alimentation des voies -1 36
Image n°22 : Alimentation des voies -2 36
Image n°23 : Première version du croquis de la maquette depuis le logiciel AnyRail 37
Image n°24 : listes de tronçons générés via la matrice de graphe 38
Image n°25 : Temps d’échange par CTP, TCP et UDP en microsecondes par rapport à la
taille des données de la commande 41
Image n°26 : Placement de la caméra par rapport à la maquette 42
Image n°27 Découpage de la maquette en grille 43
Image n°28 Tracking d’un train de couleur Rouge 43

6
1. Introduction
Dans le cadre du projet et de sa portée, ce document fournit une documentation sur les
caractéristiques, possibilités et limites du projet mais également dans son déroulement
et de ses multiples acteurs. Sans oublier d’apporter une vue sur la gestion et le
management autour du projet : Supervision de réseau ferroviaire autonome.

1.1. Contexte du projet

L’apparition soudaine des objets connectés et le développement de systèmes
autonomes ont grandement modifiés le monde industriel et informatique. Il existe de
plus en plus d’appareils et systèmes comportant des fonctionnalités totalement
automatisées non dépendante de l’apport humain. Au niveau de la mobilité cela s’est
considérablement accru. Les avions sont maintenant capables de réaliser des trajets
complets sans interventions humaines (décollage et atterrissage compris), l’industrie
automobile accentue ses recherches en développement sur cette même idéologie à
savoir la réalisation de la voiture autonome. De plus certaines lignes de métros sont
désormais automatiques et ne comportent pas de chauffeur. Bien évidemment tous ces
systèmes répondent à une exigence de sécurité et fiabilité pour les usagers tout en ayant
pour intérêt d’avoir un apport supplémentaire sur la qualité d’utilisation. En effet un
système automatique se doit d’être sécurisé quelque soit la situation rencontrée ou
événement intérieur et/ou extérieur se déroulant.
Le réseau ferroviaire de France représente un des plus grands réseaux ferrés du monde
et il s’agit d’un des plus efficace en termes de fonctionnalité. Bien que rares, certains
évènements tragiques peuvent arriver comme des accidents à cause de l’erreur
humaine ou d’un dysfonctionnement matériel. Sans compter les problèmes mineurs du
quotidien que peuvent rencontrer les usagers du transport ferroviaire. Le but est donc
d’apporter une solution permettant d’améliorer cela.

Notre équipe est composé de 5 membres répartis en deux parcours complémentaires :

Réseaux et sécurité et Systèmes Intelligents Distribués bien qu’un membre ait poursuit
antérieurement un parcours embarqué. Nous regroupons plusieurs aspects de ce projet
C’est dans ce contexte et dans le cadre du Master 2 que nous avons choisi de réaliser le
projet de réseau ferroviaire autonome qui regroupe plusieurs domaines de
l’informatiques et notions appris au cours de nos deux années en Master. Et qui
nécessite la conjugaison de plusieurs techniques liées à nos enseignements, notamment
au cours des différents ateliers en seconde année de Master. De plus cela nous permet
de travailler sur un domaine qui est en plein essor et dont les actes ont des

7
conséquences directes sur le quotidien des gens. Proposer une idée qui pourrait
améliorer le quotidien des gens serait gratifiant pour nous.

1.2. Objectif du projet

L’intérêt du projet n’est pas de proposer une solution pouvant remplacer ce qui se fait
en termes de mobilité d’un réseau ferroviaire mais de lui apporter plus de sécurité et
d’automatisation. Notre outils logiciel doit donc être capable d’apporter le même
fonctionnement qu’un réseau ferré afin que l’usager ne fasse pas la différence entre le
système non automatisé et celui automatisé. Nous devons garantir une fluidité du trafic
sur toute une topologie applicable et réduire le nombre d’attentes et retards. En prenant
en compte les multiples problèmes extérieurs qui peuvent surgir à tout moment.
Pour cela l’objectif du projet est de présenter une démonstration d’un système
intelligent et autonome qui s’assure des différents facteurs précédemment abordés.

Afin de répondre à cette problématique nous avons découpés à travers un cahier des
charges plusieurs fonctionnalités/parties essentielles (à échelle d’importance
différente). Il comporte tout d’abord des objectifs majeurs.
Avec dans un premier temps la réalisation d’un logiciel de simulation d’un réseau
ferré qui présentera l’intelligence artificielle du système, une capacité de réagir aux
différents problèmes rencontrés avec la possibilité de visualiser le réseau en question et
ses trains et gares, d’accéder aux informations associées à une entité (l’état d’un rail,
train, gare, prédictions d’arrivés et de retards possibles) en temps réels. Cette partie
étant modulaire doit pouvoir fonctionner pour chaque paramètre inséré en entrée de
celui-ci. Le système à pour mission d’être opérationnel pour toute topologie inséré (à
considérer comme étant une maquette virtuelle) et nombre de trains préalablement
définis à l’avance.
Les fonctionnalités associées à cette partie majeure sont les suivants et ont un rôle
précis pour son bon fonctionnement :

● La génération de plusieurs types de topologies de réseaux afin d’apporter un

maximum de possibilités et d’apporter un maximum d’informations pour
pouvoir en tirer plusieurs observations dans le but d’améliorer le système et de
déterminer les paramètres optimaux.

● L’automatisation de la circulation des trains sur les réseaux. Les trains à partir de
leur table de correspondance et d’itinéraires doivent être capable d’exécuter leur
tâche de manière efficace et efficiente sans aucune intervention humaine.

● La gestion des contraintes de temps réels (incidents, trains en pannes, etc…) qui
est déterminant dans l’un des critères, possédé par un système indépendant et

8
 autonome. Nous devons mettre en place un réseau qui réglerait ces incidents
dans la plus grande vivacité tout en ayant peu de conséquence sur l’ensemble du
trafic.

Dans un second temps nous utiliserons une maquette, cette fois-ci réelle et physique.
Cette partie qui représente le deuxième point essentiel du projet a pour but numéro 1
d’illustrer physiquement l’apport de la simulation logicielle précédemment vue. Avec
l’utilisation des méthodes implémentées de la simulation logicielle. Tout en ayant des
contraintes physiques et matérielles se rapprochant un peu plus de la réalité du monde
des réseaux ferroviaires. A savoir l’alimentation des trains, la gestion de leurs vitesses,
les limites d’angles composant un virage et bien d’autres. Nous pouvons considérer qu’il
s’agit de la vitrine de notre logiciel embarqué. Enfin cela offre une démonstration
efficace et réaliste permettant de matérialiser le travail effectué au cours du projet. Les
grandes problématiques reliées sont les suivantes :

● Déterminer quel genre de maquette utiliser. Comment la concevoir et définir les

éléments à prendre en compte dans la conception d’une maquette pour un
réseau ferroviaire miniature.

● L’aspect alimentation des trains qui seront les acteurs principaux du réseau. Cela
nécessite certaines notions électroniques voir électriques.

● L’utilisation d’un protocole de communication avec la maquette physique et

notre simulation logicielle en temps réel qui doit opérer et gérer le bon
fonctionnement de la maquette.

● La fonctionnalité de détection d’un train. Un train doit être identifiable à

n’importe quel moment du côté de la simulation logicielle.

● L’utilisation d’une caméra pour avoir un moyen supplémentaire de repérer et de

suivre des trains sur le réseau.

1.3. Mise en scénario

Le projet met en avant deux points essentiels : une partie axée virtuelle et logiciel d’une
part et une partie réalisation maquette physique. C’est pourquoi nous avons également
décidé de scinder en deux le déroulement de la démonstration de notre projet. Le projet

9
comporte alors plusieurs cas d’utilisations qui seront présentés ci-dessous. Nous avons
pour objectif final de vous présenter deux scénarios ayant une même base commune
tout en étant indépendant l’un de l’autre.
Tout d’abord le scénario n°1 qui présente l’aspect réalisation logicielle, sur la mise en
place d’un réseau ferroviaire autonome à partir de plusieurs paramètres d’entrées.

Image n°1 : Utilisation du logiciel sur topologie virtuelle

Le scénario n°2 représente la vitrine de ce que peut apporter le logiciel en situation réel
soumis à certaines conditions physiques à travers une maquette comportant un réseau
ferroviaire miniature.

10
 Image n°2 : Démonstration et utilisation de la maquette

1.4. Plan du rapport

Le plan du rapport est défini par rapport aux grands axes du projet. Nous présenterons
dans un premier temps une présentation globale du projet à plusieurs échelles dans
lequel seront présentés les aspect structurels et techniques, les différents composants et
leurs interactions les uns des autres (conception fonctionnelle, spécifications, résumé de
notre cahier des charges).
Nous évoquerons par la suite les 4 grandes parties :

● Une partie abordera de la simulation IA : Celle-ci a pour objectif d’expliquer les

fonctionnalités qui permettent le déplacement des trains au cours de la
simulation (à l’aide de plusieurs algorithmes de calcul de cheminements et
d’apprentissage) de manière optimale en prenant en comptes plusieurs
paramètres (topologie) et évènements possibles.

● Une partie abordera de la modélisation de la maquette physique, de sa

conception à sa réalisation et de sa relation avec la simulation IA.

● Un autre axe traitera de l’acquisition vidéo et du traitement d’image réalisé tout

en apportant son utilité de robustesse supplémentaire au système.

11
 ● Le dernier point présentera les différents mécanismes du Servo-moteur à savoir
les protocoles de communications et leurs divers caractéristiques mis en place
entre le cerveau de notre logiciel et ses différents actionneurs.

Pour finir nous présenterons un rendu du produit final sous forme d’images. La gestion
du projet sera détaillée à travers les moyens/outils de management employés, des
différents problèmes rencontrées et de manière général sur l’aventure de l’équipe au
cours du projet. Il y aura également une section de test afin de montrer les différentes
fonctionnalités validées afin de montrer le travail accompli. Pour finir nous conclurons
ce rapport par une conclusion qui portera un bilan du projet « Supervision de réseau
ferroviaire autonome » et ses perspectives d’améliorations. A noter que les sources
auxquelles nous nous sommes servis pour avancer seront répertoriées dans la section «
Bibliographie ».

Le plan de notre rapport se compose tout d’abord d’une partie présentation et

spécification du projet présentant le cahier des charges ainsi que la conception
fonctionnelle du projet. Ensuite vient les quatres grandes parties techniques, et pour
terminer la gestion de projet, suivie par la conclusion et perspectives.

Nous allons faire dans un premier chapitre, une présentation du projet, le

fonctionnement globale des différents modules en schématisant leurs relations. Par la
suite nous aborderons la conception globale illustré par des diagrammes explicatifs. Les
problématiques identifiées et solutions envisagées ainsi que notre environnement de
travail viendront boucler ce chapitre.

Dans la deuxième partie, nous allons nous focaliser sur la Simulation IA, où nous
étudierons les différents les différents algorithmes de calculs du plus court chemins,
ainsi que des algorithmes sur l’apprentissage. Nous allons ensuite effectué des
comparaisons des algorithmes de calculs du plus court chemins pour la génération
d’itinéraire, et de même pour l’apprentissage.

Nous passerons ensuite à la modélisation de la maquette, où nous listerons les

différents éléments de notre maquette miniature dans un premier temps, suivi par sa
conception.
A COMPLETER

Suivra ensuite la partie acquisition vidéo via le réseau, où nous traiterons dans un
premier temps la communication via via le réseau pour les transferts de messages de la
caméra, pour ensuite parler du traitement d’image effectué via la caméra, pour le
tracking des trains par exemples.

12
Dans la dernière partie technique sur les mécanismes de liaisons, nous ferons dans un
premier temps l’état de l’art des différentes solutions, pour ensuite présenter la
première implémentation et tests. Viendra ensuite une présentation de la gestion des
messages, notamment sur les règles de priorités, la complexité des entrées/sorties, ainsi
que sur la communication entre les différents composants du systèmes( Arduino,
Raspberry).

Nous aborderons ensuite le chapitre sur le produit final, où nous présenterons notre
interface simulation, la supervision de notre système, et le résultat final (ou
intermédiaire, car il y aura des évolutions pour la soutenance).

On entrera ensuite dans la partie sur la Gestion de projet où nous parlerons de la

méthode agile appliquer durant le projet, sa mise en oeuvre, notre planification. Ensuite
nous analyserons différents points sur la gestion des ressources humaines.

Nous finaliserons ce rapport par la conclusion du projet, en rappelant les

problématiques abordées, les solutions apportées, ainsi que les résultats obtenus. Une
sous partie de la conclusion sera axée sur les perspectives d’évolutions du projet, et
d’améliorations pour le futur.

13
2. Présentation et spécification du projet
Dans cette section nous allons vous présenter le fonctionnement général de notre
produit à travers plusieurs schémas qui apporteront une vue à différents niveaux du
produit. Il y aura les fonctionnalités répondant aux besoins du projet d’un point de vue
utilisateur avant de vous résumer les détails de sa conception. La partie qui concerne la
conception récapitule chaque module du projet sous un autre angle. Un chapitre détaillé
sur chacun d’entre eux viendra préciser les détails ultérieurement.

2.1. Fonctionnalités attendus

Nous définissons ici un diagramme de cas d’utilisation de notre système dans lequel nos
acteurs identifiés sont un analyste et un superviseur. Le schéma ci-dessous présente
une vue utilisateur, c’est-à-dire que l’on illustrera les actions observables par un
utilisateur selon son statut (qui n’est pas forcément informaticien par exemple) par
rapport au produit.

Image n°3 : Fonctionnalités de notre système pour l’administrateur et le

superviseur

14
Nous avons ici un superviseur qui a une vision globale du système autonome. Il peut
néanmoins interagir avec le système comme gérer le lancement et l’arrêt de la
simulation, sélectionner un trajet pour un train particulier, déclencher des incidents afin
d’observer la réaction du système. Il a accès à toute les données des acteurs du réseau.
Du côté du Data Analyst il a pour but de faire le tri des différents informations tirés des
multiples simulations afin de rechercher les conditions optimales pour le bon
déroulement du système (tout en ayant les mêmes fonctionnalités que le superviseur en
théorie).

Le besoin est de mettre en place une disposition globale d’un réseau de voies ferrées et
l’automatisation des trajets de ses trains.
Dans cette optique, nous avons pour mission de développer un logiciel dédié à la gestion
du réseau, capable de résoudre automatiquement les incidents pouvant survenir, et
donnant également la possibilité de configurer les trajets des trains qui deviennent
alors totalement autonomes et qui sont soumis à notre intelligence artificielle. Les outils
fournis à l’utilisateur sont les suivant :

● Côté matériel :
○ Afin de mieux représenter l’activité réelle d’un réseau de voies ferrées,
nous avons choisi de construire une maquette miniature d’un réseau de
trains.
○ Nous avons également équipé notre maquette d’une caméra pour
identifier les trains du réseau.

● Côté logiciel :
○ L’utilisateur/superviseur qui peut effectuer diverses actions :
■ Veiller au bon fonctionnement du réseau :
● Suivre les incidents pouvant survenir sur le réseau.
● Lancer/Stopper chaque simulations.
● Consulter le journal d’évènements enregistrés par le
système.
■ Superviser le fonctionnement du réseau :
● Définir ou modifier les trajets des trains sur le réseau.
● Arrêter certains ou tous les trains du réseau
● Définir les priorités en cas de croisement de deux trains sur
une voie.
○ L’administrateur ou « Data Analyst »​ pourra :
■ Effectuer diverses opérations sur une base de données regroupant
les informations souhaitées.

15
 Image n°4 : Schéma explicatif de la vue utilisateur ​(à modifier ??)

2.2. Conception globale du projet

Nous avons ici plusieurs croquis qui présenteront notre système sous plusieurs angles.
Nous présenterons ensuite notre architecture technique qui affichera les différentes
parties techniques nécessaires permettant de réaliser les fonctionnalités décrites dans
la première section. Enfin, nous donnerons une architecture logicielle.

2.2.1. Architecture technique

Les différentes fonctionnalités décrites dans la section précédente constituent des
parties bien distinctes les unes des autres. Etant donné la particularité d’avoir deux cas
d’utilisation nous avons déterminés les composants pour chaque cas :

16
 Image n°5 : Composants dédiés à la simulation logiciel sur topologie virtuelle

Les interactions chronologiques entre les composants sont les suivants :

1. On charge une topologie (sous format Json ou Xml) ainsi que les multiples
itinéraires sur le Raspberry Master.

2. Le Raspberry Master peut alors démarrer la simulation du réseau ferré.

3. Le Raspberry Master envoie des commandes aux actionneurs virtuelles (ils sont
intégrés dans un autre Raspberry) qui gèrent le déplacement des trains sur les
voies de la topologie virtuelle.

4. Le réseau est visible en temps réel et les informations reçues de la maquette

(capteurs, caméra, etc…) au Raspberry Master permettent de générer des logs à
stocker dans une base de données. Ces données sont disponibles pour
l’administrateur selon ses différentes requêtes pour son tableau de bord de suivi.

Le schéma suivant concerne le cas n°2 :

17
 Image n°6 : Composants dédiés à la simulation logiciel sur la maquette

Les interactions côtés maquette sont les suivants :

1. On charge la topologie et le nombre de trains (sous format Json ou Xml) se

rapprochant un maximum de la maquette ainsi que ses multiples itinéraires sur
le Raspberry Master.

2. Le Raspberry Master peut alors démarrer la simulation du réseau ferré.

3. Le Raspberry Master envoie des commandes aux actionneurs Arduino (plusieurs

Arduino) gèrent le déplacement des trains sur la maquette miniature.

4. Le réseau est visible en temps réel à travers la maquette et les informations

reçues de la maquette (capteurs, caméra, etc…) seront également accessibles
depuis le Raspberry Master.

Ces composants symbolisent des macro-modules (comportant également des modules)

essentiels au fonctionnement technique du système illustré ci-dessous :

18
 Image n°7 : Architecture système fonctionnel

Le système est composé de 5 macro-modules :

● Le Gestionnaire est chargé du bon déroulement du système. Il concentre

l’intelligence artificielle du système. Il a le rôle de chef d’orchestre.

● L’Actionneur est chargé de répondre aux ordres du gestionnaire (relation

maitre-esclave) et de le renseigner en remontant les différentes informations de
l’état du réseau. Il peut y avoir plusieurs actionneurs.

● La Maquette ou topologie virtuelle constitue quant à elle le terrain de jeu du

gestionnaire et à pour intérêt de respecter au maximum les critères nécessaires
d’un réseau ferroviaire.

● La Supervision constitue le tableau de bord de l’utilisateur. Elle a pour but

d’informer à celui-ci plusieurs types de données du système en temps réel mais
également d’interagir avec le système.

● La Base de données permet de réaliser des statistiques prélevées dans l’optique

d’améliorer au fur et à mesure notre système.
L’architecture technique proposée ici permet d’abord de se focaliser sur les 3 premiers
macro-modules qui permettent à eux seul d’avoir un système opérationnel et
fonctionnel.

19
 2.2.2. Architecture Logicielle

La simulation est dans un premier temps une application indépendante où elle fait
intervenir l’ensemble des composants du système, qui est appliquée sur un système se
basant sur une topologie virtuelle. Elle permet un plus large choix de paramétrage au
niveau circuit des maquettes en créant un trajet avec des configurations variées qui
représentent des cartes pour les trains. Un générateur peut être mis en place pour
faciliter la création de la carte. Il est prévu d’utiliser des algorithmes pour optimiser le
cheminement des trains ainsi que la gestion des priorités entre les trains. La gestion
d’incidents est aussi une partie de la simulation.

Image n°4 : Schéma logiciel

2.3. Problématiques identifiées et solutions envisagées

2.3.1. Observation architecture du système
Lors de la conception du système, certains points de réflexions ont été nécessaires au
bon déroulement du projet. Il a fallu répondre aux problématiques des différents
composants du système :

● La Maquette : il a fallu déterminer comment la concevoir et trouver les matériaux

pour atteindre nos objectifs tout en la reliant à notre simulation logicielle. De

20
 plus cela posait des notions supplémentaires d’ingénieries et électroniques pour
l’alimentation électrique de cette maquette. La solution a été de la relier à
plusieurs actionneurs pour que le chef d’orchestre puisse exécuter ses tâches de
manière transparente.

● Le Gestionnaire : il a fallu déterminer quelles serait le rôle exact du gestionnaire

et analyser ses limites. Sa fonction principale est d’appliquer un algorithme
général regroupant plusieurs algorithmes. C’est pour cela que le gestionnaire
sera représenté par un Raspberry Pi. Un Raspberry peut abriter un logiciel et nos
fonctionnalités. Toutefois la maquette comporte un nombre élevé d’éléments à
traiter et ce nombre n’est physiquement pas supportable par ce Raspberry
(entrées/sorties). C’est pour cela que des composants intermédiaires ont été
placés afin de répondre à ce besoin. il a fallu aussi répondre à la problématique
qui a été dans un premier temps de trouver une façon d’avoir une vision globale
du système et de définir les données que nous voulions mettre à disposition.
Nous avons utilisé une bibliothèque graphique pour cela.

● L’actionneur : c’est ce composant qui devait assurer la liaison entre les deux
composants précédemment cités. Il fallait trouver un moyen de récupérer un
nombre conséquent d’informations sur la maquette à travers plusieurs ports
entrées/sorties. La décision a été d’utiliser plusieurs microcontrôleur Arduino
qui joueront ce rôle. Puis de se demander comment orchestrer les différentes
instructions ainsi que les réceptions d’informations.

● La base de données : Avec la multiplication des capteurs que notre système va

supporter nous sommes confrontés à une génération massive de données et les
questions à se poser sont : quels sont les critères de sélection, comment peut-on
formater ces données, et comment peut-on donner de la valeur ajoutée à toutes
ces données.

2.4. Environnement de travail

Pour notre projet, nous avons dû nous familiariser avec un domaine qui nous n’était pas
très familier, à savoir la conception d’une maquette d’un réseau ferré. Cela a donc
impliqué que nous devions effectuer des recherches sur la composition d’un réseau
ferré, les rails, le système d’aiguillage, les trains, les moyens de communications entre
les arduinos et le Raspberry pi.

2.4.1. Environnement matériel

Au niveau du matériel, nous avons eu besoin de plusieurs choses :

21
Le logiciel ​AnyRail qui est un outil informatique d’aide à la conception qui permet de
planifier des réseaux de chemins de fer miniatures. AnyRail propose la géométrie des
voies de plus de 150 catalogues de fabricants de modélisme ferroviaire miniature
différents. ​(Voir en annexe quelques exemples de réseau ferrés)
Pour les servomoteurs, nous avons réquisitionné trois ​Raspberry pi 3 ​(dont une pour
le traitement d’image de la caméra et l’autre abritant notre modèle de supervision) ​et
plusieurs ​Arduino Uno ​composés de plusieurs entrées et sorties.
Nous avons bénéficié d’une salle de travail où l’on a pu y disposer la maquette, pour
éviter les problèmes liés à l’espace allouée de la maquette sans compter les nombreux
outil, matériaux, composants électronique mis à disposition.

2.4.2. Environnement logiciel

Concernant la partie logicielle, nous avons utilisé plusieurs outils de développement.
Les langages utilisé ont été :
● Java pour la l’interface graphique, nous avons utilisé l’éditeur ​Intellij Idea
● Python pour faire la partie Webcam (Traitement d’image) qui sera utilisé ensuite
dans la maquette physique.
● C pour la communication des Arduino avec les Raspberry

En ce qui concerne la maquette, nous avons utilisé, en plus de ces éditeurs cités
précédemment, ​l’IDE pour arduino ​pour simplifier le téléversement sur la carte.
Lors de la conception du système, certains points de réflexions ont été nécessaires au
bon déroulement du projet.

22
3. Algorithme IA
Dans cette première partie, nous allons tout d’abord vous présenter dans la première
section, les problématiques identifiées et solutions envisagées associées. Puis, à partir
de nos différentes recherches, nous allons vous présenter des algorithmes qui pourront
être utilisé dans notre système. Par la suite, après avoir effectué des comparaisons de
nos différentes solutions, nous allons expliqué notre solution retenue pour la génération
d’itinéraire, ainsi que pour l’apprentissage de chemin et prédiction. Nous terminerons
enfin par exprimer nos challenges ainsi que les solutions qui ont été retenue.

3.1. Problématiques identifiées et solutions envisagées

Cette première partie sur l’algorithme IA sera intégré dans notre Gestionnaire principal,
un Raspberry. En effet, ce Raspberry devra donc contrôler d’un côté notre maquette
physique, et de l’autre côté la simulation.

Avant de pouvoir se lancer sur le traitement des différents algorithmes de traitement

d’itinéraires et apprentissage. Nous devons dans un premier temps définir
l’environnement de notre système, sur lequel sera tester nos algorithmes. Surviennent
donc certaines problématiques, à savoir, comment sera modéliser notre environnement
? De quels types de données avons nous besoins ? Comment générer plusieurs
topologies plus ou moins complexes, en axant une importance sur la rapidité de
génération ?

Après avoir fait le tour des besoins sur la conception de la topologie. Nous pouvons
désormais traiter les besoins algorithmiques au niveau des itinéraires et de
l’apprentissage. Nous nous sommes demandé, quelles seraient les algorithmes les plus
efficaces, c’est-à-dire permettant d’optimiser nos différents besoins pour les modules de
générations d’itinéraires et d’apprentissage ? La deuxième question, est de savoir
comment personnaliser nos algorithmes pour qu’ils puissent passer de la maquette
physique à la simulation plus facilement.

Enfin une dernière problématique est donc de savoir comment quelles seront les
composants de notre algorithme IA, c’est-à-dire les critères, ou contraintes qui seraient
pris en compte dans les calculs (par exemple, calcul du plus court chemin pour un
itinéraire).

23
 3.2. Génération topologique
3.2.1. Matrices aléatoires et graphes générés
Pour la modélisation de notre environnement​, nous avons dans un premier
temps effectuer le stockage des données dans un fichier xml.
Les données insérées ont été généré via une matrice de graphes, qui se présente comme
l’exemple ci-dessous :

Image n°9 : listes de tronçons générés via la matrice de graphe

Les maquettes de simulation obtenues par des matrices symétriques qui sont générées
aléatoirement. Chaque sommets de la matrice représente les gares de notre réseau.
Dans l’exemple ci-dessus, nous avons donc 3 gares 1, 2 et 3, et les liens entre elles.
Toutes les valeurs différentes de 0 indique qu’il existe un lien entre deux sommets du
graphe généré, et donc dans le cas réel que le passage d’une Gare A à une Gare B est
accessible directement sans passer par une autre Gare.
La valeur du lien est une métrique de distance, elle indique le nombre de rail qui sépare
les deux gares. Le graphe généré de la matrice ci-dessus est le suivant :

Image n°10 : graphe généré depuis la matrice de graphe

24
Le graphe ci-dessus représente notre matrice de graphe. On peut donc voir que les arcs
entre les noeuds sont coupés en plusieurs bouts. Ces différentes parties représentent les
rails. Notre réseau comporte donc en tout 20 rails pour cet exemple.
Nous avons définis que les sections comportant un rail de type station possède une
taille fixe de rails, un rail avant et un rail après la rail station. Il ne peut y avoir qu’une
seule station par tronçon (ou section), et nous définissons un tronçon des rails entre
chaque station. Par exemple, entre la gare G1 et G2, nous avons le tronçon n°1 qui
comporte les rails R3, R4 et R5.

Le stockage dans un fichier XML est l’étape suivante de notre processus. En

effet, nous allons y stocker nos différents tronçons, en détaillant les rails associés, ainsi
que les voisins pour chaque rails. C’est à partir de ce fichier que nous allons générer
notre cartographie.

3.2.2. Rails d’aiguillage

Le rails de bifurcation ( SubRails) ​vont permettre de générer 2 chemins différents. En
effet sur ce rail, il y a une entrée R1 et deux sorties R2 et R3 comme on peut le voir sur le
schéma ci-dessous:

Image n°11 : SubRail - rail de bifurcation - 1

Dans notre implémentation, nous avons défini le point de bifurcation (en rouge sur
l’image 12) comme un rail de type SubRail qui sera donc relié à trois rails R1, R2, et R3.

Image n°12 : SubRail - rail de bifurcation - 2

Le point correspond à un rail d’une longueur de 0. Les rails qui sont reliés de manière à
avoir un rail qui possède les rails de départ et les rails pour les arrivées 1 et 2.

25
Les rails de croisement (Cross Rails) ​est un autre type de rails, c’est le croisement
entre 2 rails différents. Le découpage sur ce type de rails s’effectue en plusieurs étapes :

Image n°13 : CrossRail - croisement de R1 et R2

Un rail est récupéré puis séparer en deux sous rails cela veut donc dire que l’on crée
deux nouveau rail.

Image n°14 : CrossRail - Séparation du rail R1

Une fois la séparation effectué sur les rails R1 nous devons effectué le même procédé
pour le rail R2 nous devons préparer un rail central (dit CrossRail) permettant le lien
entre ces 4 rails.

Image n°15 : CrossRail - obtention des rails R1a et R1b

26
 Image n°16 : CrossRail - obtention des rails R2a et R2b

On obtient donc le chaînage ci-dessous. A savoir aussi que comme pour le rail de
bifurcation le rail de croisement à une longueur 0.

Image n°17 : CrossRail - ajout de la rail central

3.3. Recherches pour les algorithmes d’IA

La simulation logicielle est la première partie de notre projet, nous allons y définir la
simulation de notre maquette de réseau ferré. Dans cette simulation nous nous
focalisons principalement sur le côté intelligence artificielle de notre système,
c’est-à-dire l’algorithme qui permettra de gérer les trajets des différents trains en
fonctions d’une multitude de contraintes que nous aurons définis préalablement, ou les
contraintes temps réels.

27
 3.3.1. Recherches pour la génération d’itinéraire
Différents algorithmes pouvant être implémenté pour la génération d’itinéraire, ont des
intérêts plus ou moins important pour une intégration dans une telle simulation.

L’algorithme A* ​fonctionne avec un ensemble de de noeuds et de 2 listes. Une

liste dite ​ouverte qui contient l’ensembles des noeuds n’ayant pas encore été traité, et
une liste ​fermée c​ ontenant les noeuds déjà traités. A partir du noeud de départ, il
cherche tous les voisins et les place dans la liste ​ouverte.​ Le noeud voisin avec le
meilleur score F est lui retiré de la liste ​ouverte puis mis dans ​fermé​. Ainsi de suite
jusqu’à atteindre l’arrivée. Si l’algorithme rencontre un obstacle, il choisira un autre
noeud voisin du noeud actuel qui a le deuxième meilleur score F. Lorsque le chemin est
trouvé, il est reconstruit en partant du noeud final et en cascade, récupérer le noeud
prédécesseur jusqu’au départ afin de ne garder que le chemin de moindre coût.
Le calcul du coût utilise la formule F = G * H où :
● G est la distance totale du point de départ jusqu’à la position actuelle.
● H est une fonction heuristique utilisée pour mesurer la distance du point actuel
jusqu’à l’arrivée.

L’algorithme Dijkstra ​fonctionne comme A* sauf qu’il n’y a pas d’heuristique

entre le point actuel et l’arrivée. Chaque noeud a son score initialisé à 0 au début de la
simulation. A chaque itération, l’algorithme choisit le prochain noeud par le plus petit
coût pour y accéder. Tous les noeuds se valent donc tant qu’il ne rencontre pas
d’obstacles, le recherche se fait tout autour du point de départ. Lorsqu’on avance d’un
noeud, on met à jour son score et stocke le noeud père. Si l’algorithme rencontre un
obstacle, on revient au noeud prédécesseur et choisit à nouveau le noeud avec le plus
petit score. Lorsque l’objectif a été atteint, on effectue une marche arrière pour
récupérer tous les fils du noeud final et on obtient le chemin de moindre coût.
Cet algorithme a été proposé par Dijkstra très tôt mais il est perfectible. En effet, en
ajoutant la notion de calcul d’heuristique (comme en A* par exemple), la direction de
recherche est orientée vers l’objectif et on n’effectue plus une recherche aveugle. On
gagne ainsi en temps et nombre d’exécutions car moins de noeuds doivent être traités.

3.3.2. Recherches pour l’apprentissage de chemin et prédiction

Nous allons présenter les recherches en lien avec ces modules, l’algorithme qui
permettra la réalisation de deux fonctionnalité, l’analyse de chemin favoris, et la
prédiction d’itinéraire.

La chaîne de Markov est une technique permettant d’estimer la probabilité

d’observer un événement dans le futur en observant le présent. Elle se représente par

28
un graphe, où les noeuds sont les différents états et les arcs contiennent l’information
sur les probabilités de transition d’un état à un autre. Les différents états peuvent
représenter les positions possibles d’un utilisateur, et les probabilité de transition sont
calculées à partir des données enregistrées par le serveur. De cette façon, c’est un
moyen d’apprendre via la machine.
Le graphe représentant la chaîne de Markov est représenté sur l’ordinateur via sa
matrice d’adjacence :

Image n°18 : Représentation d’une chaîne de Markov par sa matrice d’adjacence

Les réseaux associatifs (Hopfield) sont un modèle d’apprentissage par la

machine permettant notamment la reconstitution de motifs. Ces réseaux fonctionnent
en 2 temps, d’abord une phase d’apprentissage, puis la phase de reconstitution. Le
réseau est composé de neurones, qui sont représentés en mémoire par un graphe,
comme la chaîne de Markov.
La première phase d’apprentissage consiste à présenter au réseau des motifs complets.
Les neurones qui s’activent en même temps (ceux représentants les parties du motif)
renforcent les liaisons entre eux.
La phase de reconstitution consiste à donner au réseau un motif incomplet, comme une
séquence de position, pour qu’il reconstitue le motif complet, à savoir un chemin. En
utilisant la matrice des poids, on élit à chaque itération le neurone le plus probable de
prendre part au motif. Quand entre 2 itérations il n’y a pas de changement dans
l’activation des neurones, le réseau à alors converger vers le motif connu le plus proche
de la séquence d’origine.

29
 3.4. Génération d’itinéraire
La génération d’itinéraires permet à l’utilisateur (le train) de créer un chemin depuis sa
position vers un point d’arrivée. Sur l’application, il reçoit un tracé qu’il n’a plus qu’à
suivre. La génération se fait grâce à un algorithme de recherche de plus court chemin.
Nous allons comparer les plus connus, A* et Dijkstra ainsi que différentes heuristiques,
et les appliquer à notre application. Après avoir retenu une solution, nous allons
détailler les étapes du choix de l’algorithme et de l’heuristique.

3.4.1. Choix de l’algorithme

Grâce au site PathFinding (​3​) nous avons pu comparer en direct la vitesse d’exécution et
le nombre d’itérations de différents algorithmes de pathfinding ce qui nous a permis de
choisir un algorithme de calcul de plus court chemin.

Image n°19 : Comparatif d'itinéraire : Mise en place de l'environnement

Ce site permet de dessiner son propre schéma avec les obstacles, point de départ( en
vert) et d’arrivée (en rouge). Le schéma représente les proportions exactes des données
réelles récupérées afin de représenter au mieux le comportement de l'algorithme
embarqué dans l'application. Nous avons comparé les algorithmes A* et Dijkstra.

Algorithme Taille du Nombres Commentaires

chemin(en d’opérations
mètres)

30
 A* Manhattan 30 235 Similaire avec la distance
Euclidienne (241
opérations)

Dijkstra 30 380 Performances égales sur

petit schéma mais non
optimal sur grand
schéma, car recherche à
l’aveugle
Les données des mesures du site nous montrent que A* est plus efficace que Dijkstra sur
ce genre de schéma. Les deux algorithmes trouvent le plus court chemin mais en des
temps différents. En utilisant l’heuristique Manhattan au lieu de la distance euclidienne,
on améliore encore le nombre de d’opérations. Même si les nombre d’opérations est
presque identique pour ce schéma, A* sera significativement plus rapide que Dijkstra
pour nos systèmes plus complexes. Au vu de ces résultats, nous avons donc choisi
l’algorithme A* avec la distance de Manhattan en tant que heuristique pour notre
application.

3.4.2. Solution personnalisé

L’algorithme A* choisi sera adapté par rapport au contraintes de notre système, nos
idées d’améliorations pour satisfaire nos besoins.
● les contraintes temps réels (ex : si incidents sur le trajet, comment réagir
rapidement pour éviter blocages)
● prise en compte de la durée des trajets (nombre sur le chemin)
● le coût financier (adapter la vitesse des trains en fonction de leur emplacement
pour un souci de consommation)
● prendre en compte les autres trains sur le parcours
Plusieurs aux contraintes pourront être ajouté à notre algorithme, recherchant au final
l’optimisation des itinéraires pour chaque trains.

3.5. Apprentissage de chemin et prédiction

Cette partie est extrêmement importante dans le projet. Les fonctionnalités apportées
par ce module sont les plus utiles, que ce soit pour l’administrateur ou l’utilisateur.
Le problème identifié dans cette partie est de justifier notre choix d’algorithme utilisé
pour l’apprentissage.
Nous allons donc dans un premier temps, présenter les comparaisons effectuées des
différents algorithmes, à savoir la Chaîne de Markov ​(3) et le Réseau de Hopfield, et par
la suite vous expliquer notre solution retenue.

31
 3.5.1. Première implémentation : Chaînes de Markov
Pour sa simplicité et pour respecter les délais qui nous sont impartis, nous avons choisi
d’implémenter en premier la chaîne de Markov.

En même temps que la création d’un graphe représentant la chaîne de Markov, un

vecteur de distribution initiale modélise les gares les plus sollicités comme départ d’un
itinéraire. Ce vecteur permet, sur le serveur, de créer différents chemins partant de
différentes gares. Nous aurions pu prendre un vecteur de distribution initiale
équiprobable, mais les résultats de l’analyse auraient été moins pertinents.

Pour tester ce module, nous avons lancé plusieurs clients (trains) qui ont chacun généré
des itinéraires. Grâce à l’interface graphique, nous avons pu constater que la
fonctionnalité d’analyse montrait les itinéraires les plus demandés.

3.5.2. Solution personnalisée

C’est la solution choisi à l’heure actuel. Elle se base sur chaîne de markov. ​A compléter

3.6. Implémentations et tests

3.6.1. Générations topologiques
Pour la génération de nos topologies, nous avons donc décidé d’effectuer dans un
premier temps le stockage des données dans un fichier xml, pour ensuite utiliser le
fichier généré pour remplir les cartes.
Deux classes ont donc été créé pour remplir ces deux besoins, ​MapToXml e​ t ​XmlToMap.
Se basant sur le parseur DOM, ces deux classes construisent les bases de stockage à
l’aide des builders, DocumentBuilder pour le fichier XML, et MapBuilder pour le
constructeur map.

● La classe ​MapToXml
Lors de l’initialisation, le noeud racine du fichier XML qui contiendra l’ensemble des
sous noeuds correspondant à chaque type de cellule est créé, en allant du plus grand au
plus petit (maquette, section, rail, neighbor). Les attributs sont ajoutée simultanément
en fonction des identifiants de celles-ci, donc dans l’ordre de parcours du graphe généré.
Par exemple, le noeud ​section ​pour l’immeuble “section” contiendra un “numéro”
d'identifiant unique attribué lors du parcours du graphe.

● La classe ​XmlToMap
Dans l’autre sens, pour générer la map à partir du fichier XML, nous récupérons les
informations en les affectant dans des variables qui serviront de paramètres pour le
constructeur “map”.

32
Par exemple, pour récupérer les informations sur le périmètre d’une maquette, voici le
début de notre méthode :

File​ fXmlFile ​=​ ​new​ ​File​(​"./xml/"+file​);

DocumentBuilderFactory​ dbFactory ​=​ ​DocumentBuilderFactory.​newInstance();
DocumentBuilder​ dBuilder ​=​ dbFactory​.​newDocumentBuilder();
Document​ doc ​=​ dBuilder​.​parse(fXmlFile);

doc​.​getDocumentElement()​.​normalize();

​String​ batiment ​=​ doc​.​getDocumentElement()​.​getNodeName();

​System.​out​.​println(batiment);

​NodeList​ nnList ​=​ doc​.​getElementsByTagName(​"Maquette"​);

​for​ (​int​ temp ​=​ ​0​; temp ​<​ nnList​.​getLength(); temp​++​) {
​Node​ nNode ​=​ nnList​.​item(temp);
​if​ (nNode​.​getNodeType() ​==​ ​Node.​ELEMENT_NODE​) {
​Element​ eElement ​=​ (​Element​) nNode;
nbSections ​=​ ​Integer.​parseInt(eElement​.​getAttribute(​"nbSections"​));
nbStations ​=​ ​Integer.​parseInt(eElement​.​getAttribute(​“nbStations"​));
nbTrains ​=​ ​Integer.​parseInt(eElement​.​getAttribute(​“nbTrains"​));
}
}
​Map​ map ​=​ ​new​ ​Map​(file, nbSections, nbStations, nbTrains);

Le noeud racine “Maquette” possède trois attributs qui sont :

● nbSections ​représentant le nombre total de section que possède la maquette
● nbStations ​représentant le nombre de stations (gares) sur la maquette
● nbTrains ​représentant le nombre de trains sur la maquette.
Ce troisième paramètre varie en fonction de la complexité de la topologie.

En effet pour la génération de notre graphe, nous avons besoin en entrée :

● d’un nombre de noeuds (les stations), qui est générée aléatoirement (ce nombre
est tout de même borné par une taille minimale et maximale)
● les valeurs des arcs (les rails) de la matrice sont également généré de façon
aléatoire
● la matrice obtenue en utilisant les deux paramètres précédents

3.6.2. Algorithmes IA
En cours de développement, à présenter à la soutenance.
Ajout code et explication pour les algorithmes IA

33
34
4. Modélisation de la maquette
La modélisation de la maquette est la première étape de notre projet. C’est la phase qui
représente le cœur du système du côté physique et qui valide le côté fonctionnel de
notre simulation. En effet, les choix opérés pour notre modélisation sont très importants
car ils auront un impact pour la bonne avancée du projet.

4.1. Principales problématiques

Les deux challenges principaux identifiés dans cette partie sont :

● Comment allons-nous représentés notre maquette physique, au niveau de la

cartographie mais aussi sur les éléments la constituant. En effet, puisqu’elle doit
être la plus proche de notre simulation on se posait la question de comment la
mettre en oeuvre sans pour autant avoir des contraintes techniques sur la
maquette physique.simulation

● Comment harmoniser tous les éléments de notre maquette notamment d’un

point de vue spatial on a pas toute la place que l’on veut pour modéliser de
grandes topologies.

En effectuant des recherches de solutions existantes à ce problème, nous allons vous

présentez, dans un premier temps la conception de la maquette et aborder les outils qui
nous ont permis de faire la cartographie de notre maquette. Pour ensuite présenter les
différents acteurs composant de cette maquette. Enfin, nous présenterons les
différentes méthodes permettant à notre intelligence artificielle de s’exprimer
pleinement.

4.2. L’art d’un réseau ferroviaire de train miniature

A propos de la composition de la maquette et pour répondre aux exigences du projet
et de notre élément visuel principal qu’est la maquette, nous avons listé les différents
matériaux/composants de cette maquette : :

● Proposer la présence de plusieurs voies ferrées afin d’avoir une multitude de

possibilités dans notre système et favoriser le fait d’avoir plusieurs trains.

● Un système d’aiguillage toujours dans l’optique d’avoir plusieurs possibilités

rencontrées mais également de pouvoir mettre en œuvre notre intelligence

35
 artificielle sur les changements d’itinéraires (par rapport à la présence d’un
incident ou sur commande d’un administrateur).

● Des trains qui composent nos éléments phare du projet et représenteront les
trains de la vie quotidienne. Et qui pourront avoir une vitesse variable.

● La présence de gares où les trains pourront s’arrêter et repartir en fonction de

leurs destinations.

● La présence de dépôts qui seront les points de départs des trains et d’arrivées en
fin de cycles des trains.

● La présence de capteurs pour détecter la présence d’un train et définir la

position de celui-ci. Nous nous sommes penchées vers deux capteurs de
positions : capteur inductif et capteur par variation de tension.

● Bien évidemment les rails qui composeront notre réseau ferroviaire.

La conception de la maquette présente plusieurs aspects fondamentaux.

Premièrement la question des moyens financiers de ce modélisme. En second temps sur
les coûts en consommation électrique des composants électrotechniques. C’est pour cela
que nous avons pris certaines décisions par rapport à l’économie apporté par tel ou tel
solution.

Ensuite il a fallu identifier l’espace alloué à la maquette (également prendre en compte

les conditions de température, d’humidité et de luminosité) pour traiter les rapports de
réduction dans un décors miniature. Le rapport de réduction du réseau ferroviaire est le
premier paramètre à définir avant toute autre étude. C’est à l’aide de la norme NEM 010
que le rapport de réduction sélectionné a été “H0” car il s’agit du rapport le plus courant
et comportant en conséquence beaucoup de conseils sur son utilisation.

Avec ces rapports de réduction, il est parfois utile d’ajouter un suffixe qui précisera
l'écartement des voies pour une échelle donnée. ​“m” pour la voie métrique et “e” pour la
voie étroite. (Voir annexe n°x)

Il existe deux organismes qui mettent en place des normes en matière de modélisme
ferroviaire. La ​NMRA aux USA et son pendant européen le ​MOROP qui édite les NEM
(Normes Européennes de Modélisme). Ces normes déterminantes, nous ont facilité la
tâche lors de la conception de la maquette.

36
On considère que le travail est confortable jusqu’à 50 cm du bord, difficile de 50 à 60 cm
et virtuellement impossible plus loin, surtout si le travail doit être précis.

Image n°20 : Espace alloué

Les dimensions de la maquette sont donc les suivantes : 120*80 cm.

Concernant l’alimentation des composants de la maquette nous avons décidé d’utiliser

plusieurs composants électroniques. Tout d’abord les rails ont besoin d’être alimenté de
12V minimum c’est pour cela que nous avons décidé d’utiliser un transformateur ​(voir
en référence) ​qui converti la source 220V d’une prise électrique en un de 12V. Pour
économiser l’utilisation électrique de nos systèmes nous avons décidé d’utiliser du
courant dans notre système uniquement sur l’espace occupé par un train. C’est
pourquoi nous avons commandé plusieurs transistors ​(voir en référence) ​qui auront la
fonctionnalité de laisser passer ou non le courant sur une voie.

Nous avons eu deux options concernant les capteurs de positions pour nos trains.
Tout d’abord l’utilisation de capteur de variation de tension ​(voir en référence)​. Il
fonctionne sur le courant généré par le train sur la voie qui va informer le capteur
présent aussi sur la voie. Nous sommes parties dans un premier temps sur ce capteur
mais en raison de son coût et du nombre de capteurs nécessaires nous avons opté pour
l’option n°2.

L’utilisation du capteur par induction ​(voir en référence) ​fonctionne sur la variation

d’un champ magnétique. C’est pour cela que nous avons équipé sous nos trains des
aimants magnétiques qui avertiront la présence des trains aux capteurs.
(Sera rajouté un schéma du train et des aimants magnétique, un schéma sur la
disposition total de la maquette)

L'alimentation des voies​ est analogique. L’utilisation de cantons est donc requise.
Il existe 2 systèmes de rails :

37
 ● Le système "2 rails" comme son nom l'indique, ne comporte que 2 rails fixés sur
des traverses isolantes. C'est le système le plus courant, utilisé par la majorité
des fabricants. Dans ce cas, il existe une tension entre les 2 rails que ce soit en
analogique. Seule la forme du signal varie mais on ne peut absolument pas
court-circuiter les 2 rails. Le système "2 rails" offre plus de réalisme, est moins
coûteux et plus répandu que le système trois rails.

Toutefois, il demande une attention particulière en matière de câblage pour les

aiguillages (pointe de cœur), les boucles de retournement et les ponts tournants
(court-circuit).

Image n°21 : Alimentation des voies -1

● Le système "3 rails" comporte une série de "picots" entre les deux rails.
L'alimentation électrique est totalement différente, les deux rails externes sont
en court-circuit. L'alimentation est connectée entre les "picots" d'une part et les
2 rails de l'autre. Ce système offre une plus grande facilité de câblage mais est
plus coûteux et moins esthétique que le 2 rails.

Image n°22 : Alimentation des voies - 2

38
● l’aiguillage des rails se fera grâce à moteur d'aiguillage PECO PL-11 - Moteur
contrôlé et alimenté par un arduino.

Image n° 23 Aiguillage des rails

39
 4.3. Cartographie du système
4.3.1. Croquis de la maquette
La réalisation de la maquette a été effectué depuis le logiciel ​AnyRail​. Ce logiciel dispose
de tous les éléments nécessaires à la constitution d’un réseau ferroviaire, en effet il est
dédié à ce type de réseau.
Pour constituer notre réseau ferroviaire physique, nous nous sommes inspirés du RER
C, en ajustant les dimensions pour pallier les différentes contraintes tel que :
- Les dimensions restreintes de notre zone de travail (300/150 cm)
- Les angles de virages
L’image ci-dessous présente la première version de notre maquette physique. C’est un
réseau à doubles voies, où les trains circuleront dans le même sens. On peut y voir les
différents tronçons différenciés par des couleurs.

Image n°23 : Première version du croquis de la maquette depuis le logiciel AnyRail

4.3.2. Eléments de la maquette

La maquette est composée de plusieurs éléments qui seront utiles pour le contrôle des
trains via le contrôleur. On retrouve notamment :

● Les rails qui vont former les voies de circulation des trains. Au niveau physique
il y a plusieurs types de rails, des rails longs, flexibles (pour les virages), de
bifurcation ou de croisement.
● Les tronçons​, qui sont composé de plusieurs rails. En effet, les rails de chaque
tronçon sont isolés, ce qui va permettre la gestion des trafics. En effet, le courant
est réparti sur chaque tronçon pour gérer différents événements, comme les

40
 priorités entre les trains, le ralentissement, l’arrêt des trains au niveau des gares,
etc...

Ajouter des images/photos du réseau pour chaque composant de la maquette

!!!! Cette partie est à rajouter sur les différentes sous parties du 4.2!!!!
En parallèle de la maquette physique prévue, nous allons mettre en place des maquettes
dites virtuelle qui pourront représenter des topologies plus complexes. En effet, elles
possèderont les mêmes éléments et communiquera de la même manière que la
maquette physique. Pour ce faire, nous avons, sur la partie logicielle, une application qui
avant de se lancer prend en entrée la carte avec une liste d’itinéraires qui sera chargé
sur l’application. Elle active l’ensemble des composants tel que l’Arduino, les capteurs,
les tronçons ou encore les ports USB qui sont eux aussi simulés.

En ce qui concerne l’Arduino virtuel nous avons décidé pour simplifier la maquette
virtuelle d’avoir un seul Arduino possédant l’ensemble des ports I/O pour tous les
capteurs et tronçons de la maquette. ​(La suite est en cours d’écriture)
Une interface graphique sera là pour visualiser ce qui se passe sur la maquette virtuelle.
!!!! Fin Partie !!!!!

4.4. Représentation logiciel de la maquette

Pour la modélisation de notre environnement, nous avons donc utilisé la méthode de
génération de carte précédemment vu à travers la création d’un fichier xml.
Les données insérées et calqués sur la maquette physique ont été généré via une
matrice de graphes, qui se présente comme suit :

Image n°24 : listes de tronçons générés via la matrice de graphe

41
Les maquette de simulation obtenues par des matrices symétriques qui sont générées
aléatoirement. Chaque sommets de la matrice représente les gares de notre réseau.
Dans l’exemple ci-dessus, nous avons donc 3 gares 1, 2 et 3, et les liens entre elles.
Toutes valeurs différentes de 0 indique qu’il existe un lien entre deux sommets du
graphe généré, et donc dans le cas réel que le passage d’une Gare A à une Gare B est
accessible directement sans passer par une autre Gare.
La valeur du lien est une métrique de distance, elle indique le nombre de rail qui sépare
les deux gares. Le graphe généré de la matrice ci-dessus est le suivant :
(Insérer le Graphe ici)

4.5. Tests et Implémentations

(Les différents test propres à la maquette seront situés ici)

42
5. Acquisition vidéo et traitement d’images
Dans cette section nous allons présenter la partie qui va nous permettre d'acquerire de
l’image sur la maquette à travers le réseau.

5.1. Etat de l’art

L’acquisition de la vidéo nous permettra de situer le train dans la maquette, une caméra
sera placé au dessus de celle-ci afin d’avoir une vision totale. Pour se faire, une caméra
USB HD standard sera utiliser.

Le premier point sur lequelle se poser est de savoir comment relier la caméra sur
notre réseau,
Concernant le transport du flux vidéo, il existe une multitudes de protocoles:

● RSVP (Ressource ReSerVation Protocol) :

utilisé par les applications temps réel pour allouer les ressources nécessaires
au niveau des routeurs situés le long du chemin de transmission .

● RTP (Real-time Transport Protocol):

assure la reconstruction temporelle, la détection de perte, la sécurité et
l'identification du contenu.
Travaille avec le protocole RTCP pour obtenir des feed-back concernant la
qualité de la transmission.

● RTCP (Real-Time Control Protocol):

envoie périodiquement des paquets RTCP envoie des informations sur la qualité
du service délivrée. En association avec RTP.

Le second point est de savoir de quel façon nous allons utiliser l’image de la maquette
et quel méthode de traitement nous allons effectué:

● De savoir si les trains se déplacent sur la maquette.

● Ou encore connaître la position des trains.

● Avoir une certaine identification de chaque train selon un symbole (un QR code
sur les trains par exemple).

43
 5.2. Comparatif des différents protocoles
Le choix technique pour le protocole qui sera utilisé pour notre solution est porté sur le
protocol TCP. L’atout majeur de ce protocole est son utilisation du protocole de
transport TCP est sa fiabilitée.
La transmission TCP est plus fiable, mais plus lente car elle contrôle les erreurs et
maintient l’ordre des données. UDP ne possède pas de mécanisme de contrôle d’erreur,
c’est pourquoi il est moins fiable mais plus rapide dans le transfert de données, mais
dans notre solution la fiabilité des données, autrement dit la fiabilité des positions des
train est primordiale
Parmis les avantages qui nous intéressent dans ce protocole :

● Une interopérabilité entre ​ordinateurs hétérogènes

● Un standard pour la communication inter réseau et particulièrement entre des
réseaux hétérogènes
● Un protocole ​routable

Image n°25 : Temps d’échange par CTP, TCP et UDP en microsecondes par rapport à la
taille des données de la commande.

5.3. Traitement d’images

Une fois que l'acquisition de l’image est faite, vient la partie traitement d’image qui va
permettre de localiser le train en mouvement.

44
 Image n°26 : Placement de la caméra par rapport à la maquette

Une fois que l’image a été acquise, le train sera détecté grâce à sa couleur, puis une
translation de la position des points de l’image va être faite sur la maquette virtuelle.

5.3.1. Démarche

La caméra va avoir une vue d’ensemble sur la maquette elle jouera un double rôle,
d’abord elle détectera la position des train dans la maquette, mais aussi elle nous
permettra de savoir si la maquette a bougé ou non.
● La caméra va avoir quérire les images de la maquette;
● Fixage des points de repères
● Traitement de l’image : détection des couleurs, chaque train sera identifiée par
une couleur;
● Translation des coordonnées pixels, en coordonnées réel de la maquette.
● Envoie des données au RaspBerry via une socket Ethernet TCP.

5.4. Implémentation et tests

Une caméra HD sera fixé au dessu de la maquette, elle servira de soutien aux capteurs
dans la cas où ces derniers sont défectueux.

La différenciation des couleures des trains servira à détecter automatiquement les

tanins présents sur la maquette et à les identifier.
Une fois qu’un train est détecté la position des trains sera traduite en tronçons, par
découpage de l’image en grille.

45
 Image n°27 Découpage de la maquette en grille

Une fois que la l'acquisition de l’image a commencé, nous pouvons détecter les train,
des points de repères seront placés aux bord de la maquette afin de d'anticiper des faux
mouvements de la caméra.

Image n°28 Tracking d’un train de couleur Rouge

46
6. Mécanismes de liaisons
6.1. Etat de l’art
Un servomoteur est un moteur qui permet de produire un mouvement précis en
réponse à une commande externe. Dans notre système deux entités constituent ce
moteur. L’un alliant l'automatisme tandis que le second alliant l'électronique et la
mécanique. La première entité chargé d’envoyer les commandes sont réalisés par un
microcontrôleur. La suivante elle sera représenté par un système chargé d’actionner
électriquement plusieurs acteurs de notre maquette.
Une multitude de solutions pour ces deux systèmes existe : ​RaspBerry, FPGA, Arduino,
gumstix...

Concernant l’utilisation du Raspberry avec les équipements nous nous sommes posés la
question sur quel mode de communication serait le plus adéquat. Pour avoir un
dialogue qui puisse tenir la route nous devons mettre en place un protocole de message
qui puissent être traduit dans un sens comme dans l’autre.

6.2. Première implémentation et tests

6.2.1. Microcontrôleur Master
Afin de répondre au besoin d’avoir un microcontrôleur ayant pour rôle d’envoyer
plusieurs commandes au microcontrôleur Slave et d’abriter un système intelligent. Nous
avons choisi d’utiliser un ​RaspBerry​. Il s’agit d’un système d’exploitation que nous
connaissons et qui pourra abriter notre software. De plus celui-ci pourra amplement
diriger le microcontrôleur Slave. (ajouter les détails techniques d’un RaspBerry par la
suite )

6.2.2. Microcontrôleur Slave

Afin de répondre au besoin d’avoir un microcontrôleur ayant pour rôle d’activer
plusieurs éléments sur la maquette et de récupérer plusieurs informations de celle-ci le
nombre de ports d’entrées/sorties doit être assez élevé. Nous avons sélectionné dans un
premier temps le microcontrôleur ​FPGA qui possède une quarantaine d’entrées/sorties
pouvant abriter du software en langage C. Son nombre d’entrées/sorties conséquent a
été un argument pour sa sélection.
Cependant un problème reposait sur le choix du FPGA, est qu’il fallait avoir une bonne
connaissance sur le langage ​VHDL pour contrôler les éléments de la maquette. La
communication Raspberry-FPGA était un autre point de blocage.
Donc la complexité de cette solution langage nous a orienté à nous pencher sur une
autre solution, qui est l’utilisation de plusieurs ​Arduino. ​Bien que son nombre

47
d’entrées/sorties ​[4] est moins conséquent que le FPGA, son utilisation pour la gestion
des éléments de la maquette ainsi que la communication avec un Raspberry est
néanmoins plus simple.

6.3. Gestion des messages

6.3.1. Règle de priorité
Au cours du lancement de la simulation physique ou virtuelle, les différents
équipements communiquent selon un schéma bien spécifique.
Au niveau des messages:

Qui -> Qui Message LONGUEUR TAILLE (bite)

Arduino -> ID 1 8
Raspberry

Raspberry -> ACT + ID 3 + 1 ou 2 24 + 8 ou 16

Arduino

Raspberry -> STA 3 24

Arduino

Raspberry -> ID? 3 24

Arduino

Raspberry -> STO 3 24

Arduino

Arduino -> CAP + ID 3 24

Raspberry

Arduino -> ID:Liste où 13 ou 16 ou 19 104 ou 128 ou 152

Raspberry Liste= 1-2-3-4-5-6
ou 7-8-9-10-11-12
ou
13-14-15-16-17-18
selon la valeur des
ids

Ce tableau répertorie la liste des messages possibles entre les deux équipements. Il
permet d’observer que même le message le plus long ne dépasse pas 20 octet.

48
 6.3.2. Complexité des entrées/sorties
En ce qui concerne le dialogue entre arduino et raspberry, nous avons mis en place un
système d’accusé réception entre eux. En effet, pour chacun des messages envoyé
depuis l’arduino si le message est reçu alors le raspberry va à son tour envoyé un
message contenant le résultat du message reçu avec une info supplémentaire désignant
si c’est valide ou non.

6.3.3. Communication du Raspberry camera et Raspberry

Master
Le protocole de communication entre le Raspberry relié à la caméra et le Raspberry qui
possède la simulation se fera en communication TCP Ethernet via des sockets

6.3.4. Communication des arduinos et Raspberry Master

Les différents arduinos ont chacun leur propre identifiant.
On explique comment sont générés les messages sur chaque equipements. On donne
l’ordre des informations des messages)

6.4. Problèmes et solution

La première chose, lors d’une communication entre le Raspberry et les Arduino, c’est de
pouvoir les faire communiquer entre eux de façon asynchrones ​[5]:​

● On a donc utilisé des Threads pour isoler chacun des Arduino. Sans Thread la
simulation n’arrivait pas à envoyer tout en recevant les messages des Arduino.

Dans le premier cas nous avons des messages qui ne sont pas tous reçu. Le
problème est lié au message asynchrones.
Par la suite nous avons donc ajouté la partie Thread afin que notre
protocole évite de perdre des messages, du Raspberry vers l’arduino et
vice-versa.

● Nous avons sur chaque arduino un port communication que l’on paramètre
exactement pareil sur l’arduino et l’objet Java.

● Nous utilisons aussi deux méthodes une d’écriture et l’autre de lecture basé sur
l’évènement.

49
La longueur du message nous a fait continué nos tests. Notamment sur ce qui nous était
permis d’utiliser entre le nombre d’octet que l’on pouvait envoyé et la durée d’attente
entre chaque message:
Si nous avons un Arduino possédant une vitesse de transmission 9600, et des messages
dont la taille est égale ou inférieur à 20 octet on obtient un delais de 20 ms par envoie
de message. Or nos messages allant jusqu’à 159 bites soit 19 octets est en dessous de
cette estimation.

50
7. Produit final
7.1. Résultat final
Le produit n’étant pas complètement finalisé, nous présenterons le
produit lors de la soutenance finale. Elle contiendra une interface
graphique, la maquette avec les composants. Lors du lancement, nos train
effectueront leur propre itinéraire et auront le même dans la simulation
que sur la maquette physique.

51
8. Gestion de projet
La gestion de projet a un rôle primordiale dans la réussite d’un projet en générale, c’est
le coeur du travail d’équipe. Cela permet au préalable d’organiser les équipes, les tâches
de chacuns, organiser des réunions, communiquer avec le client, définir un calendrier, et
beaucoup d’autres points tout aussi importants.
Dans cette partie, nous allons vous expliquer comment s’est déroulé la gestion de notre
projet d’une part sur le côté humain, ensuite sur la gestion du temps.

8.1. Gestion de projet agile

Commençons par un retour historique : en 2001 est sorti le manifeste agile, basé sur 4
valeurs, 12 principes, et 1 histoire.
Sur ces 12 principes, on peut déterminer empiriquement 4 axes fondateurs :
● Centré sur l'importance du métier
● Feedback concret et rapide
● Amélioration continue
● Équipe auto-organisée, l'hédonisme, et la responsabilité

La mise en oeuvre de l’agilité dans un projet suscite l’implication de différents acteurs.

Un client ayant un projet métier, une équipe de développeur, et un chef de projet pour
assurer l’encadrement du projet.
Tout au long de la réalisation de notre projet on retrouve ces aspects. Allant de la mise
en place du cahier des charges recommandé par le client (Romuald GRIGNON), passant
par un suivi régulier avec l’encadrant (Tianxiao LIU) afin d’assurer une amélioration
continue du projet, pour arriver à une organisation et un rendu de qualité​.

8.1.1. Cycle de vie : Planification

Explication du tableau des différentes releases et version intermédiaire

Date Release/version Commentaire

intermédiaire

22/02/19 - Génération de Maps (1) : circulation de

trains sur la map
- 1ere interface
graphique

- Première
implémentation(1)

52
22/03/19 - Première (1) : prête à utilisation
implémentation même si la
algo A* maquette n’est pas
- Multi-agent encore prête.

- Traitement d’image
pour la webcam(1)

05/04/19 (1) - Mise en place de la (1): selon l’arrivée du

maquette matériel, la date peut
changer

07/05/19 - Caméra: Identifier

un plan non
orthogonal

- Recherche sur
Transformateurs

24/05/19 - Simulation: Mise en

place d’un objet
arduino avec tous
les entrées sorties
nécessaires

- Maquette:
Attribution
d’identification sur
chaque arduino

- Mise en place du
lien Asynchrone
entre Java et
Arduino

04/06/19 - Modélisation des

CrossRail et SubRail

- Ajout de
fonctionnalité sur
Rails spécifiques

06/06/19 - Maquette: Tests sur

les vitesses des
trains

- Gestion des
collision de

53
 message Raspberry
Arduino

07/06/19

11/06/19 - Soudure à préparer

- Code arduino test
entrée capteur

8.1.2. Méthode et mise en oeuvre

Le projet a été développé suivant la méthode agile, différentes releases sont produites
(voir la section précédente) au cours du temps.

Au début du projet, lors de l’étude des besoins, le cahier de charges commence à être
complété, et c’est ainsi que commence le découpage des parties du projet en petits
ensembles de fonctionnalités donnant naissance à des users stories.

Une user story n’est lancé en production que si le tuteur l’a validée, des réunions sont
fréquemment organisées afin de recenser et de valider un maximum de
fonctionnalitées.

8.2. Gestion des ressources humaines

8.2.1. Aspect développement du projet
Nous avons favoriser le plus possible le parallélisme lors du développement de notre
projet, nous avons fait en sorte de lancer plusieurs tâches en développement afin de
gagner du temps et anticiper les changements.

Comme il y’a un aspect matériel dans le projet, la réception des commandes prennent
un temps considérable. Entre-temps les aspects logiciels sont en développement pour
que le matériel soit directement mis en place.

Au démarrage du projet, nous avons travaillé essentiellement ensemble sans répartition

particulière de tâches. Pour la mise en place de l’architecture du projet et la
modélisation de l’environnement, physique et de la simulation. Aussitôt, du travail en
binôme et monôme pour les différentes fonctionnalitées à été mis en place :

54
 Dimitri Driss Oussy Sofiane Amir

Amir Traitement
d’image

Protocole
d’échange
réseau

Sofiane Développeme Axe

nt algorithme d’utilisation
IA de la caméra

Oussy Gestion du Génération Génération

stock des d’itinéraire de la carte
éléments de Stockage
la maquette. XML

Conception
du réseau
ferré

Gestion
d’incidents

Développeme
nt algorithme
IA

Driss Conception Intégration

logiciel, des classes
Développeme pour la
nt de la simulation
Communicatio
n Traitement
Arduino/Rasp GUI
Berry.

Gestion
d’incidents

Développeme
nt algorithme
IA

Dimitri Gestion de
documentatio
n.
Gestion du
planning.

55
 8.2.2. Aspect documentation du projet
Un projet ne va de soi sans documentation, de la trace écrite permet de tenir le
cheminement et mettre en place les spécifications du projet. Ainsi, un cahier des
charges, un plan d’action, et un plan de démarrage ont été effectué par l’ensemble de
l’équipe.
Le rapport du projet demandant une vue plus interne de la réalisation, chaque membre
s’occupait de la rédaction de sa partie de développement correspondante.

D’autres outils de documentation pour les parties plus techniques ont été également
utilisé, comme :
● Trello qui est un outil permettant d’avoir un suivi précis sur les tâches à venir,
celles effectués et celles qui sont en cours.
● GitLab qui est outils incontournable pour la gestion de projet. Il nous a permis
d’héberger notre projet et la gestion des versions de code sources.

Toutes nos documentations ont été stockés dans google drive partagée à tous les
membres du groupe.

8.2.3. Analyse, prévision et réparation des risques

La réalisation du projet à regrouper un nombre conséquent de métier. Bien entendu

dans un premier temps logiciel, avec la réalisation de notre simulation de maquette.
Ensuite, il y également eu de l’électronique avec la conception de notre maquette
physique, et également du traitement vidéo.
Pour combiner plusieurs métiers, il est primordiale d’avoir une bonne gestion de projet.
Elle a suscité un niveau poussé dans la coordination de l’approche agile, de niveau M2.

La gestion de projet sans les efforts fournis par tous les membres du module n'aurait pu
aboutir au résultat retenu au jour d’aujourd’hui. L’expertise de certains membres nous a
permis d’acquérir des connaissances et des rétrospectives pour une meilleure gestion
de projet.

56
9. Conclusion et perspectives
Le principal objectif est donc d’améliorer l’automatisation et la supervision des trajets
trains et apporter un plus dans la sécurité des réseaux ferroviaires. Le projet utilise
donc différentes techniques et outils permettant la mise en place d’un tel système.
Une multitudes de compétences on étaits sollicitées dans ce projet, réseaux,
informatique embarquée, traitements temps réel, traitements d’images, électronique.

9.1. Conclusion
Sur notre produit final​,
● Les capteurs sont configurés afin de détecter la position exacte des trains pour
suivre leurs mouvements.
● La caméra détecte automatiquement la position des trains dans le cas où les
capteurs sont défaillants et envoyer ces données au superviseur.
● Pour la partie logicielle est composée de trois grands point principaux :
○ Chargement de topologies des façons aléatoire sur le simulateur
○ Algorithme du plus courts chemin implémenté pour que les trains puisse
être autonomes.
○ Communication entre les différents Arduino et le RaspBerry .
● Mise en place d’un protocole de communication pour les échanges de données
entres les Arduino et le RaspBerry.

Ce que ce travail nous a apporté​ sont d'abord des connaissances approfondies au

niveau des réseaux ferroviaires. Notamment comment fonctionnent les trains. Comment
ils sont pilotés vis à vis des itinéraires. Cela nous a donné aussi une monté en
compétences au niveaux des communications maître/esclave entre plusieurs
équipements. Il nous a permis de gagner en compétences dans les aspects du réseaux et
du traitement d’images. On peut mieux appréhender les problématiques d’envoies
comme l’utilisation de délais ou encore dans la taille des messages grâce à une partie
embarquée.

9.2. Perspectives
Ce projet de Supervision de réseau ferré dans sa version actuel pourrait subir des
extension possible. Voici une rapide présentation des différents points d’extension :
● Ajouter l'aspect de pouvoir avancer dans l'autre sens sur des itinéraires données
(du point A au point B peut donc faire de B vers A). Donc il faudrait avoir un
changement d'alimentation sur les voies. Cette partie

57
 ● Au niveau de la caméra nous pouvons décider de rajouter une partie Tracking
sur l'ensemble des trains. Cela veut dire avoir la position de chaque trains en
temps réel.
● Sur la simulation, ajouter plus de paramètres sur la recherche de plus court
chemins afin accroître les performances de l’algorithme et des résultats plus
précis.

Ces extensions, permettront de pouvoir commercialiser notre produit. Par exemple

pour des entreprises comme la SNCF, qui est dans une phase de passage à
l’automatisation et l‘autonomie.

58
 Bibliographie

[1] Maquette - Magasin spécialisé dans la modelisme - 2017

​ ttps://micro-modele.fr/fr/237-ferroviaire
ref - h

[2]L’atelier du train Blog - Vente de trains miniatures -2017

​ ttps://www.latelierdutrain.com/
ref -h

[3]Comparateur algorithme d’itinéraire depôt github - 22 Contributeurs - 2017

​ ttps​://github.com/qiao/PathFinding.js
ref - h

[4] - BLOG POST- ANAT ZAIT , APRIL 22, 2018

​ ttps://www.circuito.io/blog/arduino-uno-pinout/
ref ​ h

[5] - Oscar Liang Connect Raspberry Pi and Arduino with serial USB cable, May 2013
ref: ​https://oscarliang.com/connect-raspberry-pi-and-arduino-usb-cable/

[6] ​Java Threads -

ref - ​https://www.tutorialspoint.com/java/lang/thread_run.htm

[7] Détection de points d’intérêts - Mise en correspondance - UFRIMA - 2015

ref - ​http://devernay.free.fr

[8] Documentation Arduino - 2019

ref - ​https://www.arduino.cc/

[9] Document RaspBerry - 2019

ref - 2019 ​https://www.raspberrypi.org/documentation/

59