Rapport de Stage PFE Semah BELHADJ DIT MDALSI

Code PFE : I-212-23
Ministère de l’Enseignement Supérieur et de la Recherche Scientifique
Université de la Manouba
Institut supérieur des Arts Multimédias
Mémoire de fin d’études
Préparé en vue de l’obtention du Diplôme National d’Ingénieur en

Sciences Appliquées et en Technologie
Concevoir et mettre en œuvre un simulateur de

contrôle du trafic aérien "Aero SimEx"
Réalisé par
Semah BELHADJ DIT MDALSI
Encadré par
Mme Imen BOUZIRI – ISAMM
M. Firas BEN SALAH – AVAXIA GROUP
Année universitaire : 2022/2023

Dédicaces
Au Dieu le tout puissant, notre créateur
À mes chers parents

Vous m’avez rempli de tendresse et d’espoir tout au long de ma scolarité.
Quoi que je dise, je ne pourrai jamais vous remercier autant que vous le méritez.
Votre présence à mes côtés a toujours été ma source de force pour surmonter les
différents obstacles.
À mes frères
Je vous remercie du fond du cœur pour votre présence et votre soutien
inconditionnels, je suis vraiment reconnaissant de vous avoir comme frères.
À mes grands-parents
Je tiens à vous exprimer ma profonde gratitude pour votre soutien moral inestimable.
Votre présence constante, vos encouragements et vos prières m’ont donné la force et
la confiance nécessaires pour surmonter les défis et poursuivre mes objectifs.
À tous mes chers amis

Je souhaite exprimer ma plus profonde reconnaissance pour votre soutien moral et
physique précieux. Vos encouragements constants et votre amitié sincère ont été un
pilier essentiel dans ma vie.
Semah BELHADJ DIT MDALSI

Remerciements
Je tiens tout d’abord à remercier, toute l’équipe pédagogique de

l’Institut Supérieur des Arts Multimédia de la Manouba pour leurs
efforts, leur soutien et leurs conseils durant ma formation.
Je tiens à exprimer également ma profonde gratitude envers

AVAXIA pour son accueil chaleureux et l’opportunité précieuse qui m’a été offerte
d’effectuer mon stage au sein d’un environnement professionnel aussi enrichissant.
Je remercie Mme Imen BOUZIRI pour sa volonté d’accepter de me superviser et

pour tout le temps qu’elle m’a accordé.
Je remercie M Firas BEN SALAH l’encadrant de l’entreprise AVAXIA pour son

accueil et pour la confiance qu’il m’a accordée dès mon arrivée à l’entreprise et pour
son encadrement tout au long du projet.
Je m’adresse aussi mes vifs remerciements aux consultants de

AVAXIA pour leurs conseils techniques et fonctionnels.
Enfin, je remercie toutes les personnes qui ont aidé à réaliser ce projet de fin
d’études.
i
Table des matières
Introduction générale 1
1 Cadre du projet 3
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1 Présentation de Avaxia Group . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Contexte général du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.1 Description de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Applications Similaires : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5.1 ATC Simulator 2 : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5.2 ATC Pro : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.6 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.7 Méthodologie de gestion de projet . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.8 Langage de modélisation UML - Unified Modeling Language . . . . . . . . . . . 13
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2 Spécification des besoins 14

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.2 Les besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.3 Les besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Diagramme du cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3 Style architectural . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.1 Définition des architectures microservices . . . . . . . . . . . . . . . . . . 19
ii
2.3.2 Définition des architectures 3-tiers . . . . . . . . . . . . . . . . . . . . . . 19
2.3.3 Définition des applications Multi-Frontend . . . . . . . . . . . . . . . . . 19
2.3.4 Les niveaux de l’architecture d’AeroSimex . . . . . . . . . . . . . . . . . 19
2.4 Pilotage du projet avec Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.1 Identification de l’équipe SCRUM . . . . . . . . . . . . . . . . . . . . . . 21
2.4.2 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.3 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5.3 Technologies et langages . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3 Release 1 : Radars liés au simulateur 3D 26

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1 Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.1 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.2 Spécification fonctionnelle détaillée . . . . . . . . . . . . . . . . . . . . . 29
3.1.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2 Revue du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4 Release 2 : Radars indépendants et réalité virtuelle 47

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.1 Sprint 2 : Radar d’approche et En-Route Radar . . . . . . . . . . . . . . . . . . 49
4.1.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.1.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.1.5 Revue du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.2 Sprint 3 : Représentation de la tour de contrôle . . . . . . . . . . . . . . . . . . 62
iii
4.2.3 Détails des besoins fonctionnelles . . . . . . . . . . . . . . . . . . . . . . 63
4.2.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.2.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Conclusion générale 69
Annexe 70
Netographie 72
iv
Table des figures
1.1 Avaxia Group logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 ATC Simulator 2 [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3 ATC Pro [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1 Les acteurs du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2 Diagramme des cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . . 18
2.3 Schéma de l’architecture microservices d’AeroSimex . . . . . . . . . . . . . . . . 20
2.4 Identification de l’équipe Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1 Le système d’éclairage de l’aéroport . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2 Diagramme de cas d’utilisation du Ground Radar . . . . . . . . . . . . . . . . . 31
3.3 Diagramme de cas d’utilisation du radar de contrôle de la zone . . . . . . . . . . 32
3.4 Raffinement du cas d’utilisation «Donner des instructions aux aéronefs» . . . . 33
3.5 Diagramme d’activité «Sélectionner une instruction à partir d’une liste» . . . . 36
3.6 Diagramme d’États-Transition de la «Procédure de départ» . . . . . . . . . . . 37
3.7 Diagramme d’États-Transition de la «Procédure d’arrivé» . . . . . . . . . . . . . 38
3.8 Tour de piste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.9 Forme initiale du Ground Radar . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.10 Forme initiale du simulateur 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.11 Séléctionner une instruction à partir d’une liste . . . . . . . . . . . . . . . . . . 41
3.12 Interfaces du simulateur 3D et du Ground Radar lors du PushBack . . . . . . . 42
3.13 Bouton de détails et barre des commandes . . . . . . . . . . . . . . . . . . . . . 42
3.14 Erreur de changement de taxi spécifique . . . . . . . . . . . . . . . . . . . . . . 43
3.15 Forme initiale du Radar de contrôle de la zone . . . . . . . . . . . . . . . . . . . 44
3.16 Interfaces du CTR lors de l’atterrissage . . . . . . . . . . . . . . . . . . . . . . . 44
3.17 Interfaces du simulateur 3D lors de l’atterrissage . . . . . . . . . . . . . . . . . . 44
3.18 Instruction «Tourner 360°» dans le radar de contrôle de la zone . . . . . . . . . 45
3.19 Instruction «Tourner 360°» dans le simulateur 3D . . . . . . . . . . . . . . . . . 45
4.1 Diagramme du cas d’utilisation de l’En-Route Radar . . . . . . . . . . . . . . . 51

4.2 Raffinement du cas d’utilisation «Modifier les paramètres des aéronefs» . . . . . 52
4.3 Diagramme d’activité «Modifier l’angle de rotation» . . . . . . . . . . . . . . . . 54
v
4.4 Extrait des positions exactes des aéroports . . . . . . . . . . . . . . . . . . . . . 55
4.5 Chemin de DTTA (Tunis-Carthage) à YMAV (Avalon) . . . . . . . . . . . . . . 55
4.6 Interface de départ de l’aéronef dans l’En-Route Radar . . . . . . . . . . . . . . 56
4.7 Mouvement de l’aéronef dans l’En-Route Radar . . . . . . . . . . . . . . . . . . 56
4.8 Menu des paramètres de l’aéronef dans l’En-Route Radar . . . . . . . . . . . . . 57
4.9 Message d’erreur En-Route Radar . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.10 Modification de l’altitude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.11 Distance entre les aéronefs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.12 Risque de collision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.13 Interface initial de l’Approach Radar . . . . . . . . . . . . . . . . . . . . . . . . 61
4.14 Aéronef dans la zone d’approche . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.15 Menu dans la zone d’approche . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.16 Diagramme de cas d’utilisation de la représentation de la tour de contrôle . . . . 64
4.17 Raffinement du cas d’utilisation «Consulter les écrans du simulateur de contrôle
de trafic aérien» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.18 Diagramme d’activité «Choisir l’écran à visualiser» . . . . . . . . . . . . . . . . 66
4.19 Interface de la représentation de la tour de contrôle . . . . . . . . . . . . . . . . 67
4.20 Choisir un écran . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.21 Choisir l’En-Route Radar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
vi
Liste des tableaux
1.1 Comparaison entre PixiJS et Unity . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1 Backlog du premier Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2 Description textuelle du cas d’utilisation «Sélectionner une instruction à partir
d’une liste» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.1 Backlog du deuxième Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.2 Description textuelle du cas d’utilisation «Modifier la vitesse de l’aéronef» . . . 53
4.3 Description textuelle du cas d’utilisation «Modifier l’angle de rotation de l’aéronef» 53
4.4 Backlog du troisième Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.5 Description textuelle du cas d’utilisation «Choisir l’écrans à visualiser» . . . . . 65
vii
Introduction générale
Le contrôle du trafic aérien (Air Traffic Control : ATC) est un domaine complexe et crucial
qui implique la collaboration et la communication entre de nombreux spécialistes. Il s’agit d’un
système qui gère les mouvements des aéronefs à l’intérieur et autour des aéroports et dans
l’espace aérien. La principale fonction de l’ATC est d’assurer la sécurité, l’ordre et l’efficacité
du trafic aérien.
Les contrôleurs aériens sont des professionnels agréés par l’administration fédérale de l’avia-
tion chargés d’accomplir des tâches essentielles dans le domaine de l’aviation : ils sont respon-
sables de la supervision des itinéraires de vol, de la communication avec les pilotes, de la gestion
des urgences aériennes et de la prévention des collisions d’avions. Les contrôleurs utilisent des
radars et d’autres technologies avancées pour suivre en temps réel la position de chaque avion.
Pour développer des compétences exceptionnelles et se préparer à relever les défis du métier
de contrôleur aérien, les futurs candidats doivent suivre une formation approfondie dans les
écoles de contrôle du trafic aérien.
Pour se familiariser avec les scénarios réels, les candidats utiliser des simulateurs de vol et
des systèmes de contrôle du trafic aérien acquérant ainsi les compétences techniques indispen-
sables pour leur future carrière de contrôleur aérien. Cependant, au-delà des aspects techniques,
ces formations mettent également l’accent sur le développement des aptitudes en gestion du
stress, de la prise de décision rapide et précise, ainsi que sur l’amélioration des compétences en
communication avec les pilotes.
Dans ce contexte, notre projet de fin d’études prend place. Bien que le domaine du contrôle
du trafic aérien puisse être en partie nouveau pour nous, nous avons été motivés à nous y
investir pleinement et à acquérir les connaissances nécessaires pour aborder ce sujet complexe.
Notre objectif principal est de résoudre le problème de l’absence d’un simulateur de trafic aérien
local.
Ce projet a été amorcé il y a quatre ans au sein d’Avaxia, et sa réalisation s’est concrétisée
lors de ce stage de fin d’études.
1
Introduction générale
Le présent rapport est divisé en cinq chapitres présentés comme suit :
— Dans le premier chapitre, nous introduirons le contexte du projet en présentant l’orga-

nisme d’accueil, Avaxia, ainsi que la problématique à résoudre. Nous présenterons égale-
ment le projet et étudierons la situation existante afin de proposer une solution. Enfin,
nous décrirons la méthodologie de travail et la planification du projet.
— Le deuxième chapitre sera consacré à la spécification des besoins. Nous analyserons les
besoins en identifiant les acteurs, les besoins fonctionnels et non fonctionnels. Nous pré-
senterons également le diagramme global de cas d’utilisation, le style architectural de
l’application et le backlog du produit.
— Le troisième chapitre portera sur le premier Release du projet, consacré au développement

des radars liés au simulateur 3D. Nous allons présenter l’ensemble des tâches réalisées
durant ce sprint ainsi que les résultats obtenus.
— Dans le quatrième chapitre, nous allons aborder le deuxième Release du projet, qui sera
dédié au développement des radars indépendants et de la représentation de la tour de
contrôle. Nous allons détailler les différentes étapes de ce sprint ainsi que les résultats
obtenus.
— Enfin, ce rapport se clôturera par une conclusion générale qui récapitulera l’ensemble
du travail réalisé. Nous évaluerons les résultats obtenus par rapport aux objectifs fixés,
mettrons en évidence les contributions du simulateur au domaine du contrôle du trafic
aérien, et discuterons des possibilités d’amélioration et des perspectives futures de déve-
loppement.
Ainsi, à travers ce rapport, nous présenterons une approche complète et détaillée du déve-
loppement du simulateur de contrôle du trafic aérien, en mettant en avant notre engagement à
résoudre les défis du domaine et notre volonté d’apporter des solutions innovantes.
2
Chapitre 1
Cadre du projet
Plan
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1 Présentation de Avaxia Group . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Contexte général du projet . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2.2 Simulation dans l’éducation et les formations : . . . . . . . . 6
1.2.2.3 Simulation dans les écoles de contrôle de trafic aérien : . . . . 6
3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.1 Description de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5 Applications Similaires : . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5.1 ATC Simulator 2 : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5.2 ATC Pro : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7 Méthodologie de gestion de projet . . . . . . . . . . . . . . . . . . . 13
8 Langage de modélisation UML - Unified Modeling Language . . . 13
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Chapitre 1. Cadre du projet
Introduction
Ce chapitre est consacré à la mise en contexte du projet réalisé durant le stage de fin
d’étude. Nous commençons par la présentation de l’organisme d’accueil. Ensuite, nous mettons
en évidence la problématique. Nous étudions l’existant et enfin, nous proposons la solution.
1.1 Organisme d’accueil

Dans cette partie, nous présentons l’entreprise, ainsi que ses services.
1.1.1 Présentation de Avaxia Group
AVAXIA GROUP est une société de conseil en technologie fondée en 1998 dont le siège se
trouve à Dubaï, elle possède des bureaux au Japon et en Tunisie. Elle couvre un large éventail
de domaines et de technologies, visant à répondre aux besoins variés des clients.
Figure 1.1 : Avaxia Group logo
1.1.2 Services
Les secteurs d’activité de AVAXIA GROUP sont le Conseil SAP, la gestion de l’infrastruc-
ture, l’intégration de systèmes et le développement des logiciels. Elle offre une large gamme de
services couvrant ces secteurs.
— Intégration des systèmes : Intégration des données Gestion des flux de données Intégration
des applications, développement et gestion des API : Dell Boomi Atmosphere, gestion des
flux de données NIFI
— BI et Big Data : Capture des données, Modélisation des données, découverte des données,
traitement analytique en ligne, visualisation des données, exploration des données, analyse
prédictive SAP BW, Business Object, Tableau, gestion des big data (Hadoop).
— Nouvelles technologies : Apprentissage automatique, réalité augmentée, réalité virtuelle,

réalité mixte, internet des objets.
— Expertise technique SAP : Gestion de l’infrastructure, optimisation et réglage des per-

formances, conception de l’architecture du paysage, installation, configuration et mise à
4
niveau du système, dépannage et gestion des incidents et Audit du paysage.
— Conseil fonctionnel : Conception de solutions d’entreprise pour un nouveau déploiement

de modules fonctionnels SAP, analyse, reconception et optimisation des processus E2E,
gestion des déploiements fonctionnels et planification des tests (Fit gap, design, UT, etc).
— Solutions logicielles personnalisées : Conception et réalisation de solutions logicielles uti-

lisant : Java JEE, Dell Boomi flow, Salesforce, SAPFIORI, SAPUI5 et plus encore.
En combinant leur savoir-faire avec les dernières avancées technologiques, Avaxia Group se posi-
tionne comme un partenaire de confiance pour accompagner ses clients dans leur transformation
digitale et les aider à tirer pleinement parti de leurs données.
1.2 Contexte général du projet

1.2.1 Présentation du projet
Dans le cadre de notre stage de fin d’études à l’Institut Supérieur des Arts Multimédia, nous
avons entrepris un projet qui vise à mettre en pratique nos compétences et nos connaissances
académiques. Notre objectif principal consiste à développer un logiciel local complet qui four-
nira une formation immersive, réaliste et efficace pour les stagiaires des écoles de contrôle du
trafic aérien. En développant ce logiciel, nous assurons une formation complète qui couvre les
différentes spécialités de l’ATC. Grâce à ces formations, les candidats apprendrons à garantir
une bonne coordination entre les acteurs de l’ATC pour réduire le nombre d’erreurs de contrôle
du trafic aérien et diminuer les risques des accidents catastrophiques.
1.2.2 Simulation
1.2.2.1 Définition
La simulation est une représentation du comportement d’un processus physique, industriel,

biologique, économique ou militaire au moyen d’un modèle matériel dont les paramètres et les
variables sont les images de ceux du processus étudié, les modèles de simulation prennent le plus
souvent la forme de programmes d’ordinateurs auxquels sont parfois associés des éléments de
calcul analogique. [3] La simulation est utilisée lorsque le système réel présente des contraintes
d’inaccessibilité, de danger, d’inacceptabilité, qu’il est en phase de conception, de construction
ou qu’il est inexistant.
5
1.2.2.2 Simulation dans l’éducation et les formations :
La simulation est fréquemment utilisée à des fins pédagogiques, notamment lorsque l’uti-
lisation d’équipements réels dans le monde réel serait soit coûteuse, soit dangereuse pour les
étudiants. Dans de telles situations, les étudiants ont l’opportunité d’acquérir des compétences
précieuses au sein d’un environnement virtuel, tout en bénéficiant d’une expérience réaliste.
1.2.2.3 Simulation dans les écoles de contrôle de trafic aérien :
La simulation est essentielle pour former les contrôleurs de l’aviation, offrant des avantages
tels que la vision 3D, le contrôle météorologique et la flexibilité dans la création et le contrôle
des exercices de simulation (voir annexe).
1.3 Problématique
Actuellement, les écoles d’ATC en Tunisie achètent des simulateurs coûteux de l’étranger
pour former les futurs contrôleurs aériens. Le problème réside lorsque les simulateurs utilisés
ne répondent pas de manière optimale aux besoins de la formation complexe des candidats. De
plus, ces simulateurs étrangers ne sont pas adaptés aux exigences locales ce qui entraîne une
formation inadéquate avec les scénarios réels du trafic aérien national.
1.4 Étude de l’existant

1.4.1 Description de l’existant
Avaxia a commencé le développement d’un simulateur de contrôle de trafic aérien pour

répondre aux besoins croissants des établissements de formation dans ce domaine crucial.
Le simulateur se compose essentiellement de plusieurs segments de systèmes intégrés essen-
tiels pour la formation en contrôle du trafic aérien :
— Frontend DBM : Un tableau de bord utilisé par l’instructeur pour configurer la forma-
tion et l’exercice pour les contrôleurs.
— Backend DBM : Service DBM qui permet à l’instructeur de modifier les données avant
de lancer l’exercice.
— Lanceur : Point d’entrée de l’application qui ouvre l’application souhaitée en fonction

du rôle de connexion.
— Frontend Core : Contient les interfaces en temps réel qui sont utilisées après le lancement
de la formation, telles que l’écran de dépouillement, l’action en direct et la gestion des
6
enregistrements.
— Backend Core : Serveur de communication en temps réel utilisant Socket.io pour relier
toutes les autres applications.
— Moteur 3D : Un simulateur 3D de l’aéroport, développé avec Unity, qui propose une

représentation tridimensionnelle.
— Moteur 2D : Radar au sol (Ground Radar) développé par PixiJS qui représente les
aéronefs au sol présents dans le simulateur 3D.
1.4.2 Critique de l’existant
L’application existante que Avaxia a commencé à développer présente un ensemble de fonc-

tionnalités essentielles pour la formation au contrôle du trafic aérien. Cependant, le radar du
sol existant est développé par PixiJS, et il est important de noter que l’utilisation de PixiJS
pour développer un radar du sol aussi consistant dans l’application peut ne pas offrir la qualité
graphique, l’interactivité et les fonctionnalités avancées requises pour une simulation réaliste du
trafic aérien. Cette technologie présente certaines limites qui méritent d’être prises en compte
dans notre situation. Bien que PixiJS soit réputé pour sa légèreté et ses performances en matière
de rendu 2D, il se peut qu’il ne réponde pas de manière optimale aux besoins de la formation
complexe des futurs contrôleurs aériens.
Le tableau ci-dessous présente une analyse comparative entre les technologies PixiJS et
Unity.
7
Technologie PixiJS Unity
— Principalement utilisé pour — Moteur de développement

le développement de jeux de jeux puissant qui prend
en 2D. en charge à la fois le déve-
Type de loppement de jeux en 2D et
— Se concentre sur les jeux lé-
Développement en 3D.
gers et rapides basés sur na-
vigateur [4] — Offre une large gamme
d’outils et de fonctionnali-
tés, ce qui le rend adapté à
la création de jeux sur plu-
sieurs plates-formes [5]
— Axé sur le rendu graphique — Comprend un éditeur visuel

2D. puissant, des outils de mo-
— Offre des fonctionnalités délisation 3D, des fonction-

Fonctionnalités nalités de physique, un sys-
pour la gestion des sprites,
les animations, les effets vi- tème d’animation avancé,
suels, et les interactions uti- un moteur de particules, et
lisateur [4] bien plus encore.
— Prend également en charge

les scripts visuels, les ef-
fets spéciaux et les plu-gins
tiers. [5]
8
— Principalement utilisé avec — Utilise le langage de script

Langage de Java-Script, qui est un lan- C# et il offre des fonction-
programmation gage de programmation lar- nalités plus avancées et une
gement utilisé pour le déve- meilleure performance pour
loppement web. [4] le développement de jeux
et des applications de diffé-
rentes plate-formes.[5]
Tableau 1.1 : Comparaison entre PixiJS et Unity
Cette application aussi ne dispose pas du radar de zone de contrôle, du radar d’approche
et du radar en route pour couvrir toutes les phases du vol, ce qui permet aux stagiaires de
bénéficier d’une expérience de formation complète et cohérente.
En raison de ces déficiences, l’expérience de formation des stagiaires peut ne pas être com-
plète, ce qui peut entraîner des lacunes dans leur préparation aux situations réelles de contrôle
du trafic aérien.
En résumé, l’application existante présente des lacunes en ce qui concerne les radars néces-
saires à la formation des contrôleurs aériens.
1.5 Applications Similaires :

1.5.1 ATC Simulator 2 :
ATCsimulator 2 est une application de simulation de contrôle du trafic aérien qui vise à
offrir une expérience réaliste aux utilisateurs. [1]
9
Figure 1.2 : ATC Simulator 2 [1]
• Fonctionnalités offertes par ATCsimulator 2 :
— Simulation réaliste : ATCsimulator 2 offre une simulation réaliste du contrôle du

trafic aérien, permettant aux utilisateurs de gérer le trafic aérien.
— Scénarios personnalisés : Vous pouvez créer des scénarios personnalisés en modi-

fiant les paramètres de trafic aérien, de météo et d’aéroport.
— Interface utilisateur intuitive : L’interface utilisateur est conçue pour être convi-
viale, permettant aux utilisateurs de naviguer facilement dans l’application et de
gérer les opérations de contrôle du trafic aérien.
• Quelques fonctionnalités manquantes dans ATCsimulator 2 :
— Absence de simulation 3D : Les utilisateurs ne peuvent pas interagir avec un

environnement virtuel tridimensionnel, ce qui limite l’immersion visuelle et la per-
ception de l’aéroport, des avions et des obstacles de manière réaliste.
— Absence de gestion météorologique : Ce qui signifie que les utilisateurs ne

peuvent pas simuler des conditions météorologiques changeantes.
— Limitation de la varieté des aéroports : Une sélection limitée d’aéroports dis-

ponibles, ce qui pourrait limiter la variété des scénarios de formation possibles.
10
1.5.2 ATC Pro :
ATC Pro simule de manière authentique l’environnement TRACON du contrôle du trafic

aérien, où les avions sont surveillés par radar et guidés vers leur destination dans un rayon de
30 miles autour des principaux aéroports des États-Unis. [2]
Figure 1.3 : ATC Pro [2]
• Fonctionnalités offertes par ATC Pro :
— Simulation réaliste : Les avions commerciaux de la simulation sont générés à partir

des horaires actuels des compagnies aériennes dans le monde réel. Tous les avions se
comportent de manière réaliste en fonction des performances et des caractéristiques
réelles du type d’avion.
— Varieté des aéroports : La version initiale du produit comprend une variété des
aéroports des États-Unis. Chacune d’entre elles est composée de secteurs réalistes
comportant les limites de contrôle, les fréquences et les cartes vidéo utilisées par les
vrais contrôleurs.
— Système métérologique : La météo peut être téléchargée ou personnalisée et

s’affiche de manière réaliste sur l’oscilloscope.
• Quelques fonctionnalités manquantes dans ATC Pro :
— Absence de simulation 3D : Les utilisateurs ne peuvent pas interagir avec un

environnement virtuel tridimensionnel, ce qui limite l’immersion visuelle et la per-
ception de l’aéroport, des avions et des obstacles de manière réaliste.
11
— Coût élevé : ATC Pro est un logiciel commercial, et son coût initial peut être
important. Ce coût peut constituer une limitation pour les école de controle de
trafic aérien ayant des contraintes budgétaires.
1.6 Solution proposée

Cette situation met en évidence la nécessité de concevoir et de développer une solution
nationale, abordable et complète pour répondre aux besoins croissants des établissements de
formation dans ce domaine crucial, garantissant ainsi que la formation dispensée est adaptée
aux exigences locales de l’école. Une telle initiative présente plusieurs avantages significatifs :
— Simulation en 3D : L’inclusion d’un simulateur 3D permettra aux utilisateurs d’inter-

agir avec un environnement modélisé en trois dimensions, ce qui rendra l’expérience de
formation plus immersive et réaliste.
— Réduction des coûts : Le développement d’un simulateur local complet peut être plus
économique à long terme que l’achat d’un simulateur de l’étranger.
— Adaptation aux besoins locaux : Un simulateur de contrôle aérien local peut être
spécifiquement conçu pour répondre aux besoins et aux exigences du contrôle aérien
tunisien, en prenant en compte les particularités du trafic aérien et de l’espace aérien du
pays.
— Flexibilité et personnalisation : Le développement d’un simulateur local permettrait

aux écoles de contrôle aérien d’ajuster les scénarios de formation en fonction des défis et
des situations réelles rencontrées dans le contexte du pays.
— Expérience de formation globale : L’inclusion des radars manquantes comme le radar

de la zone de contrôle, le radar d’approche et l’en route radar permettrait de couvrir
l’intégralité des phases du vol et de mieux comprendre les interactions entre les différentes
phases du vol, favorisant une vue d’ensemble du processus de contrôle du trafic aérien.
— Expérience immersive renforcée : En combinant ces radars avec un environnement

de réalité virtuelle, l’expérience de formation devient plus immersive et engageante. Cela
créera un environnement d’apprentissage plus réaliste, où les stagiaires pourront se sentir
véritablement immergés dans la gestion du trafic aérien, renforçant ainsi leur compréhen-
sion et leur engagement tout au long de la formation.
"AeroSimex" contribuera grandement à améliorer le facteur "réalité" de la formation en

contrôle du trafic aérien, préparant ainsi les futurs contrôleurs à relever les défis complexes
12
et dynamiques de l’aviation moderne. Nous visons à créer un simulateur de contrôle du trafic

aérien qui formera la prochaine génération de professionnels hautement qualifiés et compétents
dans le domaine de l’ATC.
1.7 Méthodologie de gestion de projet

Au sein de Avaxia Group, toutes les équipes adoptent la méthodologie Scrum. Ce choix est
basé sur nombreux avantages qui répondent à nos besoins, citons à titre d’exemples :
— Rôles bien définies et attribuées à chaque développeur.
— Travail en équipe.
— Flexibilité aux ajustements et aux changements grâce à des itérations courtes.
— Feedback régulier après chaque sprint.
— Deadlines imposés.
Scrum est un cadre de développement dans lequel des équipes pluri-fonctionnelles réalisent
des produits de manière itérative et incrémentale. Son objectif est d’améliorer la productivité
des équipes auparavant ralenties par des méthodologies plus lourdes, et d’être toujours prêt à
réorienter le projet au fil de son avancement[6].
1.8 Langage de modélisation UML - Unified Modeling Lan-

guage
Le langage UML constitue une suite de diagrammes intégrés qui offrent aux développeurs la
possibilité de représenter de manière visuelle les états, les objets et les processus d’un système
donné. Dans le cadre de la conception de notre application, nous avons choisi d’adopter UML
comme langage de modélisation en raison de ses avantages majeurs, notamment sa norme de
standardisation reconnue et la diversité des types de diagrammes qu’il met à disposition. [7]
Conclusion
Dans ce chapitre, nous avons présenté l’organisme d’accueil ainsi que le contexte et la
problématique du projet. Nous avons également présenté le projet, en expliquant son objectif.
Nous avons ensuite mené une étude de l’existant en comparant plusieurs applications similaires
de simulateurs de contrôle de traffic aérien, en mettant en évidence leurs points forts et faibles.
Enfin, nous avons proposé une solution.
13
Chapitre 2
Spécification des besoins
Plan
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.2 Les besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.3 Les besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 17
2 Diagramme du cas d’utilisation global . . . . . . . . . . . . . . . . . 18
3 Style architectural . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.1 Définition des architectures microservices . . . . . . . . . . . . . . . . 19
2.3.2 Définition des architectures 3-tiers . . . . . . . . . . . . . . . . . . . . 19
2.3.3 Définition des applications Multi-Frontend . . . . . . . . . . . . . . . . 19
2.3.4 Les niveaux de l’architecture d’AeroSimex . . . . . . . . . . . . . . . . 19
4 Pilotage du projet avec Scrum . . . . . . . . . . . . . . . . . . . . . . 21
2.4.1 Identification de l’équipe SCRUM . . . . . . . . . . . . . . . . . . . . . 21
2.4.2 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.3 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5.2.1 Éditeurs du code . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5.2.2 Outils de conception . . . . . . . . . . . . . . . . . . . . . . . 24
2.5.3 Technologies et langages . . . . . . . . . . . . . . . . . . . . . . . . . . 24
14
2.5.3.1 Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.5.3.2 Langages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Chapitre 2. Spécification des besoins
Introduction
Ce chapitre est une étape importante dans le processus de développement d’un produit.
Tout d’abord, nous allons commencer par l’analyse des besoins. Ensuite, nous allons présenter
le diagramme des cas d’utilisation global et le style architectural du système. Enfin, nous allons
entamer la partie dédiée au pilotage du projet avec SCRUM.
2.1 Analyse des besoins

Cette section est consacrée pour l’analyse des besoins : Nous identifions les acteurs de notre
système ainsi que les besoins fonctionnels et non fonctionnels.
2.1.1 Identification des acteurs
Dans cette section, nous identifions les différents acteurs qui interagissent avec notre appli-
cation. Après avoir examiné les différentes interactions internes et externes du système, nous
avons jugé nécessaire de spécifier les trois acteurs suivants :
— Contrôleur : Il vérifie les plans de vol, donne aux pilotes l’autorisation de décoller ou
d’atterrir et dirige les mouvements des aéronefs et autres trafics sur les pistes et dans
d’autres parties spécifiques de l’aéroport avec des instructions vocaux.
— Pseudo-pilote : Le module sera conçu comme un poste d’appui au rôle principal de

formation des contrôleurs exécutifs du trafic aérien.
— Instructeur : A le rôle d’administrateur du système. Il dispose d’une multitude d’objets

installés pour préparer une bibliothèque d’exercices (voir annexe) prédéfinis.
Figure 2.1 : Les acteurs du système
16
2.1.2 Les besoins fonctionnels
Les besoins fonctionnels représentent une suite d’actions effectuées par le système afin de
satisfaire les besoins de l’utilisateur.
• Contrôleur
— Consulter le simulateur 3D.
— Consulter toutes les informations sur le trafic aérien en temps réel.
— Consulter toutes les écrans du simulateur de contrôle de trafic aérien dans un envi-
ronnement virtuel.
— Positionner les écrans du simulateur.
• Pseudo-pilote :
— Donner des instructions aux aéronefs dans les radars liées au simulateur 3D.
— Donner des instructions aux aéronefs dans les radars indépendants.
• Instructeur : Administrateur qui peut contrôler toutes les écrans du simulateur.
2.1.3 Les besoins non fonctionnels
Les besoins non fonctionnels sont les exigences qui caractérisent notre système. Ils se ré-
sument dans les points suivants :
- Ergonomie : les interfaces utilisateur doivent être affichées de manière bien structurée et
informative avec une couleur et un style de texte bien choisis. L’application doit également
être simple et facile à utiliser.
- Performance et Réactivité : Les simulateur doit être capable de gérer en temps réel
les données de plusieurs aéronefs et d’organiser plusieurs vols à la fois.
- Modularité et Indépendance des Radars : Le simulateur doit être conçu de manière

à ce que chaque radar, y compris le Ground Radar, le CTR Radar, l’Approach Radar et
le CCR Radar, puisse fonctionner de manière indépendante.
- Réalisme : Le simulateur doit offrir une expérience aussi réaliste que possible, y compris
des conditions météorologiques variables, des modèles de vol précis et des scénarios de
trafic aérien authentiques.
- Adaptabilité aux Besoins Réglementaires : Se conformer aux règlements et normes

de l’aviation pour la formation en contrôle de la circulation aérienne.
17
2.2 Diagramme du cas d’utilisation global

Les cas d’utilisation représentent ce que les acteurs veulent que notre système fasse pour eux.
Le diagramme du cas d’utilisation global présente les interactions entre les différents acteurs et
le système. De plus, il expose les fonctionnalités de notre solution proposée, afin de donner une
vision global de son comportement fonctionnel. [8]
La Figure 2.2 présente le diagramme du cas d’utilisation global.
Diagramme de cas d'utilisation global
Consulter toutes les

informations du trafic aérien
dans les radars liées au simulateur
3D en temps réel. include
Contrôleur
Lancer
Consulter toutes les le simulateur 3D
dans les radars indépendants
en temps réel.
Pseudo-Pilote Consulter les écrans du

simulateur de contrôle de include
trafic aérien en temps réel
Donner des instructions

aux aéronefs dans les radars
liées au simulateur 3D
Instructeur

indépendants
Figure 2.2 : Diagramme des cas d’utilisation global
18
2.3 Style architectural

Nous avons choisi une architecture de microservices pour notre système, composée de deux
services distincts.
2.3.1 Définition des architectures microservices
Les architectures microservices permettent de décomposer une application volumineuse en

composants indépendants. Chacun de ces services possède sa propre capacité métier, sa logique,
son mécanisme de communication basé sur des messages et est entièrement capable d’un dé-
ploiement indépendant. Ensemble, ces services deviennent les composants de base qui forment
l’architecture de microservices dans son ensemble. Il est même possible que ces microservices
utilisent différents langages de programmation, cadres de développement et technologies de base
de données, à condition qu’ils répondent aux exigences fonctionnelles de l’application. [9]
2.3.2 Définition des architectures 3-tiers
L’architecture à trois niveaux est une structure couramment utilisée dans le développement
de logiciels. Elle divise une application en trois parties distinctes : la couche de présentation, qui
gère l’interface utilisateur, la couche d’application, qui traite les données et la logique métier,
et enfin la couche de données, où les données de l’application sont stockées et gérées. Cette
approche facilite la conception modulaire et la gestion des applications complexes. [10]
2.3.3 Définition des applications Multi-Frontend
L’application multi-frontend est une approche évolutive dans le développement frontend

actuellement utilisée. Au lieu de regrouper toutes les interfaces d’un système dans une seule
application. Le multi-frontend consiste à diviser l’application frontale en plusieurs unités indé-
pendantes qui peuvent être livrées séparément. [9]
2.3.4 Les niveaux de l’architecture d’AeroSimex
Les niveaux de l’architecture d’AeroSimex sont représentés dans la Figure 2.3
19
DBM Service
Frontend DBM
React JS
Frontend Core
React JS
Core Service Launcher

3D Core Entry
Point
2D Core
Figure 2.3 : Schéma de l’architecture microservices d’AeroSimex
Notre architecture microservices est composée de deux services :
• Service DBM - Architecture 3 Tiers :
— Couche Présentation : Frontend DBM (Développé avec React) Il s’agit de l’in-

terface utilisateur, un tableau de bord utilisé par l’instructeur pour configurer la
formation et l’exercice pour les contrôleurs.
— Couche Logique Métier : Service DBM (Développé avec Node.JS). Il permet à

l’instructeur de modifier les données avant de lancer l’exercice.
— Couche de Données : Base de données PostgreSQL. Elle stocke les données né-
cessaires au service DBM.
• Service Core - Architecture 3 Tiers :
— Couche Présentation : (Multi-frontend)
▷ Frontend Core (Développé avec ReactJS) : Contient les interfaces en temps

réel qui sont utilisées après le lancement de la formation, telles que l’écran de
dépouillement, l’action en direct et la gestion des enregistrements.
▷ 3D Core (Développé avec Unity) : Simulateur 3D avec une vue 360° de la tour.
▷ 2D Core (Développé avec Unity) : Contient les 4 radars(Ground Radar, CTR

Radar, Approach Radar et En-Route Radar)
20
— Couche Logique Métier : Core Service (développé avec Node.js.) Serveur de com-
munication en temps réel utilisant Socket.io pour relier toutes les autres applications.
— Couche de Données : Base de données PostgreSQL. Elle stocke les données né-
cessaires au service Core.
2.4 Pilotage du projet avec Scrum

La présentation précédente des besoins ne constitue qu’une première étape pour définir en
détail les exigences fonctionnelles et non fonctionnelles requises. Pour gérer et livrer de manière
continue les résultats de ce projet, nous avons choisi d’adopter SCRUM comme cadre de travail.
2.4.1 Identification de l’équipe SCRUM
La figure 2.4 présente l’équipe Scrum de ce projet.
Figure 2.4 : Identification de l’équipe Scrum
2.4.2 Backlog du produit
Comme nous avons présenté dans le premier chapitre, le backlog de produit est un artéfact
essentiel. C’est la liste de toutes les fonctionnalités attendues d’un produit appelées les "User
Story" ou les "Histoire Utilisateur". Chaque histoire utilisateur possède un ordre de priorité
définit par le Product Owner. Nous utilisons la technique de MoSCoW pour prioriser les besoins :
— M pour Must Have : Il s’agit de ce qu’il doit être fait.
— S pour Should Have : Il s’agit d’une exigence essentielle, mais, si elle n’est pas faite,
elle peut être reportée au sprint suivant.
21
— C pour Could Have : Il s’agit d’une exigence souhaitable. Elle pourrait être réalisée à
condition qu’elle n’ait pas d’impact sur les autres tâches.
— W pour Won’t Have : Il s’agit d’une tâche intéressante, mais pas obligatoire.
Le backlog de produit est illustré par le tableau 2.1 :
Sprint User Story Priorité

En tant que contrôleur, instructeur ou pseudo-pilote, je souhaite consulter
M
toutes les informations sur le trafic des aéronefs au sol en temps réel.
En tant que pseudo-pilote ou instructeur, je souhaite avoir la possibilité
Sprint 1 de donner des instructions aux aéronefs et avoir la possibilité M
Ground de changer le comportement des aéronefs en cas de besoin.
Radar En tant que contrôleur, instructeur ou pseudo-pilote, je souhaite
S
et CTR voir le système lumineux de l’aéroport.
Radar En tant que contrôleur, instructeur ou pseudo-pilote, je souhaite
consulter toutes les informations sur le trafic des aéronefs dans la zone M
de contrôle de l’aéroport en temps réel.
En tant que contrôleur, instructeur ou pseudo-pilote, je souhaite
consulter toutes les informations sur le trafic des aéronefs dans la zone
M
d’approche et à haute altitude de l’aéroport
de départ vers l’aéroport d’arrivé en temps réel.
Sprint 2
Radar
consulter les données de l’exercice et je souhaite avoir
d’Approche M
la possibilité de changer le comportement
et En-Route
des aéronefs en cas de besoin.
Radar
avoir la possibilité de faire un Zoom avant ou arrière M
en consultant les radars d’approche et d’En-Route.
consulter le temps de simulation de l’exercice pour S
suivre les dates de départ et d’arrivé de chaque aéronef.
22

voir les écrans du simulateur de contrôle de trafic aérien
Sprint 3 M
dans un environnement virtuel similaire au monde réel pour
Représentation
vivre une meilleure expérience.
par la Réalité
Virtuelle
avoir la posibilité de positionner l’écran comme je veux dans la tour M
de contrôle.
Tableau 2.1 : Backlog produit
2.4.3 Planification des sprints
Release Sprint Date début/Date fin

Sprint 1
Release 1 Radar de contrôle de surface 20 février - 31 Mars
Radars liées au simulateur 3D et Radar de contrôle de la zone
Sprint 2
Release 2 03 Avril- 16 Juin
Radar d’approche et En-Route Radar
Radars indépendants et
Sprint 3
Représentation par la RV 19 Juin - 23 Juillet
Représentation par la Réalité virtuelle
Tableau 2.2 : Planification des sprints
2.5 Environnement de travail

Dans ce qui suit, nous décrivons les outils matériels et logiciels que nous avons utilisé dans
notre environnement.
23
2.5.1 Environnement matériel
Ordinateur 1
Propriétaire Semah BELHADJ DIT MDALSI
Processeur Core i5
Ram 8 Go
Disque dur 512 SSD
Système d’exploitation Windows 11
Casque de réalité virtuelle Oculus Meta Quest 2
Tableau 2.3 : Environnement matériel
2.5.2 Environnement logiciel
Dans cette partie, nous allons lister les éditeurs du code et les outils de conception utilisés
au cours de ce projet.
2.5.2.1 Éditeurs du code
Le choix des éditeurs de code dans le développement de ce projet est opté pour :
• Visual Studio 2019 : Panneau de lancement créatif utilisé pour modifier, déboguer et
générer du code, puis publier une application. Visual Studio aide dans le développement
C avec le moteur de jeu Unity. Il Identifie les problèmes et définie des points d’arrêt et
évalue les variables et les expressions complexes.[11]
2.5.2.2 Outils de conception
Pour la conception technique et graphique, nous avons opté pour :
• Draw.io [12] : Outil utilisé pour l’élaboation des diagrammes de conception.
• Adobe Illustrator 2022 : Outil utilisé pour la création des illustrations vectorielles
assisté par ordinateur.
• Adobe Photoshop 2022 : Logiciel de retouche, de traitement et de dessin assisté par

ordinateur.
2.5.3 Technologies et langages
Dans cette section, nous allons exposer les choix techniques utilisés pour réaliser et implé-
menter la solution.
24
2.5.3.1 Technologies
• Unity : Moteur de jeu multiplateforme développé par Unity Technologies.
• XR Interaction Toolkit : Système d’interaction de haut niveau, basé sur des compo-
sants, qui permet de créer des expériences de RV et de RA. Il fournit un cadre commun
pour les interactions et rationalise la création multiplateforme. [13]
• Agora RTC Plugin Agora.io fournit des éléments de base qui vous permettent d’ajouter
des communications vocales et vidéo en temps réel grâce à un SDK. Le SDK Agora permet
de faire une communication en temps réel dans une application. [14]
2.5.3.2 Langages
• Language C# : Langage de programmation orientée objet, commercialisé par Microsoft

depuis 2002 et destiné à développer sur la plateforme Microsoft .NET [11]
Conclusion
En conclusion, ce chapitre a permis d’établir une vision complète du projet en présentant
les différentes étapes clés de sa conception. Les besoins fonctionnels et non fonctionnels ont
également été définis avec précision, ce qui permettra de guider le développement du système
de manière efficace. Ensuite, la présentation du diagramme du cas d’utilisation global a permis
de visualiser de manière concrète les différents éléments qui seront implémentés dans le système.
Enfin, la présentation du backlog produit. Ainsi que la description de l’environnement matériel
et logiciel du travail. Ce chapitre constitue une étape importante dans la réalisation du projet
en fournissant une vue d’ensemble cohérente et claire de ses principales composantes.
25
Chapitre 3
Release 1 : Radars liés au simulateur

3D
Plan
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1 Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.1 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.2 Spécification fonctionnelle détaillée . . . . . . . . . . . . . . . . . . . . 29
3.1.2.1 Détails des besoins fonctionnelles . . . . . . . . . . . . . . . . 29
3.1.2.2 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . 30
3.1.2.3 Diagramme de cas d’utilisation raffiné . . . . . . . . . . . . . 32
3.1.2.4 Description textuelle du cas d’utilisation . . . . . . . . . . . . 33
3.1.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1.3.1 Diagramme d’activité «Sélectionner une instruction à partir

d’une liste» . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1.3.2 Diagramme d’État-Transition «Procédure de départ» . . . . 37
3.1.3.3 Diagramme d’État-Transition «Procédure d’arrivé» . . . . . 37
3.1.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.1.4.1 Ground Radar . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.1.4.2 CTR : Radar de contrôle de la zone . . . . . . . . . . . . . . 43
2 Revue du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Chapitre 3. Release 1 : Radars liés au simulateur 3D
Introduction
Après avoir analysé et défini le backlog du produit, nous avons tenu une réunion au cours
de laquelle nous avons convenu de la répartition des tâches et de la division de l’application en
deux Releases. Nous entamons désormais le premier sprint qui se concentrent sur les "Radars
liés au simulateur 3D".
3.1 Sprint 1
Ce sprint sera consacré aux radars liés au simulateur 3D qui sont le radar de mouvement
de surface et le radar de contrôle de la zone
3.1.1 Backlog du sprint
Comme début, nous identifions la liste des tâches à réaliser pendant ce sprint dans le backlog
du premier sprint comme représente le tableau 3.1.1
User Story Tâches

- Dessiner le radar de mouvement de surface en calculant
les mesures nécessaires pour avoir une forme similaire à la
forme de l’aéroport.
- Recevoir les sockets des données de l’exercice.
En tant que contrôleur, instructeur
- Projeter les positions initiales des aéronefs du simulateur
ou pseudo-pilote,
3D vers les radars.
je souhaite consulter toutes
- Ajouter des boutons et des panneaux pour faire
les informations sur le trafic
l’affichage des données de chaque aéronef en cliquant
des aéronefs au sol en temps réel.
sur un bouton (Afficher uniquement le Callsign
ou Afficher les Détails du vol).
- Logique de mouvement des panneaux de Callsign
ou des détails des aéronefs.
- Afficher la liste des aéronefs et leurs
états en temps réel.
- Colorier l’aéronefs lors du survol dans la liste.
- Mettre à jour les couleurs de chaque état dans le radar
de mouvement de surface.
27
- Afficher la barre des commandes lors du survol de la partie

haute du l’interface.
En tant que pseudo-pilote - Pour le radar de mouvement de surface, Afficher le taxi de
ou instructeur, départ en survolant l’étiquette de l’aéronef
je souhaite avoir la possibilité - Donner la possibilité d’écrire des instructions dans la barre
de donner des instructions aux des commandes.
aéronefs et avoir la possibilité de - Ajouter la logique du menu contextuel dans le radar de mou-
changer le comportement des vement de surface.
aéronefs en cas de besoin - Afficher la liste des commandes possible en cliquant gauche
sur l’étiquette de l’aéronef.
- Filtrer les commandes en temps réel pour avoir uniquement
les commandes possibles au moment du clic.
- Ajuster les Taxis dans le simulateur 3D pour ne pas avoir
des comportements illogiques.
- Ajouter la possibilité de donner une instruction en choisis-
sant une commande de la liste.
- Lister toutes les instructions et vérifier les commandes à
passer et les messages d’erreur à afficher.
- Ajouter la possibilité de changer le Taxi de départ en choi-
sissant un autre Taxi de la liste.
- Afficher le nouveau taxi en survolant l’aéronef dans la liste
des instructions avant de passer la commande du changement
du taxi
- Vérifier la validité de l’instruction choisie au moment de la
soumission.
En tant que contrôleur, instructeur - Recevoir en temps réel les positions des aéronefs du simula-
ou pseudo-pilote, teur 3D et les projeter dans le radar.
je souhaite suivre en temps réel - Recevoir en temps réel les rotations du simulateur 3D et
les positions et les rotations les appliquer aux aéronefs dans les radars en respectant les
exactes des aéronefs. mesures nécessaires.
28
En tant qu’un contrôleur, instructeur - Comprendre la logique du système lumineux de l’aéroport.

ou pseudo-pilote, - Recevoir les sockets de la plateforme de gestion du système
je souhaite voir le système lumineux.
lumineux de l’aéroport. - Ajouter les objets du système lumineux dans le radar de
mouvement de surface.
En tant que contrôleur, instructeur - Comprendre les principes du radar de contrôle de la zone.
ou pseudo-pilote, je souhaite - Dessiner le radar de la zone de contrôle et vérifier les mesure
consulter toutes les informations nécessaires.
sur le trafic des aéronefs dans la zone - Refaire la logique de suivie en temps réel des positions et
de contrôle en temps réel. des rotations exactes des aéronefs pour ce radar.
- Ajouter les instructions possible dans la zone de contrôle de
l’aéroport
Tableau 3.1 : Backlog du premier Sprint
3.1.2 Spécification fonctionnelle détaillée
Dans cette partie nous allons identifier les besoins fonctionnels des radars liés au simulateur
3D. Ensuite nous allons tracer les diagrammes de cas d’utilisation de ces derniers et enfin, nous
allons faire la description textuelle de quelques cas.
3.1.2.1 Détails des besoins fonctionnelles
Un cas d’utilisation est un groupe de séquences d’actions qui décrivent les exigences fonc-
tionnelles du système. Chaque cas d’utilisation correspond à une fonction métier du système.
Voici la liste des grandes fonctionnalités que nos deux radars doivent offrir :
— Fournir une représentation visuelle géospécifique de l’aéroport.
— Afficher les données des avions par indicatif comme défini dans le scénario de l’exercice.
Chaque événement lancé par l’instructeur doit être reflété en temps réel dans les radars
comme dans le simulateur 3D.
— Consulter le système d’éclairage de l’aéroport qui doit être comme représente la figure 3.1
29
Figure 3.1 : Le système d’éclairage de l’aéroport
— Suivre et guider en temps réel le trafic des aéronefs lors de leur arrivée ou de leur départ
de l’aéroport.
— Mettre à jour le circuit en cas de changement des données de l’exercice (changement du

taxi de départ).
— Guider les aéronefs sur leurs itinéraires de vol et les orienter.
— Donner des instructions (voir annexe) aux pilotes pour que les aéronefs suivent les tra-
jectoires correctes.
3.1.2.2 Diagramme de cas d’utilisation
Le premier sprint se concentre sur le cas d’utilisation qui décrit les différentes fonctionnalités
représentées dans les diagrammes de cas d’utilisation du radar de mouvement de surface et du
radar de la zone de contrôle.
La Figure 3.2 représente le diagramme de cas d’utilisation du Ground Radar.
30
Diagramme de cas d'utilisation Ground Radar

sur la piste de l'aéroport
en temps réel. include
Contrôleur
Lancer
le simulateur 3D
include
aux aéronefs sur la piste de
l'aéroport en temps réel.
Pseudo-Pilote
Instructeur
Figure 3.2 : Diagramme de cas d’utilisation du Ground Radar
31
La Figure 3.3 représente le diagramme de cas d’utilisation du CTR Radar.
Diagramme de cas d'utilisation du CTR Radar

dans la zone de contrôle
en temps réel. include
Contrôleur
Lancer
le simulateur 3D
include
aux aéronefs dans la zone de
contrôle en temps réel.
Pseudo-Pilote
Instructeur
Figure 3.3 : Diagramme de cas d’utilisation du radar de contrôle de la zone
3.1.2.3 Diagramme de cas d’utilisation raffiné
Un diagramme de cas d’utilisation raffiné ou diagramme de cas d’utilisation détaillé permet

de détailler un cas d’utilisation d’un système.[8]
La figure 3.4 représente le raffinement du cas d’utilisation «Donner des instructions aux
aéronefs»
32
Diagramme de cas d'utilisation raffiné
Écrire l'instruction dans

la barre des instruction

aux aéronefs sur la piste de
l'aéroport en temps réel.
Pseudo-Pilote
Choisir une instruction à
partir de la liste des
include
instructions
Lancer
le simulateur 3D
Instructeur
Figure 3.4 : Raffinement du cas d’utilisation «Donner des instructions aux aéronefs»
3.1.2.4 Description textuelle du cas d’utilisation
SOMMAIRE D’IDENTIFICATION
Titre Sélectionner une instruction à partir d’une liste
Acteur(s) Instructeur, Pseudo-pilote
DESCRIPTION DES ENCHAÎNEMENTS
Pré conditions Un exercice doit être sélectionné et le simulateur 3D doit être lancé.
33
Scénario nominal
1. Le système affiche la liste des étiquettes des aéronefs existants dans l’exercice
lancé avec leurs états et les aéronefs dans leurs positions et rotations sur la
surface de l’aéroport dans le simulateur 3D.
2. L’utilisateur déplace son curseur sur l’étiquette dans la liste des vols de départ
pour consulter le taxi de départ.
3. L’utilisateur peut effectuer un clic droit sur l’étiquette.
4. Une fois l’utilisateur effectue un clic droit, le système vérifie l’état de l’aéronef
au moment du clic.
5. Le système affiche les instructions possible dans cet état au moment du clic.
6. Une fois l’utilisateur choisit l’instruction à exécuter, le système vérifie la position

au moment du clic pour valider l’instruction
7. Une fois l’instruction est valide, le système l’envoie au simulateur 3D pour qu’il
l’exécute et l’aéronef commence à se déplacer.
8. Le système met à jours l’état de l’aéronef :
•Gris : Instruction pas encore donnée.
•Orangé : Instruction en cours de mise en œuvre.
•Vert : Instruction terminée.
Scénario alternatif
6.a. Dans le cas du changement de taxi, si l’instruction choisie n’est plus logique, le
système affiche un message d’erreur qui indique les Taxis possibles au moment du clic.
6.b. L’utilisateur reprend l’étape 2 du scénario nominal.
Tableau 3.2 : Description textuelle du cas d’utilisation «Sélectionner une instruction à

partir d’une liste»
34
3.1.3 Conception
3.1.3.1 Diagramme d’activité «Sélectionner une instruction à partir d’une

liste»
Les diagrammes d’activités fournissent des représentations visuelles du flux d’activités dans
un système. Ces diagrammes se concentrent sur les activités qui vont être réalisées et de qui
est responsable de l’exécution de ces activités. [8]
La figure 3.5 représente le diagramme d’activité du cas d’utilisation «Sélectionner une ins-
truction à partir d’une liste».
35
Utilisateur Ground Radar
Lire les données de

l'exercice
Effectuer un clic droit sur le Afficher les données

Callsign de l'aéronef des vols de l'exercice
Vérifier l'état de l'aéronef
Afficher les instructions

possible dans cet état
Sinon Si Taxi
Choisir l'instruction
Vérifier le côté du pushBack
Afficher les Taxi possible

après le pushBack de ce côté
Si Taxi
Vérifier la position et la
rotation de l'aéronef
Sinon Si Taxi encore possible
Afficher un message d'erreur

Envoyer l'instruction au
qui dpécifie les taxi encore
simulateur 3D pour l'exécuter
possibles
Sinon
Figure 3.5 : Diagramme d’activité «Sélectionner une instruction à partir d’une liste»
36
3.1.3.2 Diagramme d’État-Transition «Procédure de départ»
Un diagramme d’État-Transition est un modèle de conception utilisé pour représenter le

comportement d’un objet, d’un composant logiciel ou d’un système en mettant l’accent sur les
transitions entre les états possibles. Il décrit comment un objet ou un système évolue d’un état
à un autre en réponse à des événements ou des conditions spécifiques.
La figure 3.6 représente le diagramme d’États-Transition de la «Procédure de départ».
Start Up
Besoin d'un PushBack

Starting Up Pushing Back
Push Back
Push Back fini

Pas besoin de PushBack
Taxi
Hold
Taxiing Resume Holding
Taxi fini
Line Up
Line up fini
Lining Up Taking Off
Take Off
Take Off fini
Figure 3.6 : Diagramme d’États-Transition de la «Procédure de départ»
3.1.3.3 Diagramme d’État-Transition «Procédure d’arrivé»
La figure 3.7 représente le diagramme d’États-Transition de la «Procédure d’arrivé».
37
Land
Landing
Evacuate runway
Evacuating
Runway
Taxi
Hold
Taxiing Resume Holding
Stand
Standing
Figure 3.7 : Diagramme d’États-Transition de la «Procédure d’arrivé»
3.1.4 Réalisation
3.1.4.1 Ground Radar
Tout d’abord, nous présenterons les interfaces graphiques liées au radar de mouvement de
surface. Ensuite, nous aborderons les différents fonctionnalitées offerte par ce radar.
Pour commencer, la figure 3.8 montre la logique de la tour de piste pendant la procédure
de départ et d’arrivée d’un aéronef que nous implémenterons dans le Ground Radar :
38
Figure 3.8 : Tour de piste
Légende de la figure 3.8 :
1. Airport Apron : L’autorisation d’atterrir est accordée à cet endroit.
2. Point d’attente : L’autorisation d’entrer sur la piste est donnée au plus tard à cet endroit.
3. Line-Up : L’autorisation de décoller est donnée au plus tard à cet endroit.
4. Climb-Out : Montée
5. Crosswind : segment rejoignant le segment vent arrière.
6. tail wind : position où l’ordre d’atterrissage est communiqué.

6 bis. Fin du Down Wind : position où un aéronef doit recevoir son ordre.
7. Base : position où un aéronef effectuant une approche semi-directe doit recevoir au plus
tard l’ordre d’atterrissage ; ce point est l’équivalent du point 6 bis.
8. Last Turn
9. Final : Segment où l’autorisation d’atterrir ou de remettre les gaz est donnée au plus tard.
10. Clear Runway : Position où l’autorisation est donnée d’atteindre l’aire de trafic.
11. Long Final : Position où un aéronef effectuant une approche directe doit recevoir au plus
tard l’ordre d’atterrissage ; ce point est l’équivalent du point 6 bis.
12. Position où l’information de stationnement est donnée si nécessaire.
39
L’interface initial prend une forme gérospécifique à l’aéroport. Le système affiche la liste
des étiquettes des aéronefs existants dans l’exercice, leurs états, et leurs positions et rotations
exactes dans le simulateur 3D comme représente les deux figures 3.9 et 3.10.
Figure 3.9 : Forme initiale du Ground Radar
Figure 3.10 : Forme initiale du simulateur 3D
L’utilisateur déplace son curseur sur l’étiquette dans la liste des vols de départ pour consulter
le taxi (voir annexe) de départ et il peut effectuer un clic droit sur l’étiquette pour afficher les
instructions possible au moment du clic comme représente la figure 3.11
40
Figure 3.11 : Séléctionner une instruction à partir d’une liste
Dans ce cas, l’aéronef a fini le StartUp (comme indique la couleur verte de l’état de l’aéronef
séléctionné) et peut commencer le PushBack, donc l’instruction PushBack apparaît dans le
menu, une fois l’utilisateur sélectionne l’instruction, une socket sera envoyé au simulateur 3D
et l’aéronef commence le PushBack. Le radar met à jour la position et la rotation exacte du
simulateur comme indique la figure 3.12
41
Figure 3.12 : Interfaces du simulateur 3D et du Ground Radar lors du PushBack
Le panneau du Callsign (voir annexe) de l’aéronef suit la position de l’aéronef en mouvement,

et peut être déplacé par l’utilisateur qui peut réinitialiser la position de ce panneau à tous
moment. Il peut également mettre le curseur en haut de l’interface pour afficher les boutons
du Callsign et de détails et la barre des commandes comme indique la figure 3.13 : Le premier
bouton va afficher uniquement le Callsign de l’aéronef, et le deuxième visualisera chacun des
Callsign, aéroport de départ, aéroport d’arrivée et numéro de parking. Le pseudo-pilote ou
l’instructeur peut écrire une instructeur dans la barre de commandes pour guider les aéronefs.
Figure 3.13 : Bouton de détails et barre des commandes
Dans l’exemple de la figure 3.13, nous avons choisi de faire le Taxi après avoir terminer
le PushBack (voir annexe), donc nous devons écrire le Callsign de l’aéronef accompagné de la
42
lettre "T" qui signifie Taxi.

Le système vérifie le syntaxe de l’instruction introduite, ensuite, il vérifie l’état de l’aéronef
au moment du passage de la commande. Enfin, si la commande correspond à un taxi ou un
changement de taxi, le système vérifie la position et la rotation de l’aéronef, si la commande
est valide, il envoie une socket au simulateur 3D qui va suivre la commande, sinon, il affiche un
message d’erreur.
La figure 3.14 montre un message d’erreur lors du passage d’une commande de changement
de taxi qui ne peut pas être réalisée au moment de la soumission.
Figure 3.14 : Erreur de changement de taxi spécifique
3.1.4.2 CTR : Radar de contrôle de la zone
Tout d’abord, nous présenterons les interfaces graphiques liées au radar de contrôle de la
zone. Ensuite, nous aborderons les différentes fonctionnalités offertes par ce radar.
L’interface initial prend une forme géospécifique à la zone de contrôle de l’aéroport. Le
système affiche la liste des étiquettes des aéronefs existants dans l’exercice et leurs positions et
rotations exactes dans le simulateur 3D comme représente la figure 3.15.
43
Figure 3.15 : Forme initiale du Radar de contrôle de la zone
Le radar met à jour la position et la rotation exacte du simulateur comme indiqué dans les
figures 3.16 et 3.17
Figure 3.16 : Interfaces du CTR lors de l’atterrissage
Figure 3.17 : Interfaces du simulateur 3D lors de l’atterrissage
L’utilisateur peut effectuer un Zoom avant et un Zoom arrière dans le radar de contrôle de
la zone.
L’utilisateur peut donner des instructions aux aéronefs pour les diriger et modifier leurs
trajectoires.
44
L’utilisateur introduit la commande « 360L », l’aéronef va faire un tour de 360° et puis

elle va atterrir. Le système vérifie le syntaxe de la commande écrite. Ensuite, il vérifie l’état
de l’aéronef au moment du passage de la commande. Enfin, le système met à jour la position
et la rotation de l’aéronef dans le simulateur 3D et dans le radar 2D. Ces figures 3.18 et 3.19
montrent le résultat du passage de cette instruction.
Figure 3.18 : Instruction «Tourner 360°» dans le radar de contrôle de la zone
Figure 3.19 : Instruction «Tourner 360°» dans le simulateur 3D
3.2 Revue du sprint

La revue de Sprint a pour objectif d’inspecter l’incrément du produit réalisé durant le
Sprint, de faire le point sur l’avancement de la Release, et de s’adapter aux besoins du plan et
45
du backlog du produit.
Après une réunion avec le Scrum-Master et le Product- Owner, il a été conclu que le plan du
Sprint était conforme à ce qui avait été réalisé pendant cette première itération, ce qui rend le
Sprint valide.
Conclusion
En conclusion, nous avons abordé plusieurs aspects clés du développement Agile, notamment
le backlog du sprint, la spécification fonctionnelle, la conception, la réalisation, et la revue de
sprint.
Nous avons vu comment chacun de ces éléments contribue à garantir que le produit final est de
haute qualité et répond aux besoins des utilisateurs. Une gestion efficace du backlog du sprint
permet de s’assurer que les fonctionnalités clés sont identifiées et traitées en temps voulu. La
spécification fonctionnelle fournit une description claire des exigences, tandis que la conception
garantit que l’interface utilisateur est intuitive et facile à utiliser.
46
Chapitre 4
Release 2 : Radars indépendants et

réalité virtuelle
Plan
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
1 Sprint 2 : Radar d’approche et En-Route Radar . . . . . . . . . . . 49
4.1.2.1 Détails des besoins fonctionnelles . . . . . . . . . . . . . . . . 51
4.1.2.2 Diagramme du cas d’utilisation . . . . . . . . . . . . . . . . . 51
4.1.2.3 Diagramme du cas d’utilisation raffiné . . . . . . . . . . . . . 52
4.1.2.4 Description textuelle du cas d’utilisation «Modifier la vitesse» 52
4.1.2.5 Description textuelle du cas d’utilisation «Modifier l’angle de

rotation de l’aéronef» . . . . . . . . . . . . . . . . . . . . . . 53
4.1.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.1.3.1 Diagramme d’activité du cas «Modifier l’angle de rotation» . 53
4.1.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.1.4.1 En-Route Radar . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.1.4.2 Approach Radar . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.1.5 Revue du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
2 Sprint 3 : Représentation de la tour de contrôle . . . . . . . . . . . 62
47
4.2.3 Détails des besoins fonctionnelles . . . . . . . . . . . . . . . . . . . . . 63
4.2.3.1 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . 63
4.2.3.2 Diagramme de cas d’utilisation raffiné . . . . . . . . . . . . . 64
4.2.3.3 Description textuelle du cas d’utilisation «Choisir l’écrans à

visualiser» . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.2.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.2.4.1 Diagramme d’activité «Choisir l’écran à visualiser» . . . . . . 66
4.2.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Chapitre 4. Release 2 : Radars indépendants et réalité virtuelle
Introduction
Nous abordons dans ce chapitre le deuxième et le troisième Sprint, qui se concentrent sur
les "Radars indépendant et la réalité virtuelle", dans le deuxième sprint, nous allons entamer le
radar d’approche et l’en-route radar, et dans le troisième sprint, nous allons expliquer comment
l’utilisateur va vivre une expérience d’immersion dans un monde virtuelle.
4.1 Sprint 2 : Radar d’approche et En-Route Radar

Pour commencer, nous avons établi une liste des tâches à accomplir pour ce Sprint. Le plan
de cette itération comprend cinq User Story telles que définies dans le tableau 4.1.1.
User Story Tâches

- Comprendre les principes du radar d’approche et de l’en
route radar
En tant que contrôleur, pseudo-pilote
- Trouver des datasets pour avoir identifier les données des
ou instructeur, je souhaite consulter
positions des aéroports dans le monde réel et consommer ces
toutes les informations sur
données dans le radar.
le trafic des aéronefs dans la zone
- Trouver une solution pour convertir les longitudes et les
d’approche et à haute altitude de
latitudes des Waypoints (voir annexe) dans un radar 2D
l’aéroport de départ vers l’aéroport
- Mettre à jour les données de l’exercice pour avoir des points
d’arrivé en temps réel.
réels.
- Dessiner les formes des radars d’approche et de l’en-route
radar en respectant les mesures nécessaires.
- Ajouter les longitudes et les latitudes dans l’En-Route radar.
- Recevoir les données de l’exercice et projeter les position
exactes des aéroports dans l’En-Route radar.
- Projeter les positions initiales des aéronefs dans leurs aéro-
ports de départ.
- Ajouter la logique des détails des aéronefs comme les autres
radars.
49
- Adapter les vitesses et les altitudes maximales aux perfor-

En tant que pseudo-pilote ou mances réelles selon le modèle et la masse de l’aéronef. [15]
instructeur, je souhaite - Ajouter un menu en cliquant sur l’aéronef.
avoir la possibilité de changer - Visualiser les données relatives à chaque aéronef dans le
le comportement des aéronefs menu.
en cas de besoin. - Calculer les directions des aéronefs en temps réel et visualiser
l’angle de rotation.
- Ajouter la possibilité de changer l’altitude et la vitesse en
temps réel.
- Ajouter la possibilité de choisir un angle de rotation
- Changer le comportement de l’aéronef en changeant l’angle
de rotation donc le mouvement de l’aéronef devient manuel.
En tant que contrôleur, pseudo- - Ajouter la logique du zoom avant et arrière à la camera des
pilote ou instructeur, radars d’approche et d’en-route en utilisant soit le défilement
je souhaite avoir la possibilité de la sourie soit le touchpad.
de faire un Zoom avant ou arrière - Ajouter la possibilité de déplacer la camera en consultant
en consultant les radars. les radars.
En tant que contrôleur, pseudo-pilote - Afficher le temps de simulation dans les radars.
ou instructeur, je souhaite - Ajouter la possibilité d’augmenter et diminuer la vitesse de
consulter le temps de simulation de simulation.
l’exercice pour suivre les dates de - Faire apparaître et disparaître les aéronefs selon leurs dates
départ et d’arrivé de chaque aéronef. départs et d’arrivés.
- Calculter les durées des vol et les vitesses nécessaire pour
chaque trajet
- Adapter les vitesses et les durées des vols pour avoir une
simulation réel.
En tant que contrôleur, pseudo-pilote - Comprendre les principes du radar d’approche.
ou instructeur, je souhaite - Dessiner le radar d’approche et vérifier les mesure néces-
consulter toutes les informations saires.
sur le trafic des aéronefs dans la zone - Ajouter les aéronefs et la logique du mouvement dans le
d’approche en temps réel. radar d’approche comme les autres radars
Tableau 4.1 : Backlog du deuxième Sprint
50
Dans cette partie nous allons détailler les besoins fonctionnels. Ensuite nous allons tracer le
diagramme du cas d’utilisation de ce sprint et enfin la description textuelle de chaque cas.
4.1.2.1 Détails des besoins fonctionnelles
Les macro-fonctionnalités à implémenter par notre solution à la fin de ce Sprint sont les
suivantes :
— Fournir une vue de loin du trafic aérien tout au long du trajet des vols.
— Respecter les dates de départ et d’arrivée mentionnées dans l’exercice avec des vitesses et
des altitudes réelles.
— Consulter les informations du trafic aérien.
4.1.2.2 Diagramme du cas d’utilisation
Le deuxième sprint utilise les différentes fonctionnalités décrites dans le diagramme du cas
d’utilisation présenté dans la figure 4.1
Diagramme de cas d'utilisation En-Route Radar

informations du trafic aérien de
l'aéroport de départ vers l'aéroport
d'arrivé en temps réel.
Contrôleur
Consulter le temps de Modifier la rapidité

extends
simulation de l'exercice de temps

indépendants
Pseudo-Pilote
Instructeur
Figure 4.1 : Diagramme du cas d’utilisation de l’En-Route Radar
51
4.1.2.3 Diagramme du cas d’utilisation raffiné
La figure 4.2 représente le raffinement du cas d’utilisation «Modifier les paramètres des
aéronefs»
Diagramme de cas d'utilisation Raffiné
Modifier l'altitude de
l'aéronef
Donner des instructions * Modifier la vitesse de

l'aéronef
indépendants
Pseudo-Pilote
Modifier l'angle de
rotation de l'aéronef
Instructeur
Figure 4.2 : Raffinement du cas d’utilisation «Modifier les paramètres des aéronefs»
4.1.2.4 Description textuelle du cas d’utilisation «Modifier la vitesse»
Titre Modifier la vitesse de l’aéronef
Acteurs Instructeur, Pseudo-pilote
Pré conditions Temps de simulation atteint la date de départ.
Scénario nominal
1. L’aéronef quitte l’aéroport de départ spécifié dans l’exercice.
2. L’utilisateur effectue un clic droite sur un aéronef.
3. Un menu qui contient les informations relatifs à l’aéronef est affiché.
4. L’utilisateur introduit une valeur pour modifier la vitesse.
5. La vitesse de l’aéronef diminue ou augmente progressivement pour atteindre
la vitesse désirée.
52
4.a. En cas de saisie d’une valeur qui dépasse les performances de l’aéronef sélectionnée,
le système affiche un message d’erreur
Tableau 4.2 : Description textuelle du cas d’utilisation «Modifier la vitesse de l’aéronef»
4.1.2.5 Description textuelle du cas d’utilisation «Modifier l’angle de rotation

de l’aéronef»
Titre Modifier l’angle de rotation de l’aéronef
Acteurs Instructeur, Pseudo-pilote
Pré conditions Temps de simulation atteint la date de départ
Scénario nominal
1. L’aéronef départ de l’aéroport de départ spécifié dans l’exercice.
2. L’utilisateur effectue un clic droite sur un aéronef.
3. Un menu qui contient les informations relatifs à l’aéronef est affiché.
4. L’utilisateur introduit une valeur pour modifier l’angle de rotation.
5. L’aéronef tourne vers l’angle introduit.
6.L’avion passe du mode automatique au mode manuel et devient contrôlée par l’utilisateur.
4.a. En cas de saisie d’une valeur qui dépasse les angles du cercle trigonométrique (<0 ou >360),
le système affiche un message d’erreur qui indique la marge des valeurs possible.
4.b. L’utilisateur reprend l’étape 4 du scénario principal.
Tableau 4.3 : Description textuelle du cas d’utilisation «Modifier l’angle de rotation de

l’aéronef»
4.1.3 Conception
4.1.3.1 Diagramme d’activité du cas «Modifier l’angle de rotation»
Le diagramme d’activité de la figure 4.3 représente les étapes à suivre par un instructeur ou
pseudo-pilote pour qu’il puisse changer l’angle de rotation de l’aéronef.
53
Utilisateur En-Route Radar
Afficher l'aéronef dans l'aéroport

de départ allant vers l'aéroport
d'arrivé en parcoutant les points
Effectuer un clic droit sur l'aéronef
de cheminement en respectant
les rotations exactes entre les
points
Afficher le menu des paramètres
Introduire une valeur d'angle de

rotation
Si la valeur est entre 0° et 360°
sinon
Annuler toutes les

Afficher un message
destination de
d'erreur
l'aéronef
Tourner l'aéronef vers

l'angle introduit
Figure 4.3 : Diagramme d’activité «Modifier l’angle de rotation»
4.1.4 Réalisation
Durant cette partie nous allons expliquer les interfaces de chaque radar avec des captures
d’écran de l’application.
4.1.4.1 En-Route Radar
La figure 4.4 montre un extrait des données des positions réelles que nous avons utilisé pour
localiser les aéroports dans l’En-Route Rada.
54
Figure 4.4 : Extrait des positions exactes des aéroports
La figure 4.5 représente les Waypoints (voir annexe) d’un aéronef dont l’aéroport de départ
est l’aéroport de Tunis-Carthage et l’aéroport d’arrivée est Avalon.
Figure 4.5 : Chemin de DTTA (Tunis-Carthage) à YMAV (Avalon)
La figure 4.6 représente l’interface de l’En-Route radar et le départ de l’aéronef de l’aéroport

de Tunis-Carthage (DTTA)
55
Figure 4.6 : Interface de départ de l’aéronef dans l’En-Route Radar
La figure 4.7 représente des captures du mouvement exacte de l’aéronef suivant les Waypoints
de la figure 4.5
Figure 4.7 : Mouvement de l’aéronef dans l’En-Route Radar
56
En cliquant sur le bouton droit de la souris, un menu qui contient les paramètres de l’aéronef
apparaît. La figure 4.8 représente le menu des paramètres de l’aéronef
Figure 4.8 : Menu des paramètres de l’aéronef dans l’En-Route Radar
Si l’utilisateur introduit une valeur illogique le système affiche un message d’erreur comme
indique la figure 4.9
57
Figure 4.9 : Message d’erreur En-Route Radar
Si l’utilisateur introduit une valeur valide l’aéronef atteint progressivement la valeur comme
représente la figure 4.10
58
Figure 4.10 : Modification de l’altitude
Les altitudes et les vitesses maximales des aéronefs dépendent de la performance de chaque
aéronef, nous pouvons citer les caractéristiques générales des aéronefs :
— Modèle de l’aéronef : Chaque modèle d’aéronef peut avoir des performances, des altitudes
maximales et des vitesses maximales qui lui sont propres en fonction de ses caractéristiques
techniques et de sa conception.
— Masse de l’aéronef : La masse de l’aéronef peut être légère, moyenne ou lourde. Elle a un
impact sur ses performances en termes d’altitude et de vitesse. Les aéronefs plus lourds
peuvent avoir des altitudes de croisière plus élevées, tandis que les aéronefs plus légers
peuvent atteindre des vitesses plus élevées. [15]
Si la différence d’altitude entre deux aéronef est inférieur à 5000 ft, et la distance entre deux
aéronef est inférieur à 3.3 NM, il y a un risque de collision et le contrôleur doit interagir. [16]
59
Figure 4.11 : Distance entre les aéronefs
S’il y a un risque de collision, le système affiche un cercle rouge qui entoure l’aéronef pour
alerter l’utilisateur comme indique la figure 4.12
Figure 4.12 : Risque de collision
60
4.1.4.2 Approach Radar
Nous commençons par l’interface d’approche radar initiale illustrée à la figure 4.13 Ce type
de radar couvre la zone d’approche de l’aéroport dont le rayon est 120 km radius.
Nous pouvons aussi consulter le temps de simulation de l’exercice ainsi que la liste des
aéronefs de l’exercice.
Figure 4.13 : Interface initial de l’Approach Radar
La figure 4.14 montre le chemin d’un aéronef dans la zone d’approche :
Figure 4.14 : Aéronef dans la zone d’approche
La figure 4.15 montre des aéronef en cours de décollage dans la zone d’approche, et les
informations nécessaires sur l’aéronef que l’utilisateur à cliqué sur comme dans le radar d’en-
route mais dans la zone d’approche :
61
Figure 4.15 : Menu dans la zone d’approche
4.1.5 Revue du sprint
Après une réunion avec le Scrum-Master et le Product-Owner, il a été convenu que le plan
de sprint était cohérent avec ce qui a été accompli au cours de cette première itération. Cela
signifie que le sprint a été validé.
4.2 Sprint 3 : Représentation de la tour de contrôle

Pour commencer, nous avons établi une liste des tâches à accomplir pour ce Sprint. Le plan
de cette itération comprend deux User Story telles que définies dans le tableau 4.2.1.
User Story Tâches

En tant que contrôleur, pseudo-pilote - Documentation sur les méthode de partage des écran dans
ou instructeur, je souhaite un environnement virtuel
voir les écrans du simulateur - Utiliser un Plug-in de partage d’écran
de contrôle de trafic aérien dans - Ajouter la possibilité de choisir une fenêtre et de l’afficher.
un environnement virtuel similaire - Préparation de l’environnement de la tour de contrôle de
au monde réel. l’aéroport.
62
En tant que contrôleur, pseudo-pilote - Importer les packages de XR Interaction Toolkit

ou instructeur, je souhaite - Activation et test de la Camera (XRCamera) et le HAND-
avoir la possibilité de positionner TRACKING sur la casque de réalité virtuelle
l’écran dans l’environnement. - Ajouter l’intéraction avec l’écran après le partage.
- Ajouter la possibilité de positionner l’écran
Tableau 4.4 : Backlog du troisième Sprint
Dans cette partie nous allons identifier les besoins fonctionnels de la représentation de la
tour de contrôle avec la réalité virtuelle. Ensuite nous allons tracer les diagrammes de cas
d’utilisation et enfin, nous allons faire la description textuelle de quelques cas.
4.2.3 Détails des besoins fonctionnelles
Voici la liste des grandes fonctionnalités que notre application doit offrir :
— Consulter les écrans du simulateur de contrôle de trafic aérien dans un environnement

virtuel.
— Positionner les écrans du simulateur.
4.2.3.1 Diagramme de cas d’utilisation
Le diagramme de cas d’utilisation de la figure 4.16 explique les cas d’utilisations globales
de l’application de la représentation de la tour de contrôle.
63
Diagramme de cas d'utilisation: Représentation de la tour de contrôle
Consulter les
écrans du simulateur de
contrôle de trafic aérien dans
la tour de contrôle
Contrôleur
Pseudo-Pilote Positionner l'écran partagée
Instructeur
Figure 4.16 : Diagramme de cas d’utilisation de la représentation de la tour de contrôle
4.2.3.2 Diagramme de cas d’utilisation raffiné
Diagramme de cas d'utilisation raffiné
Consulter les
Choisir l'écran à
écrans du simulateur de include
afficher
contrôle de trafic aérien
Contrôleur
Pseudo-Pilote
Instructeur
Figure 4.17 : Raffinement du cas d’utilisation «Consulter les écrans du simulateur de

contrôle de trafic aérien»
64
4.2.3.3 Description textuelle du cas d’utilisation «Choisir l’écrans à visuali-

ser»
Titre Choisir les écrans à afficher
Acteurs Contrôleur, Instructeur, Pseudo-pilote
Pré conditions Les fenêtres du simulateur sont ouvertes dans l’ordinateur
Scénario nominal
1. Le système affiche un menu contenant un bouton «GetScreenCapture»,
une liste déroulante (Drop-Down), et un bouton «Start Sharing»
2. L’utilisateur clique sur «GetScreenCapture».
3. Le système génère la liste des fenêtre ouvertes.
4. L’utilisateur choisit l’écran à visualiser à partir le la liste.
5. L’utilisateur effectue un clic sur le bouton «Start Sharing»
6. Le système commence à partager l’écran que l’utilisateur a choisi
5.a. Si l’utilisateur choisit «Start Sharing» sans choisir l’écran le système affiche un écran blanc.
Tableau 4.5 : Description textuelle du cas d’utilisation «Choisir l’écrans à visualiser»
65
4.2.4 Conception
4.2.4.1 Diagramme d’activité «Choisir l’écran à visualiser»
Utilisateur Système
Choisir un bouton Afficher un menu
Choisir le bouton Générer la liste des fenêtres

<<GetScreenCaptures>> ouvertes
Choisir le bouton <<StartSharing>>

écran n'a pas choisi
un écran
si a choisi
un écran
Afficher l'écran Afficher un écran

choisir blanc
Choisir un écran à
partir de la liste
Figure 4.18 : Diagramme d’activité «Choisir l’écran à visualiser»
4.2.5 Réalisation
Dans cette partie nous allons expliqué les différentes étapes de réalisation de ce sprint. Nous
avons implémenter dans cette partie un Plug-in, "Agora" qui fournit des éléments de base qui
vous permettent d’ajouter des communications vocales et vidéo en temps réel grâce à un SDK.
Il permet aux utilisateurs d’un canal de partager ce qui se trouve sur leur écran avec les autres
utilisateurs du canal. Cette technologie est utile dans plusieurs scénarios de communication en
ligne, tels que le partage d’une image locale ou d’une page web pour une discussion ou comme
notre cas, le partage d’une fenêtre d’une application.
Nous commençons pas la première phase, la préparation de l’interface où l’utilisateur va se
trouver dans la tour de contrôle de l’aéroport comme représenté dans la figure 4.19.
66
Figure 4.19 : Interface de la représentation de la tour de contrôle
Nous pouvons aussi consulter le menu où l’utilisateur va choisir l’écran à visualiser comme
montre la figure 4.20. Dans ce cas, l’utilisateur a choisi de visualiser le Ground Radar :
Figure 4.20 : Choisir un écran
Si l’utilisateur a choisi de visualiser l’En-Route radar les système l’affiche comme représenté
dans la figure 4.21
67
Figure 4.21 : Choisir l’En-Route Radar
Conclusion
En conclusion, le troisème sprint est consacré à l’immersion de l’utilisateur d’AeroSimex dans
un environnement virtuelle. Nous avons surmonté les défis techniques qui se sont présentés et
intégré avec succès un plugin de partage d’écran dans notre application Unity. En outre, nous
avons développé des diagrammes du cas d’utilisation détaillés et la conception, puis nous avons
procédé à la phase de test qui comprenait les interfaces de la partie développée. Enfin, nous
avons procédé à un examen approfondi du sprint pour garantir la qualité de notre travail.
68
Conclusion générale
La réalisation de ce projet de fin d’étude nous a permis de développer un simulateur de

contrôle de trafic aérien local. Tout au long du projet, nous avons suivi une méthodologie pour
concevoir et développer l’application en s’assurant de répondre aux besoins des utilisateurs.
Dans ce rapport, nous avons présenté le contexte et la problématique du projet ainsi que l’or-
ganisme d’accueil Avaxia Group. Nous avons également effectué une étude des applications
existante pour comprendre les applications de contrôle de trafic aérien existantes et identifier
les lacunes. Nous avons ensuite présenté notre solution proposée et décrit la méthodologie de
travail et la planification utilisées.
Nous avons également présenté l’étude fonctionnel qui comprend l’analyse des besoins, le dia-
gramme de cas d’utilisation global, le style architectural et le backlog du produit. Enfin, nous
avons détaillé les releases et les sprints que nous avons réalisé.
Au terme de ce projet, nous avons réussi à développer une application de contrôle de trafic
aérien fiable, facile à utiliser et dotée d’une expérience d’immersion qui rend l’expérience plus
réaliste. En développant ce logiciel, nous avons rencontré quelques difficultés dans la collecte des
données réelles des aéroports et des Waypoints et pour avoir une simulation réelle du mouvement
de l’aéronefs. En guise de perspectives, Nous visons à améliorer notre solution en l’adaptant
aux différents aéroports. Il est possible également d’ajouter de nouvelles données pour rendre
l’expérience plus précise et performante. De plus, il est possible d’ajouter d’autres données
des exercices. Ces perspectives offrent de grandes opportunités pour améliorer l’efficacité et
la qualité des applications, ce qui est bénéfique pour les stagiaires de l’ATC. Nous sommes
convaincus que notre application aidera à former les futurs contrôleurs et les aider à vivre une
expérience immersive. Nous avons travaillé avec rigueur tout au long du projet, en mettant en
œuvre les meilleures pratiques et en respectant les délais.
Les résultats obtenus sont si encourageants que l’entreprise a décidé de présenter notre tra-
vail lors d’un événement international à l’étranger. Cette opportunité démontre non seulement
la valeur de notre contribution, mais elle renforce également notre engagement envers l’excel-
lence et l’innovation. Travailler au sein de cette entreprise nous offre une opportunité précieuse
d’acquérir une expérience professionnelle de haut niveau et de développer nos compétences en
matière de mise en œuvre d’applications performantes. Nous sommes enthousiasmés par cette
expérience enrichissante et impatients de relever les défis qui nous attendent.
69
Annexe
Air Traffic Control (ATC) : Contrôle de trafic aérien
Aérodrome : Surface spécialement aménagée (sur terre ou sur l’eau) pour permettre aux
avions de décoller ou d’atterrir, et doté de l’infrastructure nécessaire pour leurs évolutions
au sol. Un aérodrome comprend éventuellement des bâtiments, des installations, tour de
contrôle, aires de stationnement, ateliers de réparations et de vérifications, etc.). Le mot
aérodrome est dérivé des mots grecs aeros qui signifie "air" et dromos qui signifie "route"
ou "parcours", donc aérodrome signifie littéralement parcours aérien.[17]
Aéronef : Appareil capable de se déplacer dans les airs.
Callsign : La plupart des compagnies aériennes utilisent un indicatif d’appel. Il s’agit du

nom utilisé pour appeler l’avion.
Piste : Les pistes sont les surfaces d’un aérodrome, réservées au décollage et à l’atter-
rissage des aéronefs (avions, planeurs, hélicoptères, etc.).[17] Elles peuvent être en béton,
en bitume, en asphalte, en herbe, en plaques en acier perforées ou Pierced Steel Planking
(PSP), juste en terre battue ou recouverte de neige (altiports).[17]
Exercice : L’instructeur principal a le rôle d’administrateur du système. Il dispose d’une

multitude d’objets installés pour préparer une bibliothèque d’exercices prédéfinis.
Scénario : L’exercice est composé des acteurs et d’un scénario :
— Acteurs tels que les postes de contrôleurs exécutifs et les pseudo-pilotes (un ou deux
peuvent être choisis).
— Poste de travail pour la planification des vols (points de départ et d’arrivée, temps
estimé en route, aéroports de remplacement en cas de mauvais temps, type de vol,
etc.)
— Plan d’exercice spécifiant les vols qui seront inclus dans l’exercice, ainsi que le mo-
ment et la manière dont ils se présenteront.
— Conditions météorologiques (telles que la vitesse et la direction du vent, la densité

des nuages, etc.)
— les conditions d’urgence.
70
Annexe
Les radars de surface ou SMR : Les radars de surface permettent de localiser les
véhicules et aéronefs sur les parkings, les taxiway ou les pistes. Ces radars primaires
permettent de coordonner les mouvements au sol pour éviter les accidents. Ils sont utilisés
par les contrôleurs aériens pour compléter les observations visuelles. [17]
Departure : Le processus de départ de l’aéronef de l’aéroport de départ.
Arrival : Le processus de l’atterissage de l’aéronef à l’aéroport d’arrivé.
Training : Les aéronefs qui sont dans la phase d’entrainement et qui vont faire un tour
sur l’aéroprot et revenir vers le parking.
Instruction : Une instruction est une commande passée par un pseudo-pilote pour guider
l’aéronef pour suivre le bon trajet, nous citons les instructions possible dans le radar de
mouvement de surface :
— Start Up : Démarrage du moteur de l’aéronef.
— Push Back : C’est une procédure aérienne au cours de laquelle un avion est repoussé
vers l’arrière, loin d’une porte d’aéroport, par une force extérieure. Les opérations de
repoussage sont effectuées par des véhicules spéciaux à profil bas appelés tracteurs
de repoussage.
— Taxi : C’est le déplacement d’un aéronef au sol, par ses propres moyens, contraire-
ment au remorquage ou au repoussage où l’aéronef est déplacé par un remorqueur.
L’aéronef se déplace généralement sur des roues.
— Line Up : L’alignement commence lorsque l’aéronef dépasse le point d’attente et se

termine lorsque le fuselage de l’aéronef est aligné avec l’axe de la piste.
— Take Off : C’est la phase du vol au cours de laquelle un aéronef passe d’un dépla-
cement au sol à un vol en l’air.
— Down Wind : Correspond à la phase du vol où l’aéronef suit une trajectoire parallèle
à la piste, mais dans la direction opposée au décollage ou à l’atterrissage.
— Landing : C’est la phase du vol au cours de laquelle un aéronef passe du vol au

déplacement au sol.
— Evacuate Runway : Commence lorsque l’avion quitte la piste et se déplace jusqu’au

bord du "Taxiway".
— Stand : C’est la procédure d’arrêter l’avion au point de stationnement prévu.

Waypoint : C’est un emplacement géographique spécifié utilisé pour définir une route
de navigation de surface ou une trajectoire de vol d’un aéronef. [18]
71
Netographie
[1] “Atc sim 2,” [Consulté le 14-08-2023]. URL : https://atc-sim.com/
[2] “Atc pro,” [Consulté le 15-08-2023]. URL : https://www.atcprosim.com/
[3] “Larousse dictionnary,” [Consulté le 20-09-2023]. URL : https://www.larousse.fr/

dictionnaires/francais/simulation/72824
[4] A. Alizadeh et al., “Design and implementation of a web-based editor optimized for online
gambling games,” 2022.
[5] “Unity,” [Consulté le 20-09-2023]. URL : https://unity.com/fr
[6] K. Schwaber, Agile project management with Scrum. Microsoft Press, 2004.
[7] “Langage uml,” [Consulté le 15-08-2023]. URL : https://www.lucidchart.com/pages/fr/

langage-uml
[8] G. Booch, R. A. Maksimchuk, M. W. Engle, B. J. Young, J. Connallen, et K. A. Hous-

ton, “Object-oriented analysis and design with applications,” ACM SIGSOFT software
engineering notes, vol. 33, no. 5, pp. 29–29, 2008.
[9] S. Bui, “Micro frontend : Microservice implementation on web development,” 2021.
[10] “Qu’est-ce que l’architecture à trois niveaux ?” https://www.ibm.com/fr-fr/topics/

three-tier-architecture, consulté le : [14-08-2023].
[11] “Visual studio 2019,” [Consulté le 20-09-2023]. URL : https://visualstudio.microsoft.com/

ru/vs
[12] G. Alder, “Draw. io-diagrams. net,” dirección : https ://app. diagrams. net, 2021.
[13] “Xr interaction toolkit,” [Consulté le 20-08-2023]. URL : https://docs.unity3d.com/

Packages/com.unity.xr.interaction.toolkit@2.4/manual/index.html
[14] “Agora rtc plugin,” [Consulté le 20-09-2023]. URL : https://pub.dev/documentation/

agora_rtc_engine/latest/
[15] “Aircraft performance database,” [Consulté le 20-07-2023]. URL : https://contentzone.

eurocontrol.int/aircraftperformance
[16] E. Williams, “Airborne collision avoidance system,” in Proceedings of the 9th Australian
workshop on Safety critical systems and software-Volume 47, 2004, pp. 97–110.
[17] “Avionnaire,” [Consulté le 24-09-2023]. URL : https://www.lavionnaire.fr/
[18] “Precision approach,” [Consulté le 24-09-2023]. URL : https://skybrary.aero/
72
Abstract
This report presents the work we carried out during our final year internship. Our project,
AeroSimex, aims to develop an innovative simulation system for air traffic control (ATC). It is designed
for easy use in ATC training institutions, enhancing the realism of training for future air traffic
controllers. This advanced system integrates complete radar systems. Using agile methodologies, we
ensure adaptability to the needs of training establishments. AeroSimex is also revolutionizing ATC
training by offering an immersive virtual environment in the airport control tower.
Résumé:
Ce rapport présente le travail que nous avons effectué pendant notre stage de fin d'études. Notre
projet, AeroSimex, vise à développer un système de simulation innovant pour le contrôle du trafic
aérien (ATC). Il est conçu pour être facilement utilisé dans les institutions de formation ATC,
améliorant ainsi le réalisme de la formation des futurs contrôleurs aériens. Ce système avancé
intègre des systèmes radar complets. En utilisant des méthodologies agiles, nous assurons
l'adaptabilité aux besoins des établissements de formation. AeroSimex révolutionne également la
formation ATC en offrant un environnement virtuelle immersif dans la tour de contrôle de l'aéroport.
‫تلخيص‬
‫ يهدف هذا المشروع إلى إبتكار نظام محاكاة‬.‫يعرض هذا التقرير العمل الذي قمنا به خالل فترة تدريبنا في السنة األخيرة‬
‫ مما يعزز واقعية لمراقبة الحركة الجوية‬،‫تم تصميمه لسهولة االستخدام في مؤسسات تدريب مراقبة الحركة الجوية‬
،‫ باستخدام منهجيات رشيقة‬.‫ يدمج هذا النظام المتقدم أنظمة رادار كاملة‬.‫وتدريب المتربصين في إدارة الحركة الجوية‬
.‫ويعمل أيضًا على إحداث ثورة في التدريب من خالل تقديم بيئة افتراضية في برج المراقبة بالمطار‬
Netographie
74

Rapport de Stage PFE Semah BELHADJ DIT MDALSI

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport de Stage PFE Semah BELHADJ DIT MDALSI

Transféré par

Droits d'auteur :

Formats disponibles

Code PFE : I-212-23

Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

Institut supérieur des Arts Multimédias

Mémoire de fin d’études

Préparé en vue de l’obtention du Diplôme National d’Ingénieur en

Concevoir et mettre en œuvre un simulateur de

Année universitaire : 2022/2023

Au Dieu le tout puissant, notre créateur

À mes chers parents

À tous mes chers amis

Semah BELHADJ DIT MDALSI

Je tiens tout d’abord à remercier, toute l’équipe pédagogique de

Je tiens à exprimer également ma profonde gratitude envers

Je remercie Mme Imen BOUZIRI pour sa volonté d’accepter de me superviser et

Je remercie M Firas BEN SALAH l’encadrant de l’entreprise AVAXIA pour son

Je m’adresse aussi mes vifs remerciements aux consultants de

2 Spécification des besoins 14

3 Release 1 : Radars liés au simulateur 3D 26

4 Release 2 : Radars indépendants et réalité virtuelle 47

1.1 Avaxia Group logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1 Les acteurs du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1 Le système d’éclairage de l’aéroport . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.1 Diagramme du cas d’utilisation de l’En-Route Radar . . . . . . . . . . . . . . . 51

1.1 Comparaison entre PixiJS et Unity . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1 Backlog du premier Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1 Backlog du deuxième Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Le présent rapport est divisé en cinq chapitres présentés comme suit :

— Dans le premier chapitre, nous introduirons le contexte du projet en présentant l’orga-

— Le troisième chapitre portera sur le premier Release du projet, consacré au développement

1.1.1 Présentation de Avaxia Group . . . . . . . . . . . . . . . . . . . . . . . 4

2 Contexte général du projet . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2.1 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2.2.2 Simulation dans l’éducation et les formations : . . . . . . . . 6

1.2.2.3 Simulation dans les écoles de contrôle de trafic aérien : . . . . 6

1.4.1 Description de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.5.1 ATC Simulator 2 : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.5.2 ATC Pro : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

7 Méthodologie de gestion de projet . . . . . . . . . . . . . . . . . . . 13

8 Langage de modélisation UML - Unified Modeling Language . . . 13

1.1 Organisme d’accueil

1.1.1 Présentation de Avaxia Group

Figure 1.1 : Avaxia Group logo

— Nouvelles technologies : Apprentissage automatique, réalité augmentée, réalité virtuelle,

— Expertise technique SAP : Gestion de l’infrastructure, optimisation et réglage des per-

niveau du système, dépannage et gestion des incidents et Audit du paysage.

— Conseil fonctionnel : Conception de solutions d’entreprise pour un nouveau déploiement

— Solutions logicielles personnalisées : Conception et réalisation de solutions logicielles uti-

1.2 Contexte général du projet

La simulation est une représentation du comportement d’un processus physique, industriel,

1.2.2.2 Simulation dans l’éducation et les formations :

1.4 Étude de l’existant

Avaxia a commencé le développement d’un simulateur de contrôle de trafic aérien pour

— Lanceur : Point d’entrée de l’application qui ouvre l’application souhaitée en fonction

— Moteur 3D : Un simulateur 3D de l’aéroport, développé avec Unity, qui propose une

1.4.2 Critique de l’existant

L’application existante que Avaxia a commencé à développer présente un ensemble de fonc-

Technologie PixiJS Unity

— Principalement utilisé pour — Moteur de développement

— Axé sur le rendu graphique — Comprend un éditeur visuel

— Offre des fonctionnalités délisation 3D, des fonction-

suels, et les interactions uti- un moteur de particules, et