Rapport de Stage PFE Semah BELHADJ DIT MDALSI
Rapport de Stage PFE Semah BELHADJ DIT MDALSI
Rapport de Stage PFE Semah BELHADJ DIT MDALSI
Université de la Manouba
Réalisé par
Semah BELHADJ DIT MDALSI
Encadré par
Mme Imen BOUZIRI – ISAMM
M. Firas BEN SALAH – AVAXIA GROUP
À 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.
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
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
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
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
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 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.
— 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.2 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5 Applications Similaires : . . . . . . . . . . . . . . . . . . . . . . . . . 9
6 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
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.
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.
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).
4
Chapitre 1. Cadre du projet
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.
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
5
Chapitre 1. Cadre du projet
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.
— 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.
— 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
Chapitre 1. Cadre du projet
enregistrements.
— Backend Core : Serveur de communication en temps réel utilisant Socket.io pour relier
toutes les autres applications.
— 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.
7
Chapitre 1. Cadre du projet
8
Chapitre 1. Cadre du projet
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.
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
Chapitre 1. Cadre du projet
— 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.
10
Chapitre 1. Cadre du projet
— 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.
11
Chapitre 1. Cadre du projet
— 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.
— 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.
12
Chapitre 1. Cadre du projet
— Travail en équipe.
— 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].
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
Plan
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3 Style architectural . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . 23
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.
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.
16
Chapitre 2. Spécification des besoins
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 toutes les écrans du simulateur de contrôle de trafic aérien dans un envi-
ronnement virtuel.
• Pseudo-pilote :
— Donner des instructions aux aéronefs dans les radars liées au simulateur 3D.
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.
- 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.
17
Chapitre 2. Spécification des besoins
Lancer
Consulter toutes les le simulateur 3D
informations du trafic aérien
dans les radars indépendants
en temps réel.
Instructeur
18
Chapitre 2. Spécification des besoins
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]
19
Chapitre 2. Spécification des besoins
DBM Service
Frontend DBM
React JS
Frontend Core
React JS
2D Core
— Couche de Données : Base de données PostgreSQL. Elle stocke les données né-
cessaires au service DBM.
▷ 3D Core (Développé avec Unity) : Simulateur 3D avec une vue 360° de la tour.
20
Chapitre 2. Spécification des besoins
— 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.
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 :
— 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
Chapitre 2. Spécification des besoins
— 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.
22
Chapitre 2. Spécification des besoins
23
Chapitre 2. Spécification des besoins
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
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]
• Adobe Illustrator 2022 : Outil utilisé pour la création des illustrations vectorielles
assisté par ordinateur.
Dans cette section, nous allons exposer les choix techniques utilisés pour réaliser et implé-
menter la solution.
24
Chapitre 2. Spécification des besoins
2.5.3.1 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
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
Plan
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1 Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
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
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
27
Chapitre 3. Release 1 : Radars liés au simulateur 3D
28
Chapitre 3. Release 1 : Radars liés au simulateur 3D
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 :
— 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
Chapitre 3. Release 1 : Radars liés au simulateur 3D
— 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.
— Donner des instructions (voir annexe) aux pilotes pour que les aéronefs suivent les tra-
jectoires correctes.
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
Chapitre 3. Release 1 : Radars liés au simulateur 3D
Lancer
le simulateur 3D
include
Donner des instructions
aux aéronefs sur la piste de
l'aéroport en temps réel.
Pseudo-Pilote
Instructeur
31
Chapitre 3. Release 1 : Radars liés au simulateur 3D
Lancer
le simulateur 3D
include
Donner des instructions
aux aéronefs dans la zone de
contrôle en temps réel.
Pseudo-Pilote
Instructeur
32
Chapitre 3. Release 1 : Radars liés au simulateur 3D
Lancer
le simulateur 3D
Instructeur
Figure 3.4 : Raffinement du cas d’utilisation «Donner des instructions aux aéronefs»
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
Chapitre 3. Release 1 : Radars liés au simulateur 3D
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.
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.
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.
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.
34
Chapitre 3. Release 1 : Radars liés au simulateur 3D
3.1.3 Conception
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
Chapitre 3. Release 1 : Radars liés au simulateur 3D
Sinon Si Taxi
Choisir l'instruction
Si Taxi
Vérifier la position et la
rotation de l'aéronef
Sinon
Figure 3.5 : Diagramme d’activité «Sélectionner une instruction à partir d’une liste»
36
Chapitre 3. Release 1 : Radars liés au simulateur 3D
Start Up
Hold
Taxiing Resume Holding
Taxi fini
Line Up
Line up fini
Lining Up Taking Off
Take Off
37
Chapitre 3. Release 1 : Radars liés au simulateur 3D
Land
Landing
Evacuate runway
Evacuating
Runway
Taxi
Hold
Taxiing Resume Holding
Stand
Standing
3.1.4 Réalisation
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
Chapitre 3. Release 1 : Radars liés au simulateur 3D
2. Point d’attente : L’autorisation d’entrer sur la piste est donnée au plus tard à cet endroit.
4. Climb-Out : Montée
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.
39
Chapitre 3. Release 1 : Radars liés au simulateur 3D
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.
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
Chapitre 3. Release 1 : Radars liés au simulateur 3D
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
Chapitre 3. Release 1 : Radars liés au simulateur 3D
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
Chapitre 3. Release 1 : Radars liés au simulateur 3D
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
Chapitre 3. Release 1 : Radars liés au simulateur 3D
Le radar met à jour la position et la rotation exacte du simulateur comme indiqué dans les
figures 3.16 et 3.17
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
Chapitre 3. Release 1 : Radars liés au simulateur 3D
45
Chapitre 3. Release 1 : Radars liés au simulateur 3D
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
Plan
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.1.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.1.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
47
4.2.3 Détails des besoins fonctionnelles . . . . . . . . . . . . . . . . . . . . . 63
4.2.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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.
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.
49
Chapitre 4. Release 2 : Radars indépendants et réalité virtuelle
50
Chapitre 4. Release 2 : Radars indépendants et réalité virtuelle
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.
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
Instructeur
51
Chapitre 4. Release 2 : Radars indépendants et réalité virtuelle
La figure 4.2 représente le raffinement du cas d’utilisation «Modifier les paramètres des
aéronefs»
Modifier l'altitude de
l'aéronef
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»
SOMMAIRE D’IDENTIFICATION
Titre Modifier la vitesse de l’aéronef
Acteurs Instructeur, Pseudo-pilote
DESCRIPTION DES ENCHAÎNEMENTS
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.
Scénario alternatif
52
Chapitre 4. Release 2 : Radars indépendants et réalité virtuelle
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
4.b. L’utilisateur reprend l’étape 4 du scénario nominal.
SOMMAIRE D’IDENTIFICATION
Titre Modifier l’angle de rotation de l’aéronef
Acteurs Instructeur, Pseudo-pilote
DESCRIPTION DES ENCHAÎNEMENTS
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.
Scénario alternatif
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.
4.1.3 Conception
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
Chapitre 4. Release 2 : Radars indépendants et réalité virtuelle
sinon
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
Chapitre 4. Release 2 : Radars indépendants et réalité virtuelle
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.
55
Chapitre 4. Release 2 : Radars indépendants et réalité virtuelle
La figure 4.7 représente des captures du mouvement exacte de l’aéronef suivant les Waypoints
de la figure 4.5
56
Chapitre 4. Release 2 : Radars indépendants et réalité virtuelle
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
Si l’utilisateur introduit une valeur illogique le système affiche un message d’erreur comme
indique la figure 4.9
57
Chapitre 4. Release 2 : Radars indépendants et réalité virtuelle
Si l’utilisateur introduit une valeur valide l’aéronef atteint progressivement la valeur comme
représente la figure 4.10
58
Chapitre 4. Release 2 : Radars indépendants et réalité virtuelle
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
Chapitre 4. Release 2 : Radars indépendants et réalité virtuelle
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
60
Chapitre 4. Release 2 : Radars indépendants et réalité virtuelle
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.
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
Chapitre 4. Release 2 : Radars indépendants et réalité virtuelle
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é.
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.
62
Chapitre 4. Release 2 : Radars indépendants et réalité virtuelle
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.
Voici la liste des grandes fonctionnalités que notre application doit offrir :
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
Chapitre 4. Release 2 : Radars indépendants et réalité virtuelle
Consulter les
écrans du simulateur de
contrôle de trafic aérien dans
la tour de contrôle
Contrôleur
Instructeur
Consulter les
Choisir l'écran à
écrans du simulateur de include
afficher
contrôle de trafic aérien
Contrôleur
Pseudo-Pilote
Instructeur
64
Chapitre 4. Release 2 : Radars indépendants et réalité virtuelle
SOMMAIRE D’IDENTIFICATION
Titre Choisir les écrans à afficher
Acteurs Contrôleur, Instructeur, Pseudo-pilote
DESCRIPTION DES ENCHAÎNEMENTS
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
Scénario alternatif
5.a. Si l’utilisateur choisit «Start Sharing» sans choisir l’écran le système affiche un écran blanc.
5.b. L’utilisateur reprend l’étape 2 du scénario nominal.
65
Chapitre 4. Release 2 : Radars indépendants et réalité virtuelle
4.2.4 Conception
Utilisateur Système
si a choisi
un écran
Choisir un écran à
partir de la liste
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
Chapitre 4. Release 2 : Radars indépendants et réalité virtuelle
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 :
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
Chapitre 4. Release 2 : Radars indépendants et réalité virtuelle
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
69
Annexe
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]
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]
— 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.
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]
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.
— 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.
71
Netographie
[4] A. Alizadeh et al., “Design and implementation of a web-based editor optimized for online
gambling games,” 2022.
[6] K. Schwaber, Agile project management with Scrum. Microsoft Press, 2004.
[12] G. Alder, “Draw. io-diagrams. net,” dirección : https ://app. diagrams. net, 2021.
[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.
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