Mémoire de Projet de Fin d’Études

Pour l’Obtention du Titre

D’Ingénieur d’État en Télécommunications et en Technologies de

l’Information

Sujet

Conception d’une application de

Diagnostic en ligne des rames automotrices Z2M

Soutenu par : Encadré par :

OUTALB Amal Prof M. El Issati Oussama

M. Talbi Tariq

Année universitaire 2018-2019

 Dédicace

A mes chers parents

A ma chère sœur et mon cher frère
A mes très chers Ami(e)s,
Merci pour votre soutien et votre amour,
Merci à mon école l’INPT qui m’a ouvert largement ses portes
pour bénéficier d’une excellente formation.

1
 Remerciement

Je ne saurais commencer ce rapport sans remercier premièrement mon professeur

encadrant M. El Issati Oussama, pour son encadrement son aide et ses conseils
académiques et personnels tout au long de mon parcours à l’INPT, je serai toujours
reconnaissante monsieur.

Mes remerciements vont également à M. Omar Demmoun, M. Said El khair, M. Talbi

Tariq et tout le personnel de l’ERAC qui m’ont aidé durant mon projet de fin
d’études et qui m’ont fait l’honneur de m’accueillir au sein de l’ERAC.

Je remercie mon école l’INPT pour sa formation de haut niveau, pour l’opportunité
de la mobilité qui m’a offerte, et pour la qualité de vie dedans.

Que tous ceux qui m'ont aidé, de près ou de loin pour réaliser ce projet, veuillez
agréez mes salutations les plus distinguées.

2
Résumé

Dans le domaine ferroviaire comme dans n’importe quel autre type de transport public, la sécurité des
passagers et la qualité du service font la priorité de l’entreprise en charge.

Entretenir cette priorité, est un vrai défi à relever surtout devant les situations de pannes ou avaries
inattendues qui peuvent surgir lors de la circulation des rames.

La maintenance s’impose alors dans ce cas pour remettre la rame en marche et assurer
l’acheminement de son trajet.

Cette situation semble être parfaite et immédiate, or qu’en réalité c’est un cas stressant pour les
responsables de maintenance surtout lorsque les rames sont très distantes de l’atelier de maintenance
et le problème qui a causé la panne n’est pas très clair pour le conducteur qui est sur les lieux.

Pour remédier à ce problème, les responsables de L’ERAC « Etablissement des Rames Automotrices
Z2M de Casablanca» ont proposé l’idée de ce projet qui vise le suivi en ligne de la situation
électromécanique des rames Z2M lors de la circulation.

Le diagnostic en ligne c’est une approche innovante qui se base sur des technologies IoT pour
faciliter la gestion des pannes, et pour la prévention des graves accidents qui peuvent arriver.

3
Abstract

In the railway sector, as in any other type of public transport, passenger safety and quality of service
are the priority of the company in charge.

Maintaining this priority is a real challenge, particularly when an unexpected breakdown occurs
during trains movements.

In this case, maintenance is required to restart the train and to ensure the routing of its journey.

This situation seems to be perfect and immediate, but in reality it is a stressful case for maintenance
managers especially when the trains are very far from the maintenance workshop and the problem
that caused the breakdown is not very clear for the driver who is on the scene.

To remedy this problem, the ERAC managers have proposed this project idea which aims to monitor
online the electromechanical situation of Z2M train sets during traffic.

Online diagnosis is an innovative approach based on the new IoT technologies for managing failures,
and preventing serious accidents that may happen.

4
Liste des abréviations

ERAC Etablissement des Rames Automotrices Z2M de Casa

UCC Unité centrale de commande
US Unité de supervision
UD Diagramme de cas d’utilisation
UGC Unité de Gestion Centrale
MVB Multifunction Vehicule Bus
WTB Wire Train Bus
TCN Train Car Network

5
Listes des figures

1. Organigramme du grand projet

2. Organigramme de l’ONCF
3. Scrum Board
4. Diagramme de Gantt
5. Composants d’une rame Z2M
6. Schéma des dispositifs communiquant via le bus MVB
7. Description matérielle de ce la CCU
8. Arduino Yun
9. Raspberry Pi B3
10. Beagle Bone Black Wireless
11. Capture de la data reçu sur le port série
12. Capture du fichier XML
13. Cloud Computing
14. Les types de services Cloud
15. Les services de Google Cloud
16. Les services associés à Cloud IoT Core
17. Authentification à Google Cloud
18. Processus de déclenchement de Google Cloud Function
19. Capture de la base de données Firestore
20. Architecture de la partie Cloud
21. Architecture d’Android
22. Machine Virtuel Dalvick
23. Cycle de vie d’une activité
24. Diagramme de contexte dynamique
25. UD Globale
26. UD associé à Admin
27. UD associé au Superviseur
28. Diagramme de séquence associé au cas d’utilisation « S’Authentifier »
29. Diagramme de séquence associé au cas d’utilisation « Gestion de la liste des pannes »
30. Diagramme de séquence associé au cas d’utilisation « Consulter la liste des pannes »
31. Diagramme de séquence associé au cas d’utilisation « Consulter la liste des rames »
32. Diagramme de classe globale
33. Interface Authentification
34. Interface Liste des rames
35. Interface Liste des pannes

6
Liste des Tableaux

1. Fiche signalétiques
2. Configuration de la communication série en HyperTerminal
3. Résultat de la première méthode
4. Les caractéristiques principales de l’Arduino YUN
5. Les caractéristiques principales de la Raspberry Pi 3
6. Les caractéristiques principales de la BBB Wireless
7. Type d’équipement selon de code de la panne.
8. Benchmark des solutions Cloud
9. Historiques des versions du système Android
10. Cas d’utilisation selon chaque acteur
11. Description des cas d’utilisation de l’acteur Admin
12. Description des cas d’utilisation de l’acteur Superviseur

7
Tables des matières

Dédicace ............................................................................................................................................................................ 1
Remerciement................................................................................................................................................................... 2
Résumé.............................................................................................................................................................................. 3
Abstract ............................................................................................................................................................................. 4
Liste des abréviations....................................................................................................................................................... 5
Listes des figures ............................................................................................................................................................... 6
Liste des Tableaux ............................................................................................................................................................. 7
Introduction générale ..................................................................................................................................................... 10
Chapitre I : Contexte général du projet...................................................................................................................... 12
1 Introduction ............................................................................................................................................................ 13
2 Présentation de l’organisme D’accueil ................................................................................................................... 13
2.1 Historique........................................................................................................................................................ 13
2.2 Le réseau ONCF ............................................................................................................................................... 13
2.3 Activités ........................................................................................................................................................... 14
2.3.1 Chiffre d’affaires...................................................................................................................................... 14
2.3.2 Transport de voyageurs .......................................................................................................................... 14
2.3.3 Transport de marchandises .................................................................................................................... 14
2.4 Fiche signalétiques .......................................................................................................................................... 14
2.5 Organigramme de l’ONCF ............................................................................................................................... 15
3 Présentation du cadre général du projet ................................................................................................................ 16
3.1 Problématique ................................................................................................................................................ 16
3.2 Démarche et Planification............................................................................................................................... 16
3.2.1 Introduction ............................................................................................................................................ 16
3.2.2 Scrum ...................................................................................................................................................... 16
3.2.3 Planification du projet............................................................................................................................. 17
Chapitre II: Extraction des données diagnostiques ................................................................................................... 19
1 Introduction ............................................................................................................................................................ 20
2 Description fonctionnelle des rames automotrices Z2M........................................................................................ 20
2.1 Train Communication Network (TCN) : ........................................................................................................... 20
2.2 Description matérielle de la CCU .................................................................................................................... 22
2.3 Description logiciel de la CCU ........................................................................................................................ 23
3 Extraction des données ........................................................................................................................................... 23

8
 3.1 Spécification des besoins ................................................................................................................................ 23
3.2 Méthodes d’extraction ................................................................................................................................... 23
3.2.1 Procédure de téléchargement des données par la fiche de mémoire ................................................... 24
4 Traitement des données ......................................................................................................................................... 29
5 Conclusion ............................................................................................................................................................... 30
Chapitre III : Transmission des données au Cloud .................................................................................................... 31
1 Introduction : .......................................................................................................................................................... 32
2 Cloud Computing :................................................................................................................................................... 32
2.1 Définition et généralités : ............................................................................................................................... 32
2.2 Les Services Cloud : ......................................................................................................................................... 34
2.3 Méthodes de déploiement : ........................................................................................................................... 36
3 Les fournisseurs Cloud, Benchmark, et choix de la solution : ................................................................................ 37
3.1 Les fournisseurs Cloud : .................................................................................................................................. 37
3.1.1 Amazon Web Services : ........................................................................................................................... 37
3.1.2 Google Cloud Platform : .......................................................................................................................... 37
3.1.3 Microsoft Azure :..................................................................................................................................... 38
3.2 Benchmark des solutions : .............................................................................................................................. 38
3.3 Choix de la solution: ........................................................................................................................................ 40
3.3.1 Google IoT Core :..................................................................................................................................... 40
3.3.2 Cloud Pub/Sub :....................................................................................................................................... 42
3.3.3 Cloud Functions :..................................................................................................................................... 42
3.3.4 Firebase : ................................................................................................................................................. 43
3.3.5 Firestore : ................................................................................................................................................ 44
3.4 Architecture général de la partie Cloud .......................................................................................................... 45
4 Conclusion : ............................................................................................................................................................. 45
Chapitre IV : Conception et Réalisation d’une application mobile .......................................................................... 46
1 Introduction ............................................................................................................................................................ 47
2 Présentation d’Android ........................................................................................................................................... 47
2.1 Définition............................................................................................................................................................... 47
2.2 Architecture .......................................................................................................................................................... 48
2.3 Les applications Android : ..................................................................................................................................... 50
2.3.1 Etats d’une activité......................................................................................................................................... 50
2.3.2 Cycle de vie d’une activité sous Android....................................................................................................... 51
3 Spécification des besoins ........................................................................................................................................ 53
3.1 Les besoins fonctionnels ................................................................................................................................. 53
3.2 Les besoins non fonctionnels .......................................................................................................................... 53
9
4 Analyse des besoins : .............................................................................................................................................. 54
4.1 Identification des acteurs :.............................................................................................................................. 54
4.2 Modélisation du contexte : ............................................................................................................................. 54
4.3 Diagrammes des cas d’utilisation ................................................................................................................... 55
4.3.1 Identification des cas d’utilisation .......................................................................................................... 55
4.3.2 Diagramme de cas d’utilisation global .................................................................................................... 56
4.3.3 Diagrammes de cas d’utilisation détaillés: ............................................................................................. 57
5 Conception .............................................................................................................................................................. 59
5.1 Diagrammes de séquences des cas d’utilisations : ......................................................................................... 59
5.1.1 L’authentification .................................................................................................................................... 60
5.1.2 Gestion de la liste des pannes:................................................................................................................ 61
5.1.3 Consultation des pannes : ....................................................................................................................... 62
5.1.4 Consultation des rames: ......................................................................................................................... 62
5.2 Diagramme de Classe ...................................................................................................................................... 63
6 Réalisation et développement ................................................................................................................................ 64
6.1 Environnement de développement ................................................................................................................ 64
6.2 Langages de développement .......................................................................................................................... 64
6.3 Services Cloud : ............................................................................................................................................... 65
6.4 Les interfaces du système : ............................................................................................................................. 66
7 Conclusion ............................................................................................................................................................... 67
Conclusion générale et perspectives .............................................................................................................................. 68
BIBLIOGRAPHIE ............................................................................................................................................................... 69

10
Introduction générale

Le secteur du transport ferroviaire constitue un facteur essentiel pour le développement économique et

social du pays. Ce secteur doit alors se développer et s'adapter aux mutations socio-économiques qui
résultent du développement général du pays.

Il est donc essentiel de l’innover de telle sorte à bénéficier des services offertes par l’intelligence
artificielle et les technologies récentes de digitalisation.

Ce projet fait partie d’un grand projet lancé par l’ERAC : « Smart Mobile Workshop 1.0 », qui a pour
objectif de rendre l’atelier, un atelier intelligent qui prend en considération la sécurité des mouvements et
des opérateurs intervenants et le suivi électromécaniques en ligne des rames en circulation.

Le présent rapport détaille le travail réalisé lors de ce projet. Il comporte quatre chapitres. Le premier
définit le contexte général du projet, à savoir une présentation de l’organisme d’accueil, le contexte
général du projet et sa planification. Le deuxième chapitre décrit la partie extraction, filtrage et traitement
des données de diagnostic. Dans le troisième chapitre, nous élaborons les différentes phases de l’envoi de
la data au Cloud. Finalement, dans le quatrième chapitre, on s’intéressera à la conception et à la
réalisation d’une application mobile Android pour la visualisation des données diagnostiques prélevées.

Figure 1 : Organigramme du grand projet

11
Chapitre I
Contexte général du projet

Le but de ce chapitre est de présenter le contexte général du projet, qui est réparti sur trois
sections. La première concerne la présentation de l’organisme d’accueil du projet de fin d’études.
La seconde section présente le projet dans son contexte plus spécifique, il en cite la
problématique et les objectifs. Et la troisième qui traite la conduite de projet, en présentant dans
un premier temps le processus du développement puis la planification.

12
Chapitre 1 : Contexte général du projet

1 Introduction
Le transport ferroviaire est aujourd’hui devant un vrai challenge de restructuration afin de mieux
s’adapter aux besoins des clients et du personnel. Ce projet de fin d’étude est un pas vers cet objectif. Il a
pour mission de mettre en place un système de diagnostic en ligne des rames automotrices Z2M pour le
suivi d’état à distance et la prévention des graves accidents. Ce chapitre présente le contexte général du
projet.

2 Présentation de l’organisme D’accueil

« L’Office national des chemins de fer (ONCF) est un établissement public marocain chargé de
l'exploitation du réseau ferroviaire du pays sous forme d'une entreprise publique à caractère commercial
et industriel avec autonomie financière. » Wikipedia.

2.1 Historique
Historiquement, la construction du réseau des chemins de fer du Maroc remonte au début du 20ème
siècle. En effet, dès 1911 l’autorité militaire fût conduite à construire les premières lignes de chemins de
fer au Maroc pour assurer ses propres transports en voie de 0,60m. Ces voies de 0,60m furent ouvertes au
trafic public le 27 Mars 1916.

A partir de 1923, la construction des voies à écartement normal (1,435m) et leur ouverture à
l’exploitation entraînèrent la disparition des voies de 0,60m qui leur étaient parallèles. La gestion des
nouvelles voies a été confiée à trois compagnies concessionnaires privées. Ces dernières se partagèrent le
trafic ferroviaire, en exploitant chacune la partie du réseau qui lui était concédée jusqu’en 1963, lorsque
le Gouvernement Marocain a décidé le rachat des concessions et la création de l’Office National des
Chemins de Fer (ONCF) par DAHIR n° 1-63-225 du 05 Août 1963.

2.2 Le réseau ONCF

L’ONCF est placé sous la tutelle technique du Ministère du Transport et de la Marine Marchande ainsi
que sous la tutelle financière du Ministère des Finances.

L’office gère et exploite un réseau de 3 657 km de voies ferroviaires dont 2 238 km sont électrifiées. Les
3 657 km de voies sont toutes toujours en activité et gérées par l'ONCF comme opérateur unique de
maintenance y compris les embranchements particuliers vers ses clients cimentiers, sidérurgistes,
industriels, agroalimentaires et miniers. Ce réseau de voies ferrées est composé comme suit:

• 3 657 km total de voies ferroviaires en activité ;

• 2 921 km de voies de circulation principales ;
• 736 km d'embranchements particuliers, de voies de service et de traitement logistique ;
• 2 110 km de lignes principales à écartement UIC exploité pour le transport de Fret et
passagers;
• 1 965 km de ces lignes sont en Long Rail Soudé LRS (93 % du réseau);
• 1 300 km de lignes électrifiées (60 % du réseau);
• 640 km de lignes à double voies (30 % du réseau).

13
Ainsi, le réseau ferroviaire marocain qui permet des vitesses de 160 Km/h sur certains tronçons, se
présente sous forme d’un couloir reliant le Sud (Marrakech) à l’Est (Oujda) avec des antennes vers
Tanger, Safi, Oued Zem, El Jadida et Bou Aârfa. Il dessert les grandes villes et les principaux ports du
Royaume à l’exception de ceux d’Agadir au Sud et de Nador au Nord.

Quant au parc matériel roulant, il se compose de 117 locomotives de lignes, 95 locomotives de

manœuvre, 14 rames automotrices à 3 voitures, 372 voitures à voyageurs et 6894 wagons à marchandises.

2.3 Activités

2.3.1 Chiffre d’affaires

L'ONCF continue sa croissance sur son secteur d'activité voyageur (39.6 millions de passagers en 2014
contre 38 millions en 2013). Cette activité passagère a permis de stabiliser le chiffre d'affaires du groupe
à 3.6 milliards de dirhams en 2014 1 % (2.15 MM MAD fret, 1.45 MM MAD transport passagers).

2.3.2 Transport de voyageurs

En 2014, l’ONCF a transporté 39.5 millions de voyageurs ( 4 %) avec un taux de 5.3 milliards de
passagers km stable par rapport à 2013

2.3.3 Transport de marchandises

En 2014, le trafic marchandises s'est rétracté quant à lui à 34.6 millions de tonnes mais avec taux de 5.8
milliards de tonnes km en hausse par rapport aux 5.7 Milliards de tonnes km réalisées en 2013.

2.4 Fiche signalétiques

Raison Social Office National des chemins de fer

Date de création 5 Aout 1963
Forme Juridique Etablissement semi public
Siège Social 8 bis, rue Abderhmen El Ghafiki
Rabat-Agdal
Site Web [Link]
Nom du PDG Mohammed Rabie Khlie(DG)
Secteur d’activité Transport des voyageurs, de marchandises diverses
et du phosphate.
Effectif 8960 personnes

Tableau 1: Fiche signalétiques

14
2.5 Organigramme de l’ONCF

Figure 2: Organigramme de l'ONCF

15
3 Présentation du cadre général du projet

3.1 Problématique
ERAC, filiale du pôle Infrastructure et Circulation de l’ONCF a proposé l’idée d’un projet de
digitalisation de son atelier de maintenance « Smart Mobile Workshop 1.0 ». Mon projet de fin d’étude
fait partie du sous projet « Diagnostic en ligne 1.0 ».

Mon projet de fin d’étude consiste à faire l’extraction des données enregistrées dans les mémoires de la
CCU et l’US, puis de les filtrées et les décodées afin de détecter la nature de la panne et les informations
qui la concernent. Ensuite, ces informations vont être stockées au Cloud afin qu’elles soient disponibles
pour le superviseur distant via une application mobile Android.

3.2 Démarche et Planification

3.2.1 Introduction
La méthode joue un rôle essentiel pour réussir un projet, elle est aussi importante que le développement
lui-même. La planification et la répartition des tâches, sont la base d’atteindre les objectifs d’un projet.
Quant à nous on travaille avec Scrum.

3.2.2 Scrum
Scrum est la méthode de référence développé par Ken Schwaber et Jeff Sutherland en 1993 lorsqu’il
s’agit d’apporter un cadre à un projet en agile. Comme c’est un standard répandu, elle permet à l’équipe
de ne pas trop se poser de questions sur leur organisation au lancement du projet.

Une fois que l’équipe est rodée à la méthode, nous avons :

• Un backlog priorisé
• Une équipe engagée sur un objectif récurrent (par exemple deux semaines)
• Des rituels pour que l’équipe communique
• Un processus d’amélioration continue

Et traditionnellement, les équipes utilisant Scrum, ont aussi :

• Du management visuel
• Un suivi de la vélocité de l’équipe

Le management visuel, même s’il ne fait pas partie initialement du framework Scrum, on retrouve
généralement un tableau – appelé communément “board visuel” ou “Scrum-board”.

En Scrum, le board est dédié à ce qui se passe pendant l’itération. L’intention est de se concentrer sur le
cœur du développement.

Le cycle de vie des User Stories en amont de l’itération (“en cours de rédaction”, “prêt à développer” etc)
est donc géré par le « « Project Owner » » et n’est pas visible par le reste de l’équipe.

16
 • Pour les développeurs en particulier, ne pas voir les fonctionnalités prévues pour les jours qui
viennent, c’est comme conduire dans le brouillard, et donc sans voir suffisamment bien
devant soi. L’équipe a besoin d’avoir une visibilité sur les « « User Stories » » qui vont
arriver dans les prochains Sprints car il peut y avoir un impact sur la manière de développer le
sprint en cours.

• C’est également très important de définir un workflow de conception adapté dans lequel nous
pouvons avoir bien plus d’acteurs que le PO (responsable métier ou marketing, UX, designer
si besoin etc …).

• Cela permet aussi d’avoir une réelle visibilité en termes de pilotage sur le niveau de
préparation de la suite du projet.

Voici un exemple simple de board Scrumban :

Figure 3: Scrum Board

3.2.3 Planification du projet
La planification est très importante dans un projet, il aide à estimer les charges, définir les étapes de la
réalisation du projet. Nous utilisons le diagramme Gantt pour représenter graphiquement les différentes
tâches qui constituent le projet.

17
Figure 4 : Diagramme de Gantt

18
Chapitre II
Extraction des données diagnostiques

Dans ce chapitre, nous allons s’intéresser à la première étape du projet qui consiste à
extraire, filtrer et à décoder, pour identifier vers la fin la nature de la panne. Pour cela, ce chapitre
a pour objectif, de présenter en premier lieu le réseau de communication au sein des trains, ainsi
qu’une description matérielle et logicielle des unités centrales de commande. En deuxième lieu,
les deux méthodes d’extraction possible. Et finalement, en troisième lieu le filtrage et le décodage
des données diagnostiques reçues.

19
Chapitre 2 : Extraction des données

1 Introduction
Les rames dans le jargon du chemin de fer est un ensemble cohérent de véhicules (Voitures ou wagons)
attelés entre eux. Une rame automotrice assure elle-même sa propulsion ; elle peut alors circuler seule ou
en unités multiples, composées de plusieurs éléments automoteurs. Elle est réversible, elle peut circuler
dans les deux sens sans retournement, ni déplacement de la locomotive.

Une rame est comme tous autres véhicules, elle dispose d’un système électronique embarqué qui assure
l’ensemble des tâches pour sa circulation. On s’intéressera dans ce chapitre à une description
fonctionnelle générale de ce système.

2 Description fonctionnelle des rames automotrices Z2M

Les rames Z2M sont des trains haute fréquence, ils consistent en un ou deux convois constitués
respectivement de Motrice, Remorque, Remorque, Motrice.

Figure 5 : Composants d’une Rame Z2M

2.1 Train Communication Network (TCN) :

Le TCN fait partie des types de réseaux de communications au sein des trains, il est une combinaison
hiérarchique de deux bus de terrain, pour la transmission de données dans les trains. Il se compose
d'un bus de véhicule multifonctions (MVB) à l'intérieur de chaque véhicule et d'un bus de train
câblé (WTB) permettant de connecter les différents véhicules.

Le TCN est utilisé dans la plupart des systèmes de contrôle de train qui connectent généralement les
véhicules avec un UIC 558 à 18/13 broches.

20
 WTB

MVB

Figure 6: Topologie du réseau TCN

Tous les dialogues présents sur le bus MVB (Bus de véhicule) sont orchestrés par le Train Car Node
(Noeud de voiture) qui lui-même se charge d'établir la connexion en multiple entre plusieurs unités de
traction.

En effet, le TCN (Nœud de voiture), d'une part, est un bus d'administration local permettant le réglage et
la transmission cyclique des informations entre les éléments électroniques mentionnés ci-dessous, et
d'autre part, il stabilise la connexion en « télécommande » entre deux motrices éloignées. On s’intéressera
par la suite aux dispositifs présents sur le bus MVB.

Figure 7 : Schéma des dispositifs communicants via le bus MVB

CCU1(2) : Unité de commande central Master (Slave), La CCU est une installation de supervision de
train. En l'occurrence, au moyen du MVB (Bus de véhicule) elle envoie des commandes et reçoit les
informations ; au moyen d'entrées numériques ; sur les réalisations et sur les états internes des Services
auxiliaires et des Actionnements.

Avec de tels postes, des télégrammes de données sont prévus sur le bus MVB entre la CCU master et le
CGS et entre la CCU et le TCU. De plus, toujours localement sur une motrice par l'entremise du MVB
(Bus de véhicule), la CCU dialogue avec la UGC (le superviseur des installations de voiture) et envoie
des informations aux terminaux de banc TS et TD.

Les installations vitales CCU, UGC et TCN (Noeud de voiture) sont redondantes.

21
2.2 Description matérielle de la CCU
Le panier CCU est à composition mixte constitué des parties suivantes :

Partie 1:

• Prédisposée pour accueillir les fiches de microprocesseur STA-01, STA-02 et les fiches
d'interface TFP-MDV-DI.
• La STA est une famille de fiches basées sur le microcontrôleur Siemens C167.
• MDV : Mémoire Diagnostic du Véhicule
• DI : pour l'acquisition à travers le BUS VME de l'état de relais, contacteurs, électrovalves etc.

Partie 2:

• Prédisposée pour accueillir l'unité de filtre, les artères d'alimentation et les dispositifs
compteur horaire.

Partie de support connecteur :

• Prédisposée pour accueillir 4 connecteurs à travers lesquels le panier fait de l'interfaçage avec
le monde externe.

Figure 8 : Description matérielle de la CCU

22
2.3 Description logiciel de la CCU
Logiciel d’application : comprend les micros fonctions suivantes

• Répartiteur
• Interface Opérateur et Diagnostic
• Logique du Véhicule.

Le logiciel de base : inclut les drivers pour

• L'interface avec le bus VME,

• La connexion sérielle sur Bus Diagnostic
• Le Bus MIDA et les protocoles relatifs au Bus sériel diagnostic.

Système opérationnel : est requis pour

• L'utilisation du logiciel de communication

• L'implémentation du TCN (Nœud de voiture) spécifique,
• L’utilisation d’un environnement real time multitasking.

3 Extraction des données

3.1 Spécification des besoins
Cette première partie du projet a pour objectif, d’extraire le plus grand nombre possible de d’information
significatif pour la détection des pannes. Toutefois cette étape doit répondre aux exigences suivantes :

• Spécifier pour chaque panne: son code référentiel, le numéro de voiture en panne, sa date
d’occurrence, le système responsable de signaler l’occurrence.

• Au cas où une panne est corrigée, elle doit être reconnue via son code référentiel, et donc une
cinquième spécification s’ajoute ; celle de l’état de la panne « ON » ou « OFF ».

• L’extraction doit être en temps réel pour accompagner la rame tout au long de son trajet.

3.2 Méthodes d’extraction

La CCU mémorise les données diagnostiques relevées localement dans une base de données spéciale
non volatile (DB_DAT). Comme, elle mémorise celles qui sont distantes et locales en même temps dans
une autre mémoire volatile. D’un point de vue matériel, le système diagnostic comprend des parties de la
CCU qui sont Fiche STA-02 et Fiche MDV, Seule la fiche STA-02 dispose d’un port serial pour
ordinateur.

Cette dernière réalise fondamentalement les fonctions suivantes :

• Fonctions diagnostiques de Train ;

• Fonctions de communication (Bus MVB - Bus de véhicule)
• Gestion Dialogue pour ordinateur pour téléchargement données ;
• Dialogue avec les autres paniers pour gestion redondance CCU.

23
 3.2.1 Procédure de téléchargement des données par la fiche de mémoire
[Link] Méthode 1

Cette première méthode est la méthode de base utilisée par les intervenants de l’ONCF au sein de
l’atelier. Cette procédure de téléchargement s'exerce seulement dans des conditions normales dans
lesquelles les électroniques de bord nécessaires à la définition de la topographie de train sont actives et de
conséquence le Réseau de Train est défini.

Pour faire, il faut connecter un ordinateur au panier CCU en établissant la connexion entre le port sériel
de la fiche STA02 et la sérielle de l'ordinateur.

Le câble sériel à utiliser pour la connexion doit être muni de 2 connecteurs à 9 pôles avec les
caractéristiques suivantes :

L'ordinateur doit disposer des logiciels de base suivant :

• Système exploitation WINDOWS 95 ou version supérieure ;

• Logiciel de communication HyperTerminal ou équivalent qui supporte le protocole de
communication de la famille XMODEM) ;
• Programme d'application [Link] (version 1.0).
• [Link] est un programme développé par l’entreprise conceptrice des rames.

Le programme présent sur la fiche STA02 inclut la fonction logicielle partner nécessaire à l'exécution de
la procédure de téléchargement des données de la CCU à l'ordinateur.

Bit par seconde 38400

Bit de données 8
Parité Aucune
Bit d’arrêt 1
Contrôle de flux Aucun

Tableau 2: Configuration de la communication en HyperTerminal

24
Dans le cache actif du menu Transférer → Recevoir Fichier on prédispose :

• Le nom du répertoire dans lequel on désire recevoir les fichiers binaires de la CCU
• Le type de protocole de transfert : XMODEM

Pour effectuer le téléchargement des données par la CCU désirée, il faut passer aux étapes suivantes :

• Etablir la connexion sérielle entre l'ordinateur et la CCU active (fiche STA02) en utilisant la
connexion x d'HyperTerminal.

• Transmettre quelques RETOUR sur le clavier de l'ordinateur. Dans la baie sérielle, l'invite de
commande général apparaît « STA/CCUM:3 » : ceci signifie que la fiche STA02 est prête à
recevoir les commandes.

• Envoyer la commande « envoi_dbsc » suivie d'un caractère d'espacement à l'adresse de

logique de la CCU. Si par exemple on se trouve dans la cabine avec banc habilité, l'adresse de
logique de la CCU est 1 et la commande assume la forme : envoi_dbsc 1

• Dans le cache, les fichiers prédisposés à la récolte des données sont déjà prédéfinis et le
protocole comme décrit dans le paragraphe précédent.

• Activer le bouton de commande Recevoir et dans le cache successif, introduire le nom du

fichier (de 8 caractères) que l'on désire créer sur l'ordinateur dans le fichier déjà défini et
donner le OK sur le bouton de commande homonyme.

• Durant la transmission il y a un moniteur d'avancement de la transmission. À la fin, la CCU

transmet le message de fin de transmission en informant du résultat positif ou négatif du
processus ; respectivement ACK (Accusé de réception positif), NAR.

Une fois le fichier des données est téléchargé de la mémoire MDV, pour pouvoir être interprété, il doit
être transcodé en format de fichier de texte directement lisible.

L'opération de décodification est faite en utilisant le programme [Link]

Pour effectuer la décodification, on lance à partir de l'invite de commande :

« DECOTAF NOM_FICHIER_IN NOM_FICHIER_OUT »

Pour générer un simple tableau relationnel sans titres, on donne la commande

« DECOTAF NOM_FICHIER_IN NOM_FICHIER_OUT R »

25
 Tableau 3: Résultat de la première méthode

[Link] Méthode 2

La deuxième méthode proposée pour cet objectif est d’utiliser une carte électronique, et en bénéficiant
du port série de la CCU, on pourra recevoir les données instantanément. Cependant, les données qui
seront relevées nécessitent une décodification hors [Link] le programme dédié à décodification
dans la première méthode. On verra par la suite le hardware et le software utilisés pour cette mission.

[Link].1 Hardware :
Pour recevoir des données en série, un large choix de carte électronique disposant d’un port de
communication série était devant nous : Arduino Yun, Raspberry Pi 3, BeagleBone Black, STM, Intel
Galileo, etc…. Il suffira de faire son choix, et être muni d’un câble USB à RS232 femelle.

Arduino Yun :

Arduino est une plate-forme électronique open-

source basé sur un matériel et logiciel facile à utiliser.
L’Arduino Yun est une carte microcontrôleur basé sur
l’ATmega32u4 et l’Atheros AR9331. Le processeur
Atheros prend en charge une distribution Linux basée sur
OpenWrt, nommé Linino OS. La carte prend en charge les
connexions Ethernet et WiFi intégrées, un port USB-A, un
emplacement pour carte micro-SD, 20 broches d’entrée /
sortie numériques (7 d’entre elles peuvent être utilisées en
tant que sorties PWM et 12 en tant qu’entrées analogiques),
un cristal 16 MHz oscillateur, une connexion micro USB,
un en-tête ICSP et 3 boutons de réinitialisation. Figure 9: Arduino Yun

Microcontrôleur ATmega32U4 Microprocesseur Atheros AR9331

Tension de fonctionnement 5v Tension de fonctionnement 3.3V
E/S numériques 14 Architecture MIPS
@400MHz
Sorties PWM 7 Ethernet 802.3
10/100Mbit/s
Entrées analogiques 6 Wifi 802.11 b/g/n
2.4 GHz

26
Intensité par broche E/S 40 mA USB Type 2.0 Host
max
Intensité broche 5V 500 mA Lecteur de carte Micro-SD
max
Intensité broche 3,3 V 50 mA RAM 64 MB DDR2
max
Mémoire Flash 32 ko Mémoire Flash 16 MB
SRAM 2.5 ko SRAM 2.5 ko
EEPROM 1 ko EEPROM 1 ko
Vitesse d’horloge 16 MHZ Vitesse d’horloge 400 MHZ
Tableau 4: les caractéristiques principales de l’Arduino Yùn

Raspberry Pi 3 B:

Le Raspberry Pi est un nano ordinateur à processeur

ARM conçu par des professeurs du département
informatique de l'université de Cambridge dans le
cadre de la fondation Raspberry Pi. Celle-ci a une
vocation d’apprentissage, mais elle est en pratique
très utilisée pour le prototypage. Son ordinateur
Raspberry Pi 3 B est un concentré de puissance qui
fait tourner de nombreux systèmes d’exploitation
libres, de Debian, Fedora ou Suse à Firefox OS et
Kali Linux, en passant par NetBSD. Figure 10 :Raspberry Pi 3 B

SoC Broadcom BCM2837

CPU 1,2 GHz quadri cœur ARM Cortex- Systèmes Debian GNU/Linux, Raspbian
A53 d'exploitation OS, Fedora, Arch Linux ARM
, RISC OS, FreeBSD, Plan 9, Kali
Linux, Snappy Ubuntu Core,
SolydX RPI, Windows 10 IoT
GPU Broadcom VideoCore IV79, OpenGL Carte/connectique 10/100 Ethernet, Wifi 802.11n,
ES 2.0, MPEG-2 et VC-1 (avec réseau Bluetooth 4.1
licence), 1080p30 h.264/MPEG-4
AVC high-profile décodeur et
compresseur
Mémoire 1 Go Source 5 volts via Micro-B USB ou
(SDRAM) d'alimentation GPIO header
Nombre de 4 (2.0) Dimensions 85,60 mm × 53,98 mm ×
ports USB 17 mm
MicroSD Périphériques bas 17× GPIO, UART, I²C bus, SPI bus
Unité de niveau avec deux chip selects,
R/W I²S audio, +3.3 V, +5 V

Tableau 5: : les caractéristiques principales de la RPI 3 B

27
BeagleBone Black Wireless

Le BeagleBone Black Wireless de [Link] est

une carte de développement basée sur le processeur
AM335x ARM Cortex-A8, avec la fonctionnalité de
réseau sans fil supplémentaire. Cette carte BeagleBone
est un ordinateur monocarte (SBC) qui est fourni avec
Debian Linux OS préinstallé et peut être utilisé comme
un ordinateur autonome ou intégré dans un système.

Les capacités sans fil supplémentaires sont fournies

avec une puce WiLink Wifi/Bluetooth. Vous pouvez
également ajouter jusqu'à quatre capes d'extension sur
les embases de la carte BeagleBone Black Wireless.

Figure 11: Beagle Bone Black Wireless

Processeur AM3359AZCZ100 1 GHz

ARM Cortex-A8
Mémoire Flash eMMC 4 Go, 512 Mo de USB 1 hôte USB A 2.0, 1 client
DDR3, EEPROM de 4 ko mini-USB 2.0
Wifi WiLink 1835 802.11 b/g/n 2,4 GPIO 2 embases 46 broches
GHz
Bluetooth Bluetooth 4.1 avec BLE Alimentation mini-USB ou jack 5 V c.c
Stockage carte microSD, MMC 3,3 V Indicateurs LED Alimentation, WiFi,
Bluetooth, 4 LED utilisateur
TPS65217C Graphismes SGX530 3D, 20
PMIC Mpolygones/s

Tableau 6:les caractéristiques principales de la BBB Wireless

[Link].2 Software
Pour le coté software, nous avons décidé de programmer en langage Python.

• Python est un langage de programmation inventé par Guido van Rossum en 1991, qui
travaillait à cette époque au Centrum voor Wiskunde en Informatica aux Pays-Bas. Python,
Il est conçu pour optimiser la productivité des programmeurs en offrant des outils de haut
niveau et une syntaxe minimaliste, claire, simple, suffisamment proche du langage naturel
pour qu’un algorithme soit compris dès la première lecture par un lecteur qui connaît
l’anglais.

Nous avons développé donc une première fonction en python readFromSerial () et implémenter le
package « serial » de l’API «pySerial ».

• pySerial est un module d'API Python permettant d'accéder au port série. pySerial fournit
une API uniforme sur plusieurs systèmes d'exploitation, notamment Windows, Linux et
BSD.

28
 • RegEx : Python a un paquet intégré appelé « re », qui peut être utilisé pour travailler avec
des expressions régulières. Une expression régulière, est une séquence de caractères qui
forme un modèle de recherche. RegEx peut être utilisé pour vérifier si une chaîne contient le
modèle de recherche spécifié. (Dans notre cas : « code : », « Plant : », «tipo : »). Le module
propose plusieurs fonctions comme « findall », « search», «split », «sub».

4 Traitement et filtrage des données

Le résultat obtenu après l’extraction native était comme-suit :

Figure 12 : Capture de la data reçue sur le port série

La data ci-dessus est obtenue lorsqu’une panne est générée. On devait donc à partir de ce résultât
extraire les informations nécessaires et suffisantes pour rendre la panne identifiable par le superviseur
distant de la rame.

Nous avons pu alors déterminer le code de la panne (a01e sur la figure en haut). Cependant pour les
autres paramètres (Date d’échéance, voiture, équipement, état, type de panne) :

• Date d’échéance: Calculé en temps réel, lors de la réception d’une donnée sur le port
série.
• Voiture: pour identifier ces champs, nous avons entamé plusieurs tests directs sur les
rames par la génération des pannes sur des multiples voitures du train pour déterminer le
quel de Plant ou UIC signifie voiture.

• Etat : Concernant l’état de la panne ON ou OFF, on vérifie la réception du mot tipo:0

ou tipo:55 (d’après des tests).

• Equipement : les codes de pannes sont regroupés de la manière à ce que chaque plage
hexadécimale est réservée à un équipement. Comme le montre le tableau ci-dessous :

29
 CGS De 6000 à 7FFF
Nœud, Moniteur, Divers De 8000 à 9FFF
UGC De A000 à FFFF
CCU De 2000 à 3FFF
TCU De 4000 à 5FFF
Réserve De 0 à 1FFF
Tableau 7: Type d'équipement selon le code de la panne
Type de panne : Ce paramètre permet de décrire le contenue de la panne à partir de son code
référentielle. L’ONCF dispose d’un fichier XML, qui offre pour chaque code, un texte qui explique la
panne.

Figure 13 Capture du fichier XML

Apres avoir décoder la data reçue, on arrive à la phase filtrage des champs significatifs. Pour cela, on a
utilisé le module de Python RegEx(RE) définit précédemment.

5. Conclusion
On aura vu dans ce chapitre, une description générale du réseau de communication au sein des rames,
ainsi qu’une description logicielle et matérielle de l’unité centrale de commande. Cette installation de
supervision est l’unique accès au système diagnostique du train. L’accès est assuré par deux méthodes, la
première est celle de base qui est appliqué par les intervenants dans l’atelier de l’ERAC. Son
inconvénient est qu’elle ne vérifie pas un des besoins principaux cités dans le début « l’extraction en
temps réel ».

L’application de cette méthode est associée à la disponibilité des rames dans l’atelier pour subir des
interventions techniques d’où elle ne les accompagne pas durant leurs circulations.

Pour remédier à cet inconvénient, nous avons pensé à la deuxième méthode, qui consiste à implémenter
une carte électronique dans la CCU, qui pourra recevoir l’échéance de chaque panne en temps réel.

Un point d’accès wifi ainsi qu’un adaptateur de tension seront implémentés avec la carte électronique,
pour assurer l’alimentation de cette dernière ainsi que de pouvoir envoyé les données collectées au Cloud.

Le prochain chapitre de ce rapport portera donc sur la partie Cloud du projet.

30
Chapitre III
Transmission des données au Cloud

Ce chapitre présente la deuxième étape du projet qui est l’envoi des données extraites durant
la première étape. On verra donc en premier lieu une présentation du Cloud Computing, en
deuxième lieu une étude comparative et choix de la solution. Finalement, en troisième lieu, le
schéma d’envoi à suivre, les services utilisés et finalement, la liaison entre la deuxième partie et
la troisième.

31
Chapitre 3 : Envoi des données au Cloud

1 Introduction :
Comme mentionné précédemment, le but de ce projet est de permettre au superviseur de suivre l’état
électromécanique des rames distantes qui sont en circulation. Et puisque ce suivi sera en ligne, donc on
aura fortement besoin des services offertes par Cloud, pour assurer la réception, le stockage et finalement
l’envoi des pannes.

2 Cloud Computing :
2.1 Définition et généralités :
L’informatique dans le nuage est plus connue sous sa forme anglo-saxonne : « Cloud Computing », mais
il existe de nombreux synonymes francophones tels que : « informatique dans les nuages », «
infonuagique » (Québec) ou encore « informatique dématérialisée ».

Plusieurs définitions sont proposées dans ce contexte, la plus pertinente et commune entre elles est:

« Le Cloud Computing est un modèle qui permet un accès réseau à la demande et pratique à un pool
partagé des ressources informatiques configurables (telles que réseaux, serveurs, stockage, applications et
services) qui peuvent être provisionnées rapidement et distribuées avec un minimum de gestion ou
d’interaction avec le fournisseur de services ».

Selon le National Institute of Standards and Technology, le Cloud Computing englobe trois
caractéristiques clés :

• la mutualisation, de la part du fournisseur, de ressources éclatées ;

• des ressources accessibles en réseau ;
• des ressources accessibles rapidement, à la demande et de façon souple.

En conclusion, L'idée principale à retenir est que le Cloud n'est pas un ensemble de technologies, mais un
modèle de fourniture, de gestion et de consommation des services et des ressources informatiques
localisés dans des Datacenter.

32
 Figure 14: Cloud Computing - Wikipedia-

Le modèle Cloud Computing se différencie par les cinq caractéristiques essentielles suivantes:

• Accès aux services par l’utilisateur à la demande :

La mise en œuvre des systèmes est entièrement automatisée et c’est l’utilisateur, au moyen d’une
console ou à travers des outils et des logiciels spécifiques, qui mettent en place et gèrent la
configuration à distance.

• Accès réseau large bande :

Ces centres de traitement sont généralement raccordés directement sur le Backbone internet pour
bénéficier d’une excellente connectivité. Les grands fournisseurs répartissent les centres de
traitement sur la planète pour fournir un accès aux systèmes en moins de 50 ms de n’importe quel
endroit.

• Réservoir des ressources (non localisées) :

La plupart de ces centres comportent des dizaines de milliers de serveurs et de moyens de
stockage pour permettre des montées en charge rapides. Il est souvent possible de choisir une zone
géographique pour mettre les données “près” des utilisateurs.

• Redimensionnement rapide (élasticité) :

La mise en ligne d’une nouvelle instance d’un serveur est réalisée en quelques minutes, l’arrêt et
le redémarrage en quelques secondes. Toutes ces opérations peuvent s’effectuer automatiquement
par des scripts. Ces mécanismes de gestion permettent de bénéficier pleinement de la facturation à
l’usage en adaptant la puissance de calcul au trafic instantané.

33
 • Facturation à l’usage :
La facturation est calculée en fonction de la durée et de la quantité de ressources utilisées. Une
unité de traitement stoppée n’est pas facturée.

2.2 Les Services Cloud :

Les services de Cloud sont regroupés en trois types principaux. Ces types sont catégorisés selon la couche
technique fournie par l’hébergeur comme illustrer dans la figure ci-dessous :

Abstracted by Vendor

Costumer managed

Costumer managed unit of scale

Figure 15: Les types de services Cloud

▪ Infrastructure as a Service (IaaS):

Pour ce type, les fournisseurs de Cloud, proposent des ressources informatiques à la demande à partir de
leurs vastes pools d'équipements installés dans des Datacenter, tels que les espaces de stockages, les
bandes passantes, les unités centrales… etc. Les utilisateurs d’une IaaS peuvent donc utiliser des serveurs
virtuels situés dans des Datacenter sans avoir à gérer les machines physiques.

Pour déployer leurs applications, les utilisateurs du service IaaS, installent, corrigent et gèrent leur OS et
leur logiciel d'application sur l'infrastructure Cloud louée. Quant aux fournisseurs facturent généralement
par le coût correspond à la quantité de ressources allouées et consommées.

▪ Platform as a Service (PaaS):

En ce qui concerne ce type de service, le fournisseur offre un environnement de développement aux
développeurs d’applications, en fournissant une plate-forme informatique , comprenant généralement un
système d'exploitation, un environnement d'exécution en langage de programmation, une base de données
et un serveur Web. Les principaux fournisseurs de PaaS sont : Microsoft avec AZURE, Google avec
Google App Engine et Orange Business Services.
On utilisera ce service par la suite dans notre projet.

34
 ▪ Software as a Service (SaaS) :

Le matériel, l’hébergement, le framework d’application et le logiciel sont dématérialisés, et hébergés dans

un des Datacenter du fournisseur. Les utilisateurs consomment les logiciels à la demande sans les acheter,
avec une facturation à l’usage réel. Il n’est plus nécessaire pour l’utilisateur d’effectuer les installations,
les mises à jour ou encore les migrations de données.

Les solutions SaaS constituent la forme la plus répandue de Cloud Computing. Les prestataires de
solutions SaaS les plus connus sont Microsoft – offre Office365 (outils collaboratifs) Google – offre
Google Apps (messagerie et bureautique). Le modèle de tarification pour les applications SaaS est
généralement un forfait mensuel ou annuel par utilisateur.

▪ "Backend" mobile en tant que service (MBaaS) :

Ce service fournit un Backend pour des applications (principalement mobiles). Ils fournissent une API et
des outils permettant à différents langages informatiques de s'intégrer à leur Backend. Ils fournissent
également des services supplémentaires tels que stockage, analyses, notifications push, et des tableaux de
bord
D'une manière ou d'une autre, il est similaire au SaaS, mais BaaS est principalement destiné aux
développeurs, alors que SaaS est destiné aux utilisateurs finaux.
Firebase , récemment acquis par Google, est un produit BaaS très populaire. Il vise principalement les
applications en temps réel et offre également du stockage. On utilisera ce produit par la suite dans notre
projet.

▪ Function as a Service (FaaS):

C’est un service Cloud qui permet aux développeurs logiciel de s’en servir pour déployer une fonction
individuelle sous forme d’un microservice pour planifier des taches ou pour traiter des requêtes Web,
etc…
La différence entre PaaS et FaaS, est que le FaaS permet de déployer une seule fonction d’une application
plutôt que l’application intégrale. Contrairement au cas des PaaS où les applications sont généralement
exécutés en permanence sur au moins un serveur, le FaaS permet de ne lancer la fonction que lorsque
c’est nécessaire et durant quelques secondes seulement.
Google Cloud Functions est l’offre FaaS de Google Cloud Platform, qui fournit un environnement
d'exécution sans serveur pour créer et connecter des services Cloud.

35
2.3 Méthodes de déploiement :
On pourra distinguer quatre modes de déploiement du Cloud : Cloud privé, Cloud public, Cloud
communautaire et Cloud hybride.

▪ Cloud privé :

C’est une infrastructure Cloud exploitée uniquement par un seul client, gérée en interne ou par un tiers et
hébergée en interne ou en externe. L’utilisation d’un Cloud privé permet de garantir, par exemple, que les
ressources matérielles allouées ne seront jamais partagées par deux clients différents.

▪ Cloud public

Un Cloud est appelé "public" lorsque les services sont rendus sur un réseau ouvert au public. Son
propriétaire est une entreprise qui vend de l’informatique en tant que service.

En règle générale, les fournisseurs de services de Cloud public tels qu'Amazon Web Services (AWS), IBM,
Oracle , Microsoft et Google possèdent et exploitent l'infrastructure dans leur centre de données. Et l'accès
se fait généralement via Internet.

AWS, Oracle, Microsoft et Google proposent également des services de connexion directe appelés "AWS
Direct Connect", "Oracle FastConnect", "Azure ExpressRoute" et "Cloud Interconnect". Ces connexions
exigent que les clients achètent ou louent une connexion privée à un point de peering offert par le
fournisseur de Cloud.

▪ Cloud communautaire :

Son infrastructure est partagée par plusieurs organisations indépendantes et est utilisée par une
communauté qui est organisée au tour des mêmes besoins, vis-à-vis de son utilisation.

L’infrastructure du Cloud communautaire peut être gérée par les organisations de la communauté qui
l’utilise ou par un tiers et peut être située, soit au sein des dites organisations, soit chez un prestataire de
service

▪ Cloud hybride :

Un Cloud hybride c’est la composition d’un Cloud public avec un environnement privé; que ce soit un
Cloud privé ou un on-premise ; qui restent des entités distinctes mais qui sont liées les unes aux autres,
offrant ainsi les avantages des différents modèles de déploiement. En d’autres termes, il permet d’étendre
la capacité d’un service Cloud, par agrégation, intégration ou personnalisation avec un autre service
Cloud.

Parmi les cas d’utilisation d’un Cloud hybride, une entreprise peut stocker des données client sensible sur
une application de Cloud privé, mais interconnecter cette application avec une application de BI fournie
par un Cloud public.

36
3 Les fournisseurs Cloud, Benchmark, et choix de la solution :
3.1 Les fournisseurs Cloud :
Les fournisseurs des services de Cloud Computing sont des hébergeurs, Ils mettent à disposition des
infrastructures physiques proposant une plate-forme de Cloud. Il serait bien trop conséquent d’analyser
tous les acteurs du Cloud Computing présents sur le marché actuel. Nous survolerons les principaux
acteurs: Amazon, Google, et Microsoft :

3.1.1 Amazon Web Services :

C’est une division du groupe américain [Link] de commerce électronique, lancée en 2006 et
spécialisée dans les services de Cloud Computing pour les entreprises et les particuliers.

AWS propose un large éventail de produits internationaux basés sur le Cloud : calcul, stockage, bases de
données, analyse, mise en réseau, services mobiles, outils de développement, outils de gestion, Internet
des Objets, sécurité et applications d'entreprise.

Quant aux services Cloud proposés :

▪ Amazon EC2 : Serveurs virtuels dans le Cloud.

▪ Amazon Simple Storage Service (S3) : Stockage adaptatif dans le Cloud.
▪ Amazon Aurora : Base de données relationnelle gérée hautes performances.
▪ Amazon DynamoDB: Base de données NoSQL gérée.
▪ Amazon RDS : Service de base de données relationnelle gérée pour MySQL,
PostgreSQL, Oracle, SQL Server et MariaDB.
▪ AWS Lambda : Exécution de code sans avoir à se soucier des serveurs.
▪ Amazon VPC : Ressources Cloud isolées.
▪ Amazon Lightsail : Lancement et gestion de serveurs virtuels privés.
▪ Amazon SageMaker : Création, formation et déploiement de modèles de machine
Learning à grande échelle.

3.1.2 Google Cloud Platform :

C’est une plateforme de Cloud Computing fournie par Google et lancée en première version le 6 octobre
2011. Elle propose un hébergement sur la même infrastructure que celle que Google utilise pour son
moteur de recherche.

Cette plateforme est composée d’une famille de produits, chacun comportant une interface web, un outil
de lignes de commande et une interface de programmation applicative REST.

Parmi ces produits on trouve :

▪ Google Comput Engine : le composant IaaS de la Google Cloud Platform permettant aux
utilisateurs de lancer des machines virtuelles (VMs) à la demande.
▪ Google App Engine : c’est le service PaaS de Google qui vous permet l’utilisation des
mécanismes du Cloud Computing et de bénéficier de leurs avantages pour votre application.
▪ Google Kubernetes Engine : c’est un logiciel open-source de gestion de conteneurs.
▪ Google Cloud Storage : c’est un système de stockage en ligne de fichiers
▪ Google BigQuery : un logiciel de type SaaS, qui permet l’analyse interactive massive de
grands ensembles de données en collaboration avec l’espace de stockage Google.

37
 Figure 16: Les services du Cloud de Google
3.1.3 Microsoft Azure :
Microsoft annonçait l'arrivée de sa propre solution de Cloud Computing nommée Windows Azure. Cette
dernière a été rendue commerciale en janvier 2010. Microsoft Azure propose une panoplie de services qui
couvrent les trois types des services Cloud :

▪ PaaS :
- Compute: Cloud Services, Service Fabric, Batch, And Remote App.
- Data: SQL Database, SQL Data Warehouse, Cosmos DB, etc…
- Security and Management: Portal, Active Directory, Multi-Factor
Authentication, etc…
- Developer Services: Visual Studio, Azure SDK, Application Insights, etc...
- Analytics and IoT: HDInsight, Machine Learning, Data Factory, Event Hubs,
etc…

▪ IaaS :
- Compute : Virtual Machine , Containers
- Storage: BLOB Storage, Azure Files, Premium Storage.
- Networking: Virtual Network, Load Balancer, DNS, Application Gateway, etc…
• SaaS :
- Microsoft Office 365 et d’autres.

3.2 Benchmark des solutions :

Amazon WS Google Microsoft Azure
Security - TLS for device-cloud - TLS for device-cloud - TLS for device-cloud
encryption. encryption. encryption.
- JSON Web Tokens, - JSON Web Tokens. - JSON Web Tokens. -
- On-device X.509 - On-device X.509 On-device X.509
Certification and Private Keys Certification and Private Certification and Private
- IAM Users and Groups. Keys. Keys.
- Amazon Cognito Identities. - IAM Users and
Groups.
- RSA and Elliptic
Curve
Pricing - A compter du 2 Octobre, la - Facturation à la - Microsoft également
facturation sera à la seconde; seconde avec une propose des remises sur

38
 avec un minimum de une minute minimum, aux mode d’emploi. Ex :
minute, pour EC2, EBS, et virtuels Compute Machine virtuelle de
d’autres services. Engine, Container série B réservée : Pour
- Les prix du marché sont Engine, Cloud Dataproc 3 ans : $0.0051/h
toujours indiqués à l’heure et App Engine. Pour 1 an : $0,0078/h
mais les factures sont calculées -Un crédit gratuit de A l’utilisation :
à la seconde près. 300$ pour 12 mois pour $0.0096/h
- Ex: EC2 Linux/UNIX c’est à commencer à utiliser -Propose des machines
$0.016 par heure. Google Cloud Platform. virtuelles Windows à
- AWS EC2 offre des instances -Des plans gratuits sans 71% d’économies en
réservées qui offrent un rabais limite de temps. Ex : comparaison avec AWS
jusqu’à 75%. Instance f1-micro avec (Exemple de
-Amazon offre un essai gratuit 0.2 CPU virtuel, 0.60 comparaison)
de 12 mois. Ex : Instance Go de mémoire, soutenu
[Link] avec 720heures/mois par un noyau physique
partagé
- Remises pour
utilisation engagée.
Advantages - Une dominance dans le - Meilleur prix par -Meilleure
marché du Cloud avec la plus rapport à ses documentation pour
grande part depuis plus de dix concurrents. l'utilisateur final et
ans. applications pratiques.
- Réseau mondial privé
- L'éventail des fonctions et des en fibre optique en plus - Avantage de regrouper
services de Cloud Computing d’un réseau échelonné. des projets et des
est non seulement déjà vaste, utilisateurs utilisant déjà
mais encore en croissance. -Sauvegardes Office, SQL Server,
redondantes des SharePoint, .Net, etc.
- Une documentation riche sur données : Stockage
les services et les cas multirégional. - La connexion la plus
d'utilisation. rapide entre le Cloud et
-Forte documentation l'appareil et l'alliance est
- Utiliser FreeRTOS rend tout théorique. plus facile.
plus rapide et plus facile
- Compatible avec tous - Puissant pour mettre
les navigateurs. les applications sur le
Cloud.
- Stabilité de la
connexion entre le
StackDriver et l'IoT
Core.

Disadvantages
- Moins de services IoT - La mise en œuvre de la
-Utilisation complexe des contrairement à AWS ou visualisation de données
services et des fonctions Azure. en temps réel est
complexe.
- Overwhelming amount of
services - L'authentification plus - Interface utilisateur
complexe des appareils complexe.
mène l'utilisateur à
générer les clés publique - Le démarrage d'un

39
 et privée séparément. nouveau service a un
temps de création plus
long que les autres
fournisseurs.

Tableau 8: Benchmark des solutions

3.3 Choix de la solution:
Pour notre projet, nous avons opté pour Google Cloud Platform car il répond largement aux besoins de
notre application :

3.3.1 Google IoT Core :

C’est un service entièrement géré par Google pour connecter et intégrer facilement et en toute sécurité les
données issues d’appareils répartis partout dans le monde. Ce qui le caractérise est qu’il est associé à
d’autres services Cloud tels que Cloud Pub/Sub, Cloud ML Engine, Cloud Dataflow ce qui permet de
former une solution complète de traitement, d’analyse et de visualisation des données IoT.

Figure 17: Services Associés à Cloud IoT Core

Cloud IoT Core est un point d’entré à Google Cloud Platform pour les appareils IoT. Il supporte les
protocoles standards MQTT et http. Pour notre projet, nous avons choisi le protocole MQTT pour assurer
la connexion entre nos cartes électronique et GCP.

• MQTT : est un protocole de messagerie basé sur un modèle publish/subscribe. Il

fonctionne au-dessus du protocole TCP/IP comme protocole de couche Application. Son
modèle de messagerie requiert un broker de messages, tel que le Publisher et le Subscriber
ne se connaissent pas l’un l’autre.

Pour assurer la connectivité via MQTT, Cloud IoT Core dispose de deux composants principaux :

40
 • Device Manager : Il aide à établir l’identité du périphérique et à fournir le mécanisme
d’authentification lors de sa connexion.
• MQTT bridge : Il permet d’établir la première liaison entre nos cartes électroniques et
Cloud IoT Core.

[Link] Procédure de connexion à Google IoT Core

Comme nous l’avons cité précédemment, le protocole qui va nous servir de se connecter à la
plateforme de Google est MQTT. Or, qu’il faut procéder à la configuration des cartes électroniques
pour les authentifier au serveur MQTT en tant que des MQTT clients. Pour cela, il faut :

• Définir l’ID du Client MQTT à partir du chemin spécifié dans GCP pour déclarer les
cartes électroniques. Chacune a un chemin propre à elle, d’où un ID différent.

Projets / PROJECT_ID / emplacements / REGION / registres / REGISTRY_ID / devices / DEVICE_ID

• Associer le client aux certificats de serveur Cloud IoT Core pour s’assurer que la
communication n’est pas faite avec un imitateur plutôt que Google.
• Définir le nom d’hôte MQTT sur « [Link] » ou
« [Link]».
• Spécifier un nom d’utilisateur. Pour de meilleurs résultats, indiquer un utilisateur
arbitraire tel que « unused » or « ignored »
• Définir un mot de passe qui est le JWT. Apres chaque temps d’expiration, un nouveau
JWT doit être créé par le client Mqtt.

Le JWT est composé de trois sections: L’entête, la charge et la signature.

• L’entête : est constitué de deux champs, l’algorithme de signature et le type de Jeton.

Pour les clés RSA: {"alg": "RS256", "typ": "JWT"}

Pour les clés à courbe elliptique : {"alg": "ES256", "typ": "JWT"}

• La charge : est constituée de trois champs : iat (la date de création du jeton), exp (la
date d’expiration) et l’aud (l’ID du projet sur Cloud IoT Core).
• La signature : Pour calculer la signature, il faut signer l'en-tête codé base64url, la
charge codée base64-url et une clé secrète à l'aide de l'algorithme défini dans l'en-tête.

Comme les jetons ont des dates d'expiration, si un périphérique est connecté via MQTT et que son
jeton expire, il se déconnecte automatiquement du Cloud IoT Core. La figure ci-dessous montre le
processus de connexion au MQTT Bridge.

41
 Figure 18 : Authentification à Google Cloud IoT Core
Une fois la connexion est établie, les cartes électroniques commencent à publier les données vers le pont
mqtt qui lui-même se charge de guider toutes la télémétrie vers Cloud Pub/Sub.

3.3.2 Cloud Pub/Sub :

C’est un service de messagerie en temps réel entièrement géré qui permet d’envoyer et de recevoir des
messages entre des applications indépendantes. Cloud Pub / Sub est conçu pour fournir une diffusion «au
moins une fois» à faible latence avec une évolutivité à la demande allant jusqu'à 1 million de messages
par seconde (et au-delà).

Une fois que nos données sont dans Cloud Pub/Sub, elles le sont dans Google Cloud et on pourra les
consommer vers la nouvelle station de notre application.

3.3.3 Cloud Functions :

C’est une solution de calcul sans serveur de Google qui nous a servi de couche de connexion, entre les
différents services de Google Cloud Platform (GCP) en écoutant et en répondant aux événements.

Dans notre cas, nous avons développé une application en JavaScript qui se déclenche par des événements
de Cloud Pub/Sub c'est-à-dire que chaque fois une donnée est envoyée à Cloud Pub/Sub, la fonction sera
appelée pour rediriger cette donnée vers sa nouvelle station qui est Firebase.

42
 Figure 19 : Processus de déclenchement de Google Cloud Functions

3.3.4 Firebase :
Un service de Stockage de Google, qui nous a permis de stocker en temps réel toutes les données qui
concernent les pannes. Firebase propose deux types de base de données : Firestore et Realtime
database.

Real Time Database Firestore

Data Model Il stocke les données sous forme d'un grand arbre Il stocke les données sous forme de
JSON documents organisés en collections.

Real time and Il fournit une prise en charge hors ligne Il stocke les données sous forme de
offline support uniquement pour les clients mobiles Android et documents organisés en collections.
iOS. il fournit un support hors ligne pour
les clients Android, iOS et Web

Transactions L'écriture fonctionne comme une opération Il met en lots des opérations et les
individuelle et les transactions utilisent un rappel complète automatiquement
dans le SDK natif

Scalability Partage de données sur plus de 100 000 Met à l'échelle les données
connexions simultanées automatiquement et le sharding n'a
pas lieu

Seules les règles de base de données Firebase Il a une sécurité plus puissante qui
Security s'appliquent utilise IAM

Pricing Prix plus élevé pour la bande passante et le Frais inférieurs pour les opérations de
stockage lecture, d'écriture et de suppression

Nous avons choisis pour notre application Firestore.

43
3.3.5 Firestore :
C’est une base de données en temps réel NoSQL, hébergée dans le Cloud et extrêmement évolutive. Pour
structurer nos données, on a définit des collections telle que chacune représente une rame. Chaque
collection contient plusieurs documents. Chaque document contient des champs contenant les données
réelles d’une seule panne. Le choix de Cloud Firestore est basé sur le fait qu’il dispose d’un kit de
développement logiciel (SDK) pour les applications mobiles (Chapitre 4).

Figure 20 : Capture de la base de données Firestore

44
3.4 Architecture général de la partie Cloud

Figure 21: Architecture de la partie Cloud

4 Conclusion :
Dans ce troisième chapitre, on aura donc vu une définition du Cloud Computing, ses cinq caractéristiques
essentielles puis les cinq types principaux des services Cloud (PaaS, SaaS, IaaS, FaaS, BaaS). Ensuite,
nous avons élaboré un benchmark entre trois solutions Cloud majeurs : Microsoft Azure, Amazon Web
Services et Google Cloud Platform. Et finalement, le choix de la solution, et les services utilisés pour
notre système de diagnostic en ligne. Vers la fin de cette deuxième partie du Cloud, on aura donc notre
data stockée dans la base de données Firestore pour être visualisé via une application mobile.

45
Chapitre IV
Conception et réalisation d’une Interface Graphique
-Application Mobile-

Ce chapitre représente la troisième étape du projet qui est la conception d’une interface graphique,
pour la visualisation des pannes. Nous avons choisi comme interface, une application mobile Android car
c’est la plus pratique dans l’utilisation pour les superviseurs. On verra donc en premier lieu une
présentation du système Android. Puis, en deuxième lieu les besoins et les spécifications que doit vérifier
notre application mobile. On élaborera, en troisième lieu les différents diagrammes UML pour la phase
conception. Vers la fin, nous présenterons l’environnement de développement, les langages de
programmation, les services Cloud utilisés et le résultât final des interfaces de notre application.

46
Chapitre 4 : Conception et Réalisation d’une application mobile

1 Introduction
A cet étape du projet, l’acquisition le traitement, et l’envoie des informations sur les pannes sont faits. On
arrive à la visualisation sous forme d’une application mobile sous Android. L’objectif du projet sera
accompli donc lorsque l’utilisateur final, aie entre ses mains une belle et simple application, qui lui
affiche d’une manière structurée les pannes sur les vingt-quatre rames qui supervise.

2 Présentation d’Android
2.1 Définition
Android est le système d’exploitation mobile de Google open-source fondé sur un noyau Linux
monolithique. Il équipe la majorité des appareils électroniques du marché dont l’architecture est : ARM
(Téléphones mobiles et tablettes), MIPS (Console de jeux vidéo, etc...) ET x86.

L’histoire d’Android commence en octobre 2003, lorsqu’Andy Rubin, Rich Miner, Nick Sears et Chris
White créent la société Android à Palto Alto en Californie. Google a racheté la société en août 2005.
Deux ans plus tard, l’Open Handset Alliance est annoncée et Android devient officiellement open source.

La première version du SDK Android 1.0 sort le 23 septembre 2008 avec le premier téléphone sous
Android (HTC Dream). En Septembre 2019, la dernière version stable 10.1 d’Android sort, tout en
passant par un ensemble de versions qui propose de nombreuses modifications et nouveautés comme le
montre le tableau ci-dessous :

Nom Version Date Niveau d’API

Android 1.0 1.0 23 Septembre 2008 1
Android 1.1 1.1 9 Février 2009 2
Cupcake 1.5 30 Avril 2009 3
Donut 1.6 15 Septembre 2009 4
Eclair 2.0 - 2.1 12 Janvier 2010 5-7
Froyo 2.2 – 2.2.3 21 novembre 2011 8
Honeycomb 3.0 - 3.2.6 Février 2012 11-13
Gingerbread 2.3 -2.3.7 21 Septembre 2011 9 – 10
Ice Cream Sandwich 4.0.1 – 4.0.4 29 mars 2012 14 – 15
Jelly Bean 4.1 – 4.3.1 3 octobre 2013 16 – 18
KitKat 4.4 – 4.4.4 20 juin 2014 10 – 20
Lollipop 5.0 – 5.1.1 Octobre 2014 21 – 22
Marshmallow 6.0 – 6.0.1 Mai 2015 23
Nougat 7.0 – 7.1.1 Septembre 2016 24 – 25
Oreo 8.x.x Octobre 2017 26 – 27
Pie 9.x Aout 2018 28
Tableau 9: Historique des versions du système Android

47
2.2 Architecture
La figure suivante schématise l'architecture d'Android :

Figure 22 : L'architecture d'Android

On peut observer toute une pile de composants qui constituent le système d’exploitation d’Android. Le
premier élément de cette pile est le noyau Linux :

• Noyau linux :

Le système d’exploitation d’Android s’appuie sur un noyau Linux. Cette version de Linux est
conçue spécialement pour l’environnement mobile, avec une gestion avancée de batterie et une
gestion particulière de mémoire. Le noyau est l’élément du système qui permet de faire le pont
entre le matériel et le logiciel via des programmes pilotes comme le montre la figure.

Le deuxième élément de la pile ; les librairies.

• Librairies :
A ce niveau, on trouve la couche des bibliothèques principales du système fournies par des
tiers. Ces bibliothèques, de bas niveau, sont écrites en C et/ou C++. Elles fournissent des services
essentiels tels que la bibliothèque d’affichage en 2D (SGL), la bibliothèque d’affichage graphique
3D (OpenGL), la bibliothèque de base de données (SQLite), la lecture et l’enregistrement audio et
vidéo (Media Framework), un moteur de navigation Web (WebKit) ... etc.
48
Le deuxième élément de la pile est partagé également avec Android Runtime.

• Android Runtime (Le moteur d’exécution linux) :

Un moteur d’exécution en général est un programme qui permet l’exécution de d’autres programmes. A
titre illustratif, pour développer une application en Java standard sur le PC, on aura besoin du JRE (Java
Runtime Environement). Or, pour développer en Android, ce n’est pas la même logique d’exécution.
Tout d’abord, la version Java pour Android est une version réduite amputée de certaines fonctionnalités,
ainsi il n’utilise pas une machine virtuelle Java mais plutôt une machine virtuelle Dalvick développée
pour les systèmes embarqués.

Figure 23 : Machine virtuelle Dalvick

D’après ce schéma, le code Source Java est converti en bytecode Java comme dans le cas du Java
Standard. Or que ce bytecode ne pouvait être lu que par une machine virtuelle Java. Et comme Dalvick
n’est pas une machine virtuelle Java, donc il faut procéder à une autre conversion à l’aide du programme
« dx ». Ce programme s’occupe de traduire le bytecode Java en bytecode Dalvick, qui est compréhensible
par la nouvelle machine virtuelle.

Le troisième élément de la pile est Framework Android.

• Framework Android :

Le framework Android fournit des API permettant aux développeurs de créer des applications riches. Ces
API fournissent des services qui n’ont aucune interaction avec l’utilisateur et qui tourne en arrière plan :

- Activity Manager : gère le cycle de vie des applications et maintient une "pile
de navigation" (navigation backstack) permettant d'aller d'une application à une

49
 autre et de revenir à la précédente quand la dernière application ouverte est
fermée.
- Package Manager : utiliser par l'Activity Manager pour charger les informations
provenant des fichiers .apk.
- Content Provider : gère le partage de données entre applications, comme par
exemple la base de données de contact, qui peut être consultée par d'autres
applications que l'application Contact. Les Données peuvent partager à travers
une base de données (SQLite), des fichiers, le réseau, etc
- View System : fournit tous les composants graphiques : listes, grille, text box,
buttons et même un navigateur web embarqué

Ils fournissent également des services matériels qui eux-mêmes fournissent un accès vers les API
matérielles de bas niveau :

- Telephony Service : permet d'accéder aux interfaces "téléphonique" (GSM, 3G,

etc.)
- Location Service : permet d'accéder au GPS.
- Bluetooth Service : permet d’accéder à l’interface Bluetooth.
- USB Service : permet d'accéder aux interfaces USB.
- ETC…

On arrive finalement au dernier élément de la pile d’architecture.

• Les applications :

Ces applications peuvent être, bien sûr, les applications tierces téléchargées sur le magasin d’application
officiel, mais également des applications installées par défaut, telles que l’application d’accueil (aussi
appelée Launcher), le navigateur web, les applications de SMS et téléphonie, etc. Toutes ces applications
sont communément développées en Java

2.3 Les applications Android :

Une application mobile est un logiciel applicatif développé pour un appareil électronique mobile tel
qu’un assistant personnel, un téléphone portable, une tablette tactile, etc…

Une application mobile Android est spécifiquement développée pour les appareils qui utilisent le système
Android.

Sous Android, chaque application est composée de plusieurs activités. Chacune représente un écran de
l'interface utilisateur de l'application Android.

L'application Android commence par afficher l'activité principale et à partir de là, elle peut permettre
d'ouvrir des activités supplémentaires.

2.3.1 Etats d’une activité

Une activité peut se trouver dans différents états : en cours d’exécution, en pause, stoppé et tué.

▪ En cours d’exécution :
L’activité se trouve au premier plan et reçoit les interactions utilisateurs.

50
 ▪ Pause :
L’activité est visible mais l’utilisateur ne peut pas interagir avec (cachée par une boîte dialogue
par exemple). La seule différence avec l’état précédent est la non-réception des évènements
utilisateurs.

▪ Stoppé :
L’activité n’est plus visible mais toujours en cours d’exécution. Toutes les informations
relatives à son exécution sont conservées en mémoire. Quand une activité passe en état stoppé,
vous devez sauvegarder les données importantes et arrêter tous les traitements en cours
d’exécution.

▪ Tué :
L’activité est tuée, elle n’est plus en cours d’exécution et disparaît de la back Stack. Toutes les
données présentes en cache non sauvegardées sont perdues.

2.3.2 Cycle de vie d’une activité sous Android

Le cycle de vie d’une activité correspond aux différents états d’une activité lors de sa gestion par le système
Android. La figure ci-dessous décrit les étapes de ce cycle de vie :

Figure 24 : Cycle de vie d'une activité

51
Sous Android, chaque application s’exécute selon un processus bien déterminé, qui se définit par le cycle
de vie de ses activités.
A ce processus, s’ajoute la gestion du système d’exploitation Android des différentes applications qui se
trouve dans la dernière couche de sa pile. Cette gestion touche essentiellement aux ressources disponibles
dans un appareil et peut, ci-besoin, fermer des applications pour libérer quelques ressources.
Le choix de l’application à fermer dépend fortement de l’état du processus dans lequel elle se trouve. Si
Android doit choisir entre deux applications se trouvant dans le même état, il choisira celle qui se trouve
dans cet état depuis plus longtemps.
Le cycle de vie d’une application est complexe, cependant sa compréhension est indispensable pour un
développeur Android. Le schéma ci-dessus décrit ce cycle de vie.
• Lancement de l’activité :
Lorsqu’elle est lancée, le système Android fait appelle à la méthode « onCreate ». Celle-ci, se charge par
l’initialisation des éléments qui forment la vue. Elle prend en paramètre aussi un Bundle (pile) contenant
l’état précédent de l’activité. Par la suite, cet appel est suivi par « onStart » pour signaler le lancement
effectif de l’activité (Elle est visible à ce point), puis par « onResume » afin d’exécuter tous les
traitements nécessaires au fonctionnement de l’activité que ce soit un thread, processus ou traitement.
Apres ces trois appels, l’activité devient utilisable et peut agir avec les interactions de l’utilisateur.
• Une deuxième activité se lance :
Lorsqu’une activité n’est plus dans le premier plan. Android fait appel à «onPause», mais avant à la
méthode « onSaveInstanceState » pour la sauvegarde de l’état de l’activité. Cet état pourra être appliqué
aux futurs lancements de cet activité lors de l’appel à la méthode « onRestoreInstanceState » ou de
l’appel à «onCreate ». Quand l’activité est à nouveau visible, cela correspondra à un appel de
«onResume ».
• L’arrêt de l’activité :
Lorsqu’une activité passe à l’état stoppé, ceci correspond à l’appel de la méthode «onStop ».
Deux cas se posent :
- Soit être relancée : cela s’effectue par un appel à la méthode « onRestart » suivi du cycle de vie
normal de l’activité.
- Soit être tuée : cela s’effectue par un appel à la méthode « onDestroy », dans laquelle tous les
traitements restants sont arrêtés. Vous pouvez provoquer l’appel à la méthode « onDestroy » en utilisant
la méthode finish.

52
 3 Spécification des besoins
Cette partie servira de spécifier les bases du système à réaliser et aussi pour pouvoir clarifier les besoins
des utilisateurs de notre application. On présentera donc les besoins fonctionnels ainsi que les besoins non
fonctionnels.

3.1 Les besoins fonctionnels

Dans cette étape, nous détaillons les fonctionnalités. Ce sont les besoins spécifiant un comportement
d'entrée / sortie du Système

• Gérer les utilisateurs : gérer l’attribution des droits d’accès aux données, seules les identifiants
pré déclarés sont autorisé à consulter l’application.
• Consulter l’état des rames : La solution doit offrir une visualisation en premier lieu du nombre
de pannes sur chaque rame.
• Consulter les pannes : La solution doit offrir la visualisation; pour chaque rame ; des pannes qui
existent ainsi que son code référentiel, sa date d’occurrence, la voiture, et l’équipement qui l‘a
déclarée.
• Gérer les pannes : La mise à jour des pannes par l’ajout de nouvelles ou la suppression de celles
qui seront corrigées.

3.2 Les besoins non fonctionnels

Il s’agit des besoins en matière de qualité de l’application et qui doivent répondre aux attentes du client.
Notre application doit nécessairement assurer les besoins suivant :

• L'extensibilité : l'application devra être extensible, c'est-à dire qu'il pourra y avoir une
possibilité d'ajouter ou de modifier de nouvelles fonctionnalités.
• La sécurité : L’application devra être hautement sécurisée, les informations ne devront pas
être accessibles à tout le monde, c'est-à-dire que l'application est accessible que par un
identifiant et un mot de passe attribué au département de l’entreprise.
• La performance : L'application doit être performante c'est -à-dire que le système doit réagi
dans un délai précis, quelque soit l'action de l'utilisateur.
• La convivialité : L'application doit être simple et facile à manipuler par des noms experts.
• L'ergonomie : Le thème de l'application doit être inspiré des couleurs et du logo de
l’entreprise

53
 4 Analyse des besoins :
L’objectif de l’analyse est d’accéder à une compréhension des besoins et des exigences du client. Il s’agit
de livrer des spécifications pour permettre de choisir la conception de la solution.

4.1 Identification des acteurs :

Un acteur représente un élément externe qui interagit avec un système dans le but de le faire fonctionner
et d'en tirer profit. Dans notre cas, on dispose de deux acteurs :
• Le superviseur : C’est un acteur principal dans notre application, il s’occupe du suivi de l’état
électromécanique des rames à distance, par la consultation des pannes actives.
• L’Admin : C’est un acteur principal aussi, son rôle est la gestion des utilisateurs qui peuvent
accéder aux systèmes, ainsi que la gestion des publications qui concernent les pannes.

4.2 Modélisation du contexte :

Un message représente la spécification d’une communication unidirectionnelle entre objet qui transporte
de l’information avec l’intention de déclencher une activité chez le récepteur. On distingue deux types de
messages :
• Messages Acteur vers le système :
- (M1) Demande d’authentification.
- (M2) Demande de visualisation de la liste des rames en circulation et nombres
des pannes sur chacune.
- (M3) Demande de consultation des informations sur les pannes
- (M4) Mise à jour de la liste de pannes.
- (M5) Mise à jour de la liste des rames en circulation

• Messages système vers l’acteur :

- (M’1) Visualisation de l’interface des rames en circulation et le nombre des
pannes sur chacune.
- (M’2) Visualisation des informations des pannes.
- (M’3) Affichage des messages d’erreurs et de confirmations.
- (M’4) Affichage des notifications.
- (M’5) Affichage de l’interface d’authentification.

54
Tous les messages (Système Acteurs) peuvent être représentés de façon synthétique sur un diagramme
appelé diagramme de contexte. Comme le montre la figure ci-dessous.

Figure 25 : Diagramme de contexte dynamique

4.3 Diagrammes des cas d’utilisation

Le diagramme de cas d’utilisation fait partie des diagrammes de langage de modélisation graphique
UML. Il est utilisé pour donner une vision globale du comportement fonctionnel d’un système logiciel.
Dans un diagramme de cas d'utilisation, les utilisateurs sont appelés acteurs, ils interagissent avec les cas
d'utilisation (use cases).
Un cas d'utilisation est une unité cohérente représentant une fonctionnalité visible de l'extérieur. Il réalise
un service de bout en bout, avec un déclenchement, un déroulement et une fin, pour l'acteur qui l'initie.

4.3.1 Identification des cas d’utilisation

Pour chacun des deux acteurs définis précédemment, on associe des cas d’utilisation qui lui correspond.

Cas d’utilisation Acteur

Gérer l’utilisateur Admin
Gérer la liste des pannes Admin
Consulter la liste des pannes Superviseur
Consulter la liste des rames en circulation Superviseur
Tableau 10 : Cas d'utilisation selon chaque acteur

55
 4.3.2 Diagramme de cas d’utilisation global
Nous avons regroupé l’ensemble des cas d’utilisations dans le diagramme suivant :

Figure 26: Diagramme des cas d'utilisation global

56
 4.3.3 Diagrammes de cas d’utilisation détaillés:
- Côté « Admin » :

Figure 27: Diagramme du cas d'utilisation associé à Admin

- Description des cas d’utilisation :

Le tableau ci-dessous présente une description des deux cas d’utilisation associés à l’Admin.

Cas d’utilisation Gérer l’utilisateur Gérer la liste des pannes

Acteur Admin Admin
Objectif Mise à jour des utilisateurs Mise à jour de la liste des rames
Pré-condition Authentification Authentification
Scénario normal -Le système affiche l’interface - Le système affiche l’interface qui affiche les
d’authentification. informations sur les pannes.
-L’utilisateur rempli les - L’Admin enregistre les mises à jour sur Firebase.
champs e-mail et mot de passé. -Le système fait appel à ces mises à jour,
-ce cas d’utilisation intervient et les enregistre sur l’interface correspondante.
dans la vérification la validité
des champs, s’ils sont
prédéfinis dans la table « user »
sur Firebase
-La table « user » pourra être
modifiée de telle sorte à ajouter
ou supprimer ou modifier un
utilisateur.
57
Alternatif Si les champs ne sont pas Si la mise à jour n’est pas réussie, un message
valides, le système affiche un s’affiche indiquant le type d’erreur.
message d’erreur et réaffiche
l’interface d’authentification.

Tableau 11: Description des cas d'utilisation de l'acteur Admin

- Côté « Superviseur »:

Figure 28: Diagramme des cas d’utilisation associé au superviseur

- Description des cas d’utilisation :

Le tableau ci-dessous présente une description des deux cas d’utilisation associés à l’acteur superviseur.

Cas d’utilisation Authentification Consulter la liste des Consulter la liste des

rames pannes
Acteur Superviseur Superviseur Superviseur

Objectif Vérifier le droit d’accès à Consultation la liste des Consultation de la liste

l’application. rames des pannes
Pré-condition Authentification Authentification
Scénario normal -Le système affiche l’interface - Le système affiche - Le système affiche
d’authentification. l’interface qui affiche les l’interface qui affiche les
-L’utilisateur rempli les icones des rames. informations sur les
champs e-mail et mot de pannes.
passé.
-Le système vérifie l’existence
58
 de l’utilisateur.
-Le système donne accès à
l’interface qui suit.
.
Alternatif Si les champs ne sont pas
valides, le système affiche un
message d’erreur et réaffiche
l’interface d’authentification.

Tableau 12: Description des cas d'utilisation associés au superviseur

5 Conception
La démarche de conception est une étape fondamentale dans le processus de développement puisqu’elle
fait correspondre la vision applicative à la vision technique.

Ce chapitre vise à illustrer la phase de conception et les modèles UML associés.

5.1 Diagrammes de séquences des cas d’utilisations :

Les diagrammes de séquences sont la représentation graphique des interactions entre les acteurs et le
système selon un ordre chronologique.

Dans ce qui suit, nous allons élaborer les diagrammes de séquences des principales interactions dans
notre système.

59
 5.1.1 L’authentification
L’utilisateur doit s’authentifier, en saisissant une adresse e-mail et un mot de passe. Puis le système
vérifie leur validité grâce à la table des utilisateurs dans Firebase. Si les champs saisis sont valides, le
système affiche l’interface correspondante au rôle de l’utilisateur, sinon un message d’erreur s’affiche.

Figure 29 : Diagramme de séquence du cas d'utilisation "s'authentifier"

60
 5.1.2 Gestion de la liste des pannes:
Le diagramme ci-dessous résume le cas d’utilisation « Gérer la liste pannes ».Une panne soit elle est
ajoutée ou modifier. Toutefois, la seule modification possible concerne le champ « State » et par défaut sa
modification implique la suppression de la panne qui a subie la modification.

S’Authentifier

Figure 30:Diagramme de séquence du cas d'utilisation "Gestion de la liste des pannes"

61
 5.1.3 Consultation des pannes :
Le diagramme ci-dessous résume les étapes de consultation des pannes.

S’Authentifier

Figure 31:Diagramme de séquence du cas d'utilisation "consulter les pannes "

5.1.4 Consultation des rames:

Le diagramme ci-dessous résume les étapes de consultation des rames par un Superviseur.

Figure 32: Diagramme de séquence du cas d'utilisation "consulter les rames "

62
5.2 Diagramme de Classe
Un diagramme de classe est un schéma utilisé en génie logiciel pour la représentation des classes, les
interfaces des systèmes ainsi que les différentes relations entre celles-ci.

Nous allons donc élaborer pour cette phase de conception un diagramme de classe global.

Figure 33 : Diagramme de classe Global

63
6 Réalisation et développement
A cette phase, on est pratiquement à la fin du processus de développement. On verra donc pour conclure
une présentation de l’environnement de développement, les outils et les langages de programmation, ainsi
que les services Cloud utilisés.

6.1 Environnement de développement

• Android Studio
Android studio est un environnement de développement des applications mobile Android,
lancé en première version par Google en décembre 2014. Il est basé sur Intellij IDEA et
utilise le moteur de production Gradle.
Il permet principalement d’éditer les fichiers Java/Kotlin et les fichiers de configurations
XML d’une application Android. Parmi ses fonctionnalités de base, qu’il intègre un
émulateur permettant de faire tourner un système Android virtuel sur un ordinateur et un
éditeur complet avec une panoplie d’outils pour accélérer le développement de l’application.

6.2 Langages de développement

• Java
C’est un langage de programmation orienté objet créé par James Gosling et Patrick
Naughton. La particularité de Java est qu’il permet de créer des logiciels compatibles avec de
nombreux systèmes d’exploitation tels qu’Unix, Windows, Mac OS ou GNU/linux. Java
offre aussi la possibilité de développer des programmes pour les téléphones portables et
assistants personnels.

• JavaScript
C’est un langage de programmation de scripts employé en premier lieu dans les pages web
interactifs et les serveurs. Il est considéré comme l’une des technologies cœur du www. Il a
été crée en 1995 par Brendan Eich et c’est le langage qui possède le plus large écosystème
grâce à son gestionnaire de dépendances npm, avec environ 500 000 paquets en 2017.

• XML
C’est un langage puissant et extensible qui permet de décrire à l’aide de balises un ensemble
de données. Il a été crée pour faciliter les échanges de données entre les machines et les
logiciels. A cela, s’ajoute un autre objectif qui est la description des données d’une manière
aussi bien compréhensible par les hommes que les machines. XML est standardisé par le
W3C en février 1998 et depuis il est largement utilisé.
• JSON
JavaScript Object Notation est un format de données textuelles. Il est facile à lire et à écrire
pour des humains et aisément analysable par des machines. Il est basé sur un sous-ensemble
du langage de programmation JavaScript. JSON se base sur deux structures :

- Des ensembles de paires nom/valeur.

- Une liste de valeurs ordonnées.

Le format JSON est largement utilisé pour récupérer des informations concernant les utilisateurs d'un site
web.

64
6.3 Services Cloud :
• Firebase
C’est un ensemble de services d’hébergement pour tout type d’application (Android, iOS,
JavaScript, Unity, C++…). Il propose d’héberger en NoSQL, et en temps réel des bases de
données, du contenu, de l’authentification, et des notifications. Il a été lancé premièrement en
2011 sous le nom d’Envolve, pour être acheté par la suite par Google

• Firebase authentification
C’est le service authentification de Firebase, il fournit des services de back-end, des kits de
développement logiciel (SDK) faciles à utiliser et des bibliothèques d'interface utilisateur
prêtes à l'emploi pour authentifier les utilisateurs auprès des applications. Firebase
authentification prend en charge l’authentification à l’aide de mot de passe, de numéro de
téléphone, et des fournisseurs d’identités tels que Google, Facebook…etc

• Firestore
C’est un service de stockage sous forme de base de données NoSQL flexible et évolutive
pour stocker et synchroniser les données pour le développement côté client et serveur.
Firestore permet l’intégration transparente avec les autres produits de Firebase et Google
Cloud Platform.
Les cinq caractères principaux de Firestore :

- La flexibilité : Structuration hiérarchique des données sous forme de

collections/documents.
- Interrogation expressive : Réponse aux requêtes d’écoute et d’extraction.
- Mises à jour en temps réel : Mise à jour ponctuelle des données sur chaque
périphérique connecté.
- Support hors ligne : Synchronisation des données misent en cache lorsque
l’appareil revient en ligne.

65
6.4 Les interfaces du système :

Figure 34 : Interface Authentification Figure 34 : Interface liste des rames

Figure 35: Interface liste des pannes

66
Conclusion
Dans ce dernier chapitre, nous avons tout d’abord décrit le système Android, son architecture et ses
versions à travers le temps de son évolution. Ceci, nous a permis de bien comprendre son fonctionnement.
Ensuite, nous avons spécifié les besoins et les objectifs de notre application mobile à l’aide des
diagrammes de cas d’utilisation. Après, pour la phase conception, nous avons élaboré des diagrammes de
séquences relatifs à chaque cas d’utilisation, ainsi que le diagramme de classe global. Finalement, nous
avons présenté l’environnement de développement, les langages de programmation, les services Cloud
utilisés et le résultât final des interfaces de notre application.

67
Conclusion générale et perspectives
Le transport ferroviaire marque une prédominance dans le trafic voyageur. Chaque jour, un nombre
important de personnes l’utilise pour assurer un voyage de longue distance ou pour des navettes. La sécurité
donc de ces clients et la qualité du service forment une priorité, qu’il faut mettre en considération pour
garder cette position de dominance.

Lorsqu’on parle de cette priorité, on inclut la qualité de la logistique c'est-à-dire l’état des rames. Pour cela,
nous avons pensé à un système intelligent qui pourra faire le suivi de l’état électromécanique de ces rames
tout le long de son trajet de circulation.

Cette solution est une action préemptive contre les anomalies qui peuvent surgirent lors de la circulation et
au milieu de nulle part.

Ce rapport présente les étapes initiales de la réalisation de ce projet. Nous avons tout d’abord, exposé
l’organisme d’accueil, en faisant un aperçu sur l’office national des chemins de fer. Ensuite, nous avons
présenté la première étape dans la réalisation du projet qui est l’extraction et le filtrage des données, pour
cela nous avons décrit le fonctionnement interne du réseau de communication au sein des véhicules qui
forment la rame. Puis les deux méthodes d’extraction, une est adoptée par l’entreprise pour des extractions
sur place, l’autre est proposée spécialement pour ce projet. Après, pour la deuxième étape qui est l’envoi des
données au Cloud, nous avons présenté le domaine du Cloud Computing, ses différents services et outils.
Ainsi que la plateforme que nous avons utilisée. Finalement, pour la troisième partie nous avons présenté
l’univers d’Android et le processus de développement de notre application mobile pour la visualisation des
données extraites durant la première étape.

Ce projet a fait l’objet d’une expérience intéressante, car il touche à plusieurs domaines : l’électronique, le
Cloud Computing et le développement des applications mobiles. Lors de sa réalisation, j’ai pu mettre en
pratique mes connaissances théoriques et d’acquérir d’autres notamment dans le Cloud Computing et le
développement mobile.

Bien que le projet ne soit pas encore fini, nous avons l’intention de le compléter et de l’améliorer en termes
de design et en termes de d’autres fonctionnalités qu’on pourra ajouter telles que l’envoi des commandes
dans le sens contraire pour agir sur des actionneurs afin d’intervenir rapidement et facilement lors des
anomalies.

68
BIBLIOGRAPHIE

[Link]

[Link]

[Link]

[Link]

[Link]

[Link]

[Link]

69