Development of a Mathematical weighted Formula to

Transcription

EUROPEAN ORGANISATION
FOR THE SAFETY OF AIR NAVIGATION
EUROCONTROL
EUROCONTROL EXPERIMENTAL CENTRE
DEVELOPMENT OF A MATHEMATICAL WEIGHTED FORMULA TO ELIMINATE THE
OVERLAPPING OF AIRCRAFT LABELS ON THE ATC RADAR DISPLAY
EEC Note No. 19/05
Project INO-2AT-STUD
Issued: Novembre 2005
The information contained in this document is the property of the EUROCONTROL Agency and no part should
be reproduced in any form without the Agency’s permission.
The views expressed herein do not necessarily reflect the official views or policy of the Agency.
REPORT DOCUMENTATION PAGE
Reference:
EEC Note No. 19/05
Security Classification:
Unclassified
Originator:
Originator (Corporate Author) Name/Location:
EEC – INO
(InNOvative Research)
EUROCONTROL Experimental Centre
Centre de Bois des Bordes
B.P.15
F - 91222 Brétigny-sur-Orge CEDEX
FRANCE
Telephone: +33 (0)1 69 88 75 00
Sponsor:
Sponsor (Contract Authority) Name/Location:
Centre de Bois des Bordes
B.P.15
F - 91222 Brétigny-sur-Orge CEDEX
FRANCE
Telephone: +33 (0)1 69 88 75 00
WEB Site: www.eurocontrol.int
TITLE:
DEVELOPMENT OF A MATHEMATICAL WEIGHTED FORMULA TO ELIMINATE THE
OVERLAPPING OF AIRCRAFT LABELS ON THE ATC RADAR DISPLAY
Authors
Alain Duverger
Date
Pages
Figures
Tables
Annexes
References
11/2005
viii+36
7+21
-
-
-
Project
INO-2AT-STUD
Task No. Sponsor
Period
1999
Distribution Statement:
(a) Controlled by:
Head of INO
(b) Special Limitations: None
Descriptors (keywords):
Aircraft labels overlapping, label readability, de-conflicting labels, automation, radar display, operational
display system, ODS
Abstract:
On radar display areas with dense traffic the labels associated with the aircraft tracks may overlap with
each other or with track symbols. This phenomenon reduces significantly the readability of the labels. In
case labels are overlapping tracks safety may be affected. In the past different approaches to overcome
the overlapping problem by automation have been realized. Today, none of them provides acceptable
anti-overlapping functionality.
In opposite to previous approaches the study attacks the overlapping problem with a local approach.
Local means local to each aircraft displayed on the screen. The local area for the research for deconflicting labels covers the reasonable distance to the track where a label should be. The study model
preferences and constraints for the label position by different weightings in a mathematical formula. A
research algorithm search then the best possible new labels position starting from the previous label
position. This approach is very flexible and may include any weighted constraint model. The local
approach allows distributed computing for the of the label anti-overlapping problem.
Development of a Mathematical weighted Formula
to eliminate the overlapping of Aircraft Labels on the ATC Radar Screen
PREFACE
Especially in areas with dense traffic labels associated with the aircraft tracks may overlap with other
labels or track symbols displayed on controllers operational display system. This phenomenon
reduces significantly the readability of the labels. In case labels are overlapping tracks safety may be
affected.
Today, controllers mainly arrange manually the track labels in a personally, convenient manner with
the mouse to avoid overlapping.
In the past different approaches to overcome the overlapping problem have been realized. Proposed
solutions refer mainly all to physically based modelling laws. Some simulate electrical charge
(electrostatic, magnetic) for labels and use then the associated physical laws of the repulsion. Others
simulate labels as balls on a horizontal pane attached by springs to the track symbol.
Common to all these solutions based on physical laws is that the movement of any object (label)
influences all other objects, as such systems searching a global solution. This may result in some
kind of label jittering. To avoid jittering strong attenuation is applied to the physical laws. A global
method of overlapping resolution may generate label positions, which are illogical for humans. In
example a label position far away behind other labels, a label position in front of the track and so on.
End of 1998 a technical study of the label overlapping problem was initiated. The research was
executed in collaboration with the ‘Conservatoire National des Art et Métiers – Institut d’Informatique
d’ Entreprise’ in Evry, France. The student Alain Duverger applied for the diploma as an engineer
(specialization – applied mathematic). The study was limited to six month time.
In opposite to previous solution he chooses a local approach for the overlapping problem. Local
means local to the specific aircraft displayed on the screen. This approach is based on the reality
that a solution for the label position has to be in a reasonable distance to the track. This distance
represent he local area for the research of a non-conflicting label position. Duverger developed
therefore an own mathematical formula. The formula respects preferences and constraints for the
label position by different weightings. A grid covers the local research area and with the formula for
each grid cell a position weighting is calculated. With the values of the grid cells a local surface graph
is build. The lowest point of the graph represents the best next label position. A research algorithm
search then this next best possible labels position starting from previous position. The advantage of
this approach is its flexibility for including different weighted constraint models. Even estimated future
aircraft movements can be modelled in the formula. The possibility of distributed computing is
another strong point for the local approach of the label anti-overlapping problem.
The diploma was ending with the development with a JAVA demonstrator with good performance. In
this time, unfortunately the orientation of the EEC research changed and so further work based on
this idea was not done. The diploma is written in French. After this preface you wild find a short coauthored paper in English as quick overview of the realized work. Currently in the EEC, activities with
radar label overlapping restarted and so it seems of interest to make Alain Duverger’s diploma
public.
Horst Hering (EUROCONTROL Experimental Centre),
November 2005
Project INO-2AT-STUD - EEC Note No. 19/05
v
Intentionally left blank
vi
Development of a Mathematical weighted Formula to eliminate the
overlapping of Aircraft Labels on the ATC Radar Display
Horst Hering, Alain Duverger
{ horst.hering, alain.duverger }@eurocontrol.int
Eurocontrol Experimental Centre
BP15, F - 91222 Bretigny sur Orge Cedex
Abstract1
ATC Radar display areas with dense traffic may
cause the overlapping of the two or more aircraft
labels. This phenomenon reduces significantly
the readability of the labels. Today, no algorithm
provide acceptable anti-overlapping.
After a description of the label positioning
context, this paper will undertake a technical
discussion of a new method, with description of
the algorithms based on constraints expressed in
mathematical weightings and explanation of the
resulting display. Some early result from
controller experiments will then be discussed,
and finally the paper will indicate directions for
future improvements.
Introduction
The overlapping of the aircraft labels in high
traffic areas on a radar display is a well known
problem in the modern ATC world. A complete or
partly overlap of two or more AC labels request
special attention of the controller with high mental
demand for the correct reading of the problematic
labels. Therefore more time is needed. Normally,
reading is a routine, background task for humans
that doesn’t affect mental resources. In case of
label overlapping high mental demand is required
for the deciphering. This additional effort
increases
controllers
mental
workload
significantly.
Today, such label problems are mainly
eliminated by the controller. Therefore, the
controller repositions permanently the labels with
his mouse.
Systems for automatic anti-overlapping of labels
exist. Developed systems are mainly based on
ideas borrowed from physical effects. E.g. two
magnetic objects are pushed apart or pulled
together depending of the polarity of their field.
The emulation of a magnetically field for radar
labels is used for the virtual push back between
the labels to eliminate overlapping. The
disadvantage of such systems is shown by the
instability (jittering) of the dynamically (Radar
update) moved labels.
1
The Eurocontrol Experimental Center in Bretigny
(France), studied several different solutions for
the label problem. From different proposed
solutions (e.g. increasing readability, on
mechanical laws based solution) we decided to
promote one in this paper and developed a
demonstrator application. The idea is based on
the calculation of weightings for the positioning of
the Radar labels by the help of a developed
mathematical formula. Therefore the area around
an Aircraft (AC) is overlaid with a grid. This grid
area covers all reasonable label positions around
an AC.
The mathematical formula takes care of different
label parameters like label positioning in relation
to the flight direction of the AC and the label
distance from the AC. Label ‘forbidden’ cells for
their own or others AC symbols and leader lines
are included in the grid. Anticipated AC positions
(own and others) are estimated and weighted by
the formula to find the best new AC label
position.
Based on these conditions a label is moved from
the current to the new position by an animation.
Requirements
An automatic anti-overlap module should
anticipate controllers effort of continuos label
repositioning. Therefore the module should fulfil
some major conditions specified in the label antioverlapping requirements [1]. An AC label should
never overlap or interfere with another label, AC
position symbol, AC speed vector or AC track
history. The leader line of a label should not
cross any label leader line or speed vector of an
AC. Smooth label movements are included in
these requirements. As promoted by an existing
study [2] on label animation.
The demonstrator module has implemented
these conditions. But the crossing conditions
generate heavy constraints so crossing of leader
lines and labels are not always guaranteed.
Weighted Label Parameters
The chosen approach for the problem may be
described best as an individual solution for one
AC. The individual AC needs some kind of
intelligent agent knowing the AC environment.
Spring 2000
vii
Therefore the AC environment is split into
individual cells. A cell may be empty or occupied.
For the solution of the problem a very simple rule
may be established now:
A label cannot occupy occupied cells!
Priorities and gradations may be applied to this
rule. The intelligent AC label agent needs
information on the preferred label positioning.
This piece of information is taken from the
evaluation of different label default parameters.
Figure 2 shows as an example of evaluation
values (min–default–max) for the label position
angle in relation to the AC fight direction.
LFT0098
350^
Label
MUN
775
Figure 3: Evaluation of the angle between AC
direction and label position
AFR7535
290^
PAR
850
Computation of the AC environment grid cells
evaluated with the previous conditions gives the
graphic representation shown in figure 3.
The label distance from the AC symbol is
evaluated in a similar way.
occupy
empty
Figure1: Empty and occupied grid cells
Label
Evaluation
100
50
Figure 4: Evaluation of the label AC distance
Angle
0
90°
135°
180°
0°
Figure 2: Function for the evaluation of the
angle between AC direction and label position
Adding weightings to the evaluation of the angle
(a) and the distance (d) of the label result in the
following function for the evaluation of a grid cell
(figure 5). These functions are symmetric and
could provoke continuous swapping of the label
therefore a move penalty (m) is introduced in the
formula.
F(P) = (α∗a(P)+β∗d(P)+ϒ∗m(P))/(α+β+ϒ)
viii
To increase the probability of finding the global
maximum we start the heuristic research from the
same starting point in eight different directions.
Based on the idea that the current label position
was the best one of the previous search, we start
the new evaluation at this point (1). Figure 7
shows in an example the implemented search
algorithm in red.
1
2
Figure 5: Final evaluation of the Function
(angle and label distance)
4
3
Search algorithm
The proposed function is rather complex and
seems not to have special properties. Therefore
only a very simple heuristic search is proposed to
find the most adapted cell to the label problem.
Starting at an arbitrary point this method follows
the grid cells with the highest increasing values
to find the highest value.
It is clear that this simple search algorithm will
not always give in the best value for the AC
environment. The result of this complex function
depends on the arbitrary starting point of the
search. It can be a regional or global maximum of
the specific AC environment.
#
##
##
80
85
81
##
78
79
##
67
75
##
7
##
63
72
13
53
58
65
15
48
45
50
47
60
55
62
##
##
##
##
##
Starting point
Figure 6: Heuristic research function
Figure 7: Research algorithm
From these the best regional maximum is
selected for the new label position. In the case
the selected maximum has not reached a
predefined threshold, a new search cycle is
started from the real AC (2) position now.
In the shown example the next label would be
moved to point (3). (4) indicates the global
maximum of the function which wasn’t detected
by the employed search algorithms.
The example of figure 7 shows the evaluated
area of an individual AC including ‘forbidden’
(black/dark-grey) squares. These black squares
represent, as shown in figure 1 the occupied cells
by AC symbols, speed vectors and labels of the
examined AC and of other conflicting AC in the
area. The attenuated to dark-grey squares result
from probably in the future occupied cells by
anticipated AC position symbols, vectors and
labels.
Implementation and
performance
The anti-overlap demonstrator was designed as
a plug and play Java component. For a first
evaluation we used a fix traffic sample with
nearly ten crossing AC trajectories. Running the
demonstrator on a an Intel Pentium II PC with
266MHz clock a mean CPU time of
approximately 200 milliseconds per evaluated AC
was measured. The evaluation time increase with
the complexity of the AC environment. In
example a figure 7 equivalent problem would
need 200–300 milliseconds CPU time. In this
ix
state the demonstrator was presented to some
controllers for quick evaluation. Their feedback
gave positive reaction concerning the innovative
part of the approach and performance/reliability.
In a second step the developed anti-overlap Java
components have been added as a component
to the TOCCATA [3] platform. In a traffic sample
with about 20 AC (at the same time in the display
area) no significant changes in performance and
reliability have been detected.
Conclusion
The development of the anti-overlapping module
shows very good performance and achieved
nearly all given requirements. The very high
constraints of label leader lines crossing still
cause some problems.
The selected research direction for the antioverlap problem is a promising basis for further
research on the evaluation function, searching
algorithm for the maximum value and
anticipation. Especially the chosen research
algorithm which cannot always find the global
maximum should be optimised. This is the
reason why label instabilities can be observed
sometimes.
Following preliminary evaluation results, the preoperational PROVE [4] project has decided to
integrate the anti-overlap Java component for indepth evaluation and validation in the newt few
months.
x
Reference
[1] A. Dorbes. Radar Label Anti-overlap
Requirements, Eurocontrol working paper ADW
99001, 1999
[2] C. Mertz, JL. Vinot. Touch Input Screens and
Animations: More Efficient and Humanized
Computer Interactions for ATCO”, CENA Internal
Report, 1999
[3] TOCCATA, CENA Internal Report, 1998
[4] http://www.eurocontrol.fr/projects/prov
CONSERVATOIRE NATIONAL DES ARTS ET METIERS
INSTITUT D’INFORMATIQUE D’ENTREPRISE
Fiche signalétique
Mémoire en vue d’obtenir le diplôme d’ingénieur IIE.
Recherche de solutions au problème
de chevauchement de labels
Auteur : Alain Duverger
Directeur de mémoire : Horst Hering, EUROCONTROL
L’écran radar des contrôleurs aériens comporte une multitude d’informations
contenues dans des étiquettes. Ces étiquettes, du fait de leur grand nombre se
chevauchent fréquemment rendant leur contenu illisible. Il s’agit de rechercher un
algorithme permettant d’éviter ces chevauchements de façon automatique.
1
Résumé du mémoire
Sur les écrans radar des contrôleurs aériens apparaissent un grand nombre d’informations.
A chaque avion présent dans le secteur contrôlé est associé une étiquette (un label) contenant un
certain nombre d’information sur ce dernier (nom, altitude ,vitesse…). Ce label est positionné près
de l’avion et le suit dans ses déplacements.
De nos jours, le trafic aérien ne cesse d’augmenter et donc le nombre de ces labels
augmente de même. Par conséquent, il arrive de plus en plus fréquemment que des labels se
chevauchent, rendant les informations qu’ils contiennent illisibles. Les contrôleurs sont donc
obligés d’intervenir manuellement (avec une souris par exemple) afin de réorganiser les labels.
L’objet de la recherche est donc de trouver une méthode, un algorithme, permettant de
résoudre ce problème de façon automatique et, ainsi, soulager les contrôleurs de ces interventions
manuelles qui peuvent les gêner dans leur travail.
Le fait que le temps dont on dispose pour résoudre le problème entre chaque mouvement
des avions est assez court (de l’ordre de 8 à 10 secondes entre deux mises à jour) et aussi le fait
que la solution ne doit pas gêner le contrôleur (mouvements intempestifs des labels par exemple)
limitent quelque peu la recherche.
Pour approcher ce problème, il faut d’abord connaître ce qui a déjà été tenté sur le sujet.
Dans le cas de ce problème, aucune solution n’est en application actuellement. Puis il faut étudier
les approches possibles pour résoudre le problème. Enfin, il faut tester ces approches en simulant
un trafic ou, pourquoi pas, en l’intégrant dans un centre de contrôle.
Il n‘existe aucune solution à ce problème qui soit appliquée actuellement dans un centre de
contrôle. La seule solution testée jusqu’à présent est une solution développée par le Centre
d’Etude sur la Navigation Aérienne (CENA) mais elle a peu de chance d’être validée du fait de
certains défauts. Le but est donc d’apporter une approche différente du problème afin d’éviter les
défauts de la solution du CENA. Cette approche peut être une approche plus scientifique ou, du
moins, plus mathématique.
La recherche a abouti à une solution utilisant une approche à la fois technique, pour la
gestion des recouvrements, et mathématique, pour la recherche de la meilleure position d’un label
à un instant donné. L’objectif de la solution est de rechercher à chaque instant la meilleure
position c'est-à-dire la position la plus proche de la position idéale par rapport à l’avion
(déterminée selon des critères d’ergonomie) en évitant les chevauchements.
Pour cela, on créer une fonction d’évaluation des positions du label relativement à la
position idéale et l’on cherchera à la maximiser sous contrainte de ne pas provoquer de
chevauchements (éviter certaines positions). On ajoute à cela une notion d’anticipation des
mouvements afin de prévoir les chevauchements plus à l’avance.
La solution développée va être testé sur une plate-forme de prototypage afin d’être évaluée
sur un trafic simulé. Elle va aussi être implantée sur une plate-forme pré-opérationnelle qui sera
soumise à un vrai trafic aérien et testée par des contrôleurs dans des situations réelles.
Une grande partie de la recherche et notamment la recherche de la position idéale à été
aiguillée par le document « Anti-overlap requirements » rédigée par S. Dorbes, ergonome à
Eurocontrol. Ce document a pour but de fixer les limites et exigences que doit respecter un
algorithme d’anti-recouvrement.
2
Project INO-2AT-STUD- EEC Note No. 19/05
TABLE DES MATIERES
I.
ENVIRONNEMENT.............................................................................................................................................. 5
1.
2.
II.
CENTRE EXPERIMENTAL D’EUROCONTROL .......................................................................................................... 5
ENVIRONNEMENT HUMAIN ET TECHNIQUE ........................................................................................................... 5
OBJET DE LA RECHERCHE............................................................................................................................ 6
1.
CONTEXTE ........................................................................................................................................................... 6
a) Le travail du Contrôleur aérien ..................................................................................................................... 6
b) Le poste de travail (CWP) .............................................................................................................................. 8
c) Présentation du projet SmartControl (ancien MIT) ....................................................................................... 9
2. LE PROBLEME DE CHEVAUCHEMENT DE LABELS ................................................................................................ 11
a) Description................................................................................................................................................... 11
b) Solution actuelle........................................................................................................................................... 12
III.
ETUDE DU PROBLEME................................................................................................................................. 13
EXISTANT .................................................................................................................................................................. 13
« ANTI-OVERLAP REQUIREMENTS » ........................................................................................................................... 13
APPROCHES................................................................................................................................................................ 14
a) Deux approches............................................................................................................................................ 14
b) Plus loin dans la deuxième approche........................................................................................................... 15
IV.
SOLUTION ADOPTEE.................................................................................................................................... 17
1.
GESTION DES RECOUVREMENTS ......................................................................................................................... 17
a) Grille ............................................................................................................................................................ 17
b) Forme des éléments...................................................................................................................................... 18
2. GESTION DES « ANTI-OVERLAP REQUIREMENTS » .............................................................................................. 19
a) Fonction d’évaluation .................................................................................................................................. 19
b) Recherche de maxima de la fonction d’évaluation....................................................................................... 22
c) Les contraintes d’anti-recouvrement dans la fonction d’évaluation ............................................................ 26
d) Anticipation .................................................................................................................................................. 28
V.
IMPLEMENTATION DE LA SOLUTION...................................................................................................... 30
1.
STRUCTURE ........................................................................................................................................................ 30
a) Structure générale ........................................................................................................................................ 30
b) Structure du module Supervisor ................................................................................................................... 31
2. DANS LE DETAIL................................................................................................................................................. 33
a) Fonction d’évaluation .................................................................................................................................. 33
b) Implémentation de l’euristique..................................................................................................................... 33
VI.
CONCLUSION .................................................................................................................................................. 35
LA RECHERCHE .......................................................................................................................................................... 35
LES APPORTS DU STAGE ............................................................................................................................................. 35
VII.
REMERCIEMENTS........................................................................................................................................ 36
3
Intentionally left blank
4
I. Environnement
Organisme d’accueil: EUROCONTROL
BP 15, F-91222 BRETIGNY sur Orge CEDEX
Tel: 01.69.88.75.00
Directeur du Mémoire: Horst HERING
Tel: 01.69.88.73.84
Tel du stagiaire: 01.69.88.73.42
1. Centre Expérimental d’EUROCONTROL
EUROCONTROL, organisation européenne pour la sécurité de la navigation aérienne
compte 22 états membres : Allemagne, Belgique, France, Luxembourg, Pays Bas, Royaume Uni,
Irlande , Portugal, Grèce, Turquie, Malte, Chypre, Hongrie, Suisse, Autriche, Norvège, Danemark,
Slovénie, Suède, République tchèque, Italie et Roumanie, et récemment Monaco.
Fondé en 1960, dans le but de superviser le contrôle du trafic aérien dans l’espace des pays
membres, EUROCONTROL a comme but principal le développement d’un système de contrôle
du trafic aérien cohérent et coordonné.
Mon mémoire se déroule au centre expérimental d’EUROCONTROL (EUROCONTROL
EXPERIMENTAL CENTRE) à Brétigny-sur-Orge, au sud de Paris. Le CEE fournit des moyens
pour le design, le développement et l’amélioration des systèmes de contrôle du trafic aérien. Le
site du CEE occupe 90000 mètres carrés de surface, et compte environ 15000 mètres carrés pour
les bureaux, les salles de réunion, les salles d’expérimentation et les ateliers de travail. Le reste du
site est réservé à la simulation en temps réel, qui comprend deux salles de simulation et une salle
contenant un simulateur de vol. Environ 400 personnes sont présentes dans les bâtiments, ceci
incluant des consultants venant d’autres sociétés.
Outre la recherche et le développement de nouveaux outils pour le contrôle aérien, le CEE
possède une salle de simulation permettant à des centres de contrôle européens d’étudier de
nouveaux cas de figure dans leur zone de contrôle (prédiction de l’évolution du trafic, nouvelle
répartition du travail entre les contrôleurs etc.) dans des conditions très proches de la réalité.
2. Environnement humain et technique
La recherche s’est déroulée dans le département Telecomunication & Multimedia
Technologies (TEC). Il a à son actif des projets tels que AudioLAN (IP Telephony) utilisant IPv6
(IP nouvelle génération).
Je suis encadré par mon maître de stage Horst Hering, mais aussi Gilbert Coatleven aussi
rattaché au projet. Je suis aussi en contact avec d’autres personnes telles que Gilles Gawinowski
(chef du département) ainsi que Christian Musson.
Coté matériel, je dispose d’un PC (un pentium II 266MHz) sous Windows NT contenant
les logiciels de Bureautique habituels (Word 97 etc.), ainsi qu’un terminal X connecter à une
machine sous Unix. Je possède aussi un accès Internet ce qui m’aide dans mes recherches.
Je travaille dans le cadre du projet SMARTCONTROL (anciennement MIT) qui a pour but
d’étudier une nouvelle architecture et de nouveaux outils pour le CWP (Controler Working
Position), le « CWP du future ».
5
II. Objet de la recherche
1. Contexte
a) Le travail du Contrôleur aérien
Lorsqu’un avion effectue un vol d’un aéroport à un autre, il doit par avance définir un plan
de vol. Il s’agit d’un ensemble de points de référence (Way Points) qui détermine sa trajectoire. A
l’instar du sol, la navigation aérienne civile possède des routes qu’il faut emprunter (le trajet ne se
fait pas forcement en ligne droite). Ces routes sont caractérisée par des Way Points. Les avions
naviguent selon ces Way Points qui correspondent dans la réalité à des balises radar.
Fig. II.1.a. 1 Exemple de routes de navigation
Le rôle du contrôleur aérien est de diriger les avions traversant un secteur donné. Il ne
s’agit pas simplement de surveiller le bon déroulement du passage d’un avion dans le secteur
contrôlé. En effet, le contrôleur est là pour indiquer à l’avion tous les renseignements et
manœuvres à effectuer pour que ce dernier suive son plan de vol. De plus, il doit détecter et
résoudre d’éventuels conflits intervenant dans son secteur. En fait, le pilote ne prend aucune
décision en ce qui concerne son vol, il suit simplement les instructions des contrôleurs.
6
Le contrôle aérien s’effectue sur trois niveaux : contrôle en route, approche et tour de
contrôle. Ces trois niveaux correspondent à des secteurs de tailles différentes (périmètre plus
grand pour le contrôle en route et plus petit pour les tours de contrôle) et à des altitudes différentes
(hautes altitude pour le contrôle en route et basses pour les tours de contrôle, Fig. II.1.a.1). Lors
d’un vol, un avion passe successivement dans chacun des niveaux de contrôle : tour de contrôle ->
approche -> route, puis route -> approche -> tour de contrôle.
Tour de
Approche
controle
Controle en route
Decollage
Vol
Approche
Tour de
controle
Altitude
Atterrissage
Fig. II.1.a. 2 Succession des différents niveaux de contrôle durant un trajet.
Le contrôle en route correspond à diriger les avions vers leurs Way Points, le contrôle en
approche sert à diriger les avions vers les aéroports et enfin la tour de contrôle gère les
atterrissages et décollages.
Un secteur est contrôlé par un seul poste, il doit donc gérer un grand nombre d’avion en
même temps (jusqu’à 20 à 30 avions dans les cas extrêmes). Lorsqu’un avion passe d’un secteur à
un autre, les contrôleurs des deux secteurs se communiquent les renseignements (en Europe, ces
renseignements sont communiqués par l’intermédiaire de « strips », des bandelettes de papier
contenant des informations diverses : origine, destination, plan de vol, altitude etc.).
Fig. II.1.a. 3 Un « strip »
Il y a donc deux parties différentes dans le travail du contrôleur : dialogues avec les pilotes
et dialogues avec les contrôleurs des secteurs adjacents. C’est pourquoi chaque poste de contrôle
est occupé par deux contrôleurs qui travaillent en collaboration.
7
Ces deux contrôleurs sont le contrôleur radariste (ou exécutif) et le contrôleur organique
(ou planning). Le rôle du premier est de résoudre les conflits et de donner les indications aux
pilotes. Le rôle du second est de s’occuper des transferts de vols d’un secteur à un autre, ainsi que
d’anticiper des problèmes éventuels.
b) Le poste de travail (CWP)
Le CWP (Controler Working Position ou poste de travail du contrôleur) est équipé d’un
écran affichant une image radar du secteur (Radar Display), d’un moyen de communication
(téléphone ou radio), d’une souris (éventuellement un clavier) et d’une imprimante de « strips »
(pour le cas européen).
Fig. II.1.b. 1 Photo d’un CWP durant une simulation à Eurocontrol
De nos jours l’image radar (Fig II.1.b.2) est une image numérique mise à jour
régulièrement (à chaque passage du radar, soit environ toutes les 5 ou 10 secondes) représentant
les positions des avions et plusieurs autres informations le concernant (altitude, vitesse, destination
etc.), elle correspond à l’état réel du trafic. Le contrôleur peut interagir avec cette image par le
biais d’une souris ou d’un clavier.
8
Fig. II.1.b. 2 Un exemple d’écran de CWP (Simulateur STANS).
Lors de l’informatisation de l’écran radar (avec la numérisation des données radar), on a
voulu insérer dans le Radar Display un grand nombre d’informations et d’outils. Par conséquent,
le nombre de données affichées est devenu très important et la lisibilité a diminué.
L’imprimante de « strips » sert à recevoir les informations concernant les avions entrant
dans le secteurs (ces informations sont envoyée par le contrôleur d’un autre secteur).
Les seuls outils utilisés par les contrôleurs sont donc l’écran radar, le téléphone (ou la
radio) et les strips. C’est aussi dans cette direction que le CWP tend à évoluer, c’est-à-dire l’ajout
de nouveaux outils.
Enfin, les contrôleurs dialogues entre eux et avec les pilotes via la radio et/ou le téléphone.
c) Présentation du projet SmartControl (ancien MIT)
Mon travail se situe dans le cadre du projet SMARTCONTROL visant à imaginer le CWP
(Controller Working Position : poste de travail d’un contrôleur aérien) du futur pour le contrôle du
trafic aérien (Air Trafic Control : ATC). Il s’agit en fait de rechercher une nouvelle architecture
(matérielle et logicielle) pour le CWP permettant une plus grande ergonomie et une plus grande
clarté dans la visualisation du trafic aérien.
9
Le projet se décompose en trois parties :
Phase 1
Phase 2
Hardware
Software
Concepts
Fig. II.1.c. 1 Structure du projet SMARTCONTROL
Le partie ‘Hardware’ a pour but la recherche et l’étude des nouvelles technologies pouvant
être envisagées comme solution pour une nouvelle architecture matérielle du CWP. Il s’agit là de
comparer les divers types d’écran existant (LCD, Plasma etc.), les différentes interfaces
matérielles (remplacer la souris par un écran tactile par exemple).
Parallèlement la partie ‘concept’ correspond à la recherche d’une nouvelle façon de
représenter les données, de nouveaux moyens d’interaction entre le contrôleur et le CWP ainsi que
de nouveau outils. C’est dans cette partie que se situe mon travail, il consiste en une amélioration
du Radar Display.
Cette partie a aussi pour but d’alléger le Radar Display en décentralisant les outils et
certaines données.
NOTAM
AH4389
LH373
Altitude: 321
Dest : ALD
25 %
50 %
NOTAM
AH4389
LH373
25 %
Fig. II.1.c. 2 Séparation du Radar Display et des outils
L’étude est désormais faite en collaboration avec le CENA (Centre d’Etude pour la
Navigation Aérienne, l’équivalent français d’Eurocontrol) qui a déjà proposé et réalisé quelques
outils ainsi qu’une plate-forme de test (IVY, décrite en annexe).
10
Enfin, une fois la ‘Phase 1’ terminée, le travail restant à faire correspond au développement
d’un prototype de CWP. Il ne s’agit pas là de créer une application finalisée et directement
utilisable, mais plutôt d’aboutir à des spécifications et surtout à une présentation d’une maquette
de la solution aux principaux intéressés. Ceci pourra permettre d’établir un cahier des charges en
ensuite de sous-traiter le développement de la solution finale.
2. Le problème de chevauchement de labels
a) Description
Actuellement, l’interface visuelle d’un CWP est constituée d’un simple écran. Sur cet
écran s’affiche une grande quantité d’information ce qui provoque souvent une vision très
confuse. En effet, l’écran d’un CWP sert à afficher l’ensemble des avions circulant dans le secteur
concerné, à chacun de ces avions correspond un certain nombre de renseignements le concernant
(altitude, direction, en ascension ou en descente etc.).
Vecteur vitesse
Historique
des positions
Avion
135°
Leader line
20 pxls
AFR7535
290^
PAR
850
Label
Fig. II.2.a. 1 Représentation d’un avion et des différents
renseignements qui l’accompagnent.
Ces données sont affichées dans une étiquette (un label) rattaché à la position de l’avion
(par une ligne appelée « leader line »). Or, le nombre d’avions dans un même secteur peut être très
important (jusqu’à 20 ou 30 voire plus dans le futur), par conséquent, il arrive très fréquemment
que plusieurs labels se superposent rendant la lecture des données impossible (notamment lorsque
plusieurs avions sont en attente dans le même secteur, cf. Fig II.2.a.2). Le problème est assez
simple en soi, mais il est très gênant et il n’y a toujours pas de solution appliquée à l’heure
actuelle. Ce problème soulève aussi l’idée de revoir la façon d’afficher les données.
11
Fig. II.2.a. 2 Problème de chevauchement.
Le but de ce travail est d’étudier diverses solutions déjà envisagées et d’en rechercher
d’autres afin de pourvoir les proposer lors des simulations organisées dans le centre. Les résultats
obtenus seront certainement appliqués à court terme, dans la simulation.
b) Solution actuelle
La seule solution en application actuellement est l’intervention manuelle. C'est-à-dire que
le contrôleur corrige lui-même les problèmes de chevauchement en intervenant sur le
positionnement des labels grâce à la souris. Il est donc constamment en train de repositionner les
labels.
Sur les plates-formes de simulation actuelles, il existe un système d’anti-recouvrement
(décrit plus loin, développé par le CENA), mais est le plus souvent désactivé à cause de son
instabilité et de son incapacité à résoudre certains cas.
12
III. Etude du problème
Existant
Il existe déjà une solution réalisée par le CENA. Elle consiste à considérer que les labels
possèdent un champ magnétique et donc ont tendance à se repousser les uns les autres. Cette
solution présente des points intéressants mais n’est pas efficace à cent pour cent. En effet, lorsque
le nombre de labels est suffisamment grand (et cela arrive fréquemment) les forces magnétiques
ne suffisent plus à les repousser et l’on abouti de nouveau à des chevauchements. De plus, cette
méthode souffre d’une grande instabilité (un label repoussé par plusieurs labels peut avoir un
mouvement vibratoire très gênant pour le contrôleur). Enfin, les labels ne se positionnent pas
toujours convenablement. Il existe des positions préférentielles d’un label par rapport à l’avion
(voir en annexe le papier sur les ‘Anti-overlap requirements’) et surtout, il existe des positions à
éviter. Ce genre de considérations ne sont pas prises en compte par cette algorithme.
Cette solution est actuellement en utilisation dans les simulations à Eurocontrol mais elle
est la plupart du temps désactivée par les contrôleurs qui sont gênés par son instabilité.
« Anti-overlap requirements »
On constate grâce à l’échec de la solution du CENA qu’il y a beaucoup de contraintes que
doit respecter une solution au problème. Ces contraintes sont, pour la plupart d’ordre
ergonomique, elles ont un rapport avec le positionnement du label par rapport à l’avion, le
mouvement des labels etc.
Une étude a été faite sur ces contraintes, le résultat de cette étude se trouve en annexe
(« Anti-overlap requirements »). L’étude est très détaillé et précise, il n’est pas nécessaire, dans un
premier temps, de considérer les contraintes dans le détail.
Voici les contraintes prises en compte dans l’étude qui suit :
Contraintes de non-recouvrement :
Ces contraintes sont la base du problème d’anti-recouvrement.
Un label ne doit pas chevaucher (dans l’ordre de priorité):
- un autre label (contrainte obligatoire)
- un symbole d’avion
- l’historique des positions d’un avion (3 ou 4 symboles)
- la ligne représentant la vitesse d’un avion (contrainte moins importante)
Les « leader lines » ne doivent pas se croiser ni croiser un label. (ces deux contraintes
sont très fortes car elles réduisent énormément le nombre de positions possibles).
13
Contraintes de positionnement :
Ces contraintes correspondent à ce qui est supposé être la meilleure position possible pour un
label (relativement à l’avion qui lui est associé). Cette position est caractérisée par deux critères
principaux :
- angle entre la « leader line » et le vecteur vitesse de l’avion
(par exemple : 135 °)
- distance entre le label et l’avion associé (ou longueur de la « leader line »)
(par exemple : 20 pixels)
La figure II.2.a.1 représente la position caractérisée par les contraintes et les valeurs ci-dessus.
Bien entendu, cette position « idéale » peut être différentes selon les goûts des utilisateurs (un
contrôleur peut préférer que le label soit toujours en haut à droite de l’avion, quelque soit sa
direction). Néanmoins l’étude est effectuée avec ces contraintes comme référence.
Une dernière contrainte vient s’ajouter à cette liste, il s’agit d’une contrainte portant sur la
solution en elle même :
- le mouvement d’un label lors d’un repositionnement ne doit pas dépasser une
certaine distance (par exemple : 40 pixels).
Il existe d’autres contraintes décrites dans le document, mais il s’agit de contraintes beaucoup
plus orientée vers des détails des contraintes principales. Elles seront négligée dans un premier
temps, mais pourrons facilement être prises en compte plus tard.
On peut d’ores et déjà poser deux définitions :
- une solution sera dite admissible si elle respecte les contraintes de nonrecouvrement.
- une solution sera dite optimale si elle respecte les contraintes de
positionnement ainsi que la contrainte de repositionnement.
L’admissibilité pourra être limitée à la contrainte de plus forte priorité (les labels ne se
chevauchent jamais). De même, l’optimalité pourra être considérée comme atteinte lorsqu’une
solution propose des positionnement proche de la « position idéale » (l’optimalité absolue ne peut
bien sur pas être atteinte du fait des contraintes de non-recouvrement).
L’objectif est donc d’obtenir une solution admissible « la plus optimale possible ».
Approches
a) Deux approches
On peut envisager en tout premier lieu deux approches possibles : prévenir ou guérir.
L’approche « guérir » correspond à ne pas chercher à éviter les chevauchements, mais à
essayer de trouver une technique permettant de distinguer les données relatives aux labels lorsque
ceux-ci sont superposés. Il s’agit plus d’une recherche sur l’apparence des labels, par exemple on
peut imaginer d’utiliser des couleurs différentes, des polices de caractères différentes, des tailles
différentes etc. Mais, si cela peut fonctionner avec deux labels (l’œil humain peut faire la
distinction entre deux images superposées), ces méthodes perdent toute leur efficacité dès que le
14
nombre de label dépasse deux, et cela arrive fréquemment. De plus, cette approche assure
l’optimalité mais ne gère pas l’admissibilité du résultat.
Bref, cette approche aboutie rapidement à une impasse. La recherche s’est donc orientée vers
la seconde approche.
L’approche « prévenir » correspond donc à chercher un moyen d’éviter les chevauchements. Il
s’agit de repositionner les labels à chaque instant afin de ne jamais aboutir à un chevauchement.
C’est donc dans cette optique que l’étude va s’effectuer.
b) Plus loin dans la deuxième approche
Ici encore, on peut considérer plusieurs approches :
•
Approche individualiste du problème.
Approche globale du problème.
Approche « passive » du problème (inspirée de la solution développée par le CENA).
Approche individualiste
Il s’agit de considérer les comportements des labels indépendamment (à priori) les uns des
autres. Une solution de ce type doit appliquer des méthodes visant à modifier le mouvement, la
position ou le comportement des labels de façon individuelle.
Cette approche peut s’associer avec la notion d’agent intelligent. Chaque label possède un
comportement qui est régit par son environnement (dans ce cas, les labels alentour). On peut ainsi
établir des règles de comportement qui permettront de ne jamais rencontrer de chevauchements.
L’intérêt de cette approche est qu’avec des règles très simples on peut aboutir rapidement à
une solution admissible. Par contre, il est nécessaire d’étudier plus en profondeurs ces règles pour
obtenir une solution optimale.
•
Approche globale
Cette approche est en opposition avec la première approche car elle correspond à chercher une
solution utilisant les données relatives à l’ensemble des labels en situation de conflit. Par cette
approche, on veut directement aboutir à une solution optimale. On peut imaginer plusieurs
solutions dans cette optique.
Tout d’abord on peut utiliser un module qui supervise les mouvements des labels et qui étudie
à l’avance les conflits éventuels. Etant renseigné sur l’intégralité des mouvements des labels, il
pourrait anticiper les conflits et ainsi modifier les trajectoires. Ce type de solution est plus difficile
à mettre en œuvre car elle demande de détecter les conflits puis de trouver des trajectoires
éliminant ces conflits (sans en créer d’autres bien entendu). De plus, l’admissibilité des solutions
est plus difficile à vérifier.
On peut aussi utiliser un module qui réorganise les labels à chaque étape. L’idée ici est de
modéliser le problème un peu comme un problème d’optimisation mathématique (par exemple :
minimiser les distances entre les labels et leurs avions respectifs, sous contrainte de ne pas avoir
de chevauchement). Mais il est inconcevable de résoudre le problème de façon mathématique.
15
Tout d’abord, parce que le nombre de variables n’est pas fixe (arrivée et départ d’avions dans le
secteur), et surtout, parce qu’il est important (deux à trois variables par label pour un maximum de
20 à 30 labels) et donc les calculs prendrait trop de temps (l’intervalle de temps entre deux mises à
jour est de 5 à 10 secondes en général).
Néanmoins, on peut imaginer un algorithme plus adapté et surtout moins coûteux en temps.
Cette approche peut être soutenue par le fait que les avions empruntent constamment les
mêmes trajectoires (avec très peu de variations, surtout dans le contrôle en route). On peut même
penser à des solutions spécifiques pour chaque secteur, en effet, dans un secteur donné, les conflits
apparaissent toujours dans les même lieux (les croisements de routes par exemple).
•
Approche « passive »
Cette dernière approche est dite passive car elle correspond à « laisser faire les choses ». Elle
est inspirée de la solution du CENA. En effet, l’idée du CENA est d’associer aux labels un champ
magnétique qui fait qu’il se repoussent les uns les autres. A partir de là, il suffit d’observer pour
constater le résultat, les chevauchement disparaissent de façon « naturelle » (dans ce cas précis, la
solution n‘est toute fois pas totalement admissible).
En reprenant cette idée, on peut effectivement imaginer une solution utilisant les lois de la
physique mais, au lieu d’utiliser le magnétisme, on peut utiliser la mécanique et la dynamique.
Cette fois, on considère que les labels sont des volumes (des boules par exemple) qui possèdent
une masse (et donc une inertie) et qui s’entrechoquent (à la différence de se repousser), le lien
avec l’avion peut se modéliser par un lien élastique ce qui permet de conserver une distance
constante et de transmettre au label le mouvement de l’avion.
On est sûr dans ce cas de l’admissibilité de la solution, par contre on n’a aucun renseignement
quant à l’optimalité. On n’est pas sur non plus de la stabilité des labels.
L’intérêt de cette solution est le nombre de paramètres que l’on peut modifier : la masse des
labels, la raideur de l’élastique, les frottements, les quantité de mouvement transmis lors des
chocs... Tous ces paramètres peuvent aider à se rapprocher d’un solution optimale ainsi que
d’augmenter la stabilité.
L’étude de cette solution doit se faire de manière empirique car le comportement de tels objets
est quasiment imprévisible.
16
IV. Solution adoptée
Parmi ces différentes approches, on peut éviter l’approche « passive ». En effet, on ne peut
jamais être sur de la stabilité de la solution et il est difficile de s’approcher l’optimalité. De plus
l’expérience a déjà été faite par le CENA et elle semble mal acceptée par les contrôleurs.
L’approche globale est encore une solution envisageable, d’autant plus qu’il est plus facile
d’anticiper les conflits lorsqu’on a une vue générale sur le problème. Néanmoins, nous laisserons
cette approche de coté, sans pour autant l’abandonner, elle pourra faire l’objet d’une étude
ultérieure.
L'approche développée par la suite est donc l'approche « individualiste ». Il s’agit donc de
déterminer les règles de comportement des labels.
Pour cela, il faut tout d’abord trouver un moyen pour ces labels d’analyser leur
environnement, détecter les situations de conflit avec d’autres éléments (chevauchements) et ainsi
en faire une solution admissible.
Ensuite, il faut trouver les règles permettant d’approcher l’optimalité définie par les
contraintes de positionnement.
1. Gestion des recouvrements
a) Grille
Afin de détecter les conflits dus aux contraintes de chevauchement, l'on pourrait effectuer
des tests sur les positions de chaque label, mais cela ne correspond pas à l'optique de l'approche
choisie. De plus, il y aurait de nombreux tests superflus.
L’approche « individualiste » sous-entend la notion d’agent intelligent, c'est-à-dire un
entité agissant par rapport à son environnement. Dans notre cas, ils s’agit d’un label réagissant à la
présence de labels ou d’avions alentour. Mais c’est juste cette présence qui est importante en soi,
pas l’entité présente (inutile de différencier les labels des avions).
Ainsi, un label doit simplement connaître les zones occupées autour de lui afin de
déterminer s’il est en situation de conflit ou non. D’où l’idée d’établir une « carte » des alentours
du label et, par extension, une carte globale permettant de connaître les zones occupées de l’écran.
Pour cela, il suffit de partager l’écran en un ensemble de cases (ou cellules) ayant deux états
possibles : libre ou occupée.
Chaque objet affiché à l’écran occupe donc un certain nombre de cellules correspondant à
son apparence. Ainsi, un label peut simplement consulter l’état des cellules autour de lui pour
savoir s’il s’approche d’une situation de conflit.
17
LFT0098
350^
AFR7535
290^
MUN
775
PAR
850
Occupée
Iibre
Fig. IV.1.a 1 Occupation des objets dans la grille
On a, grâce à cette grille, un moyen d'assurer l'admissibilité de la solution. En effet, il suffit
d’établir la règle suivante :
« Un label ne peut occuper des cellules déjà occupées. »
Cette règle peut être nuancée afin d’y intégrer les priorités définies par les contraintes
d’anti-recouvrement.
b) Forme des éléments
Dans cette grille, chaque élément possède une forme. Ces formes peuvent être plus ou moins
détaillées sachant que plus le niveau de détail est élevé plus cela réduit le nombre de positions ne
provoquant pas de chevauchement.
La forme d’un avion par exemple peut comprendre seulement un carré contenant sa position
ou, en plus, une forme contenant son vecteur vitesse apparent.
Ce degré de détail permettra de tenir compte ou non des différentes contraintes d’antirecouvrement.
18
Par exemple, pour tenir compte de la contrainte liée aux leader lines (elles ne doivent pas se
croiser ni croiser de labels etc.) il suffit de rajouter à la forme du label une forme contenant la
leader line. Un croisement de leader line sera donc considéré comme un chevauchement de label.
Un nouveau problème apparaît : lorsqu’un label ne peut pas suivre le mouvement de son
avion sous peine de provoquer un recouvrement, il faut maintenant déterminer sa nouvelle
position. Cette nouvelle position est soumise aux contraintes de positionnement définies plus haut.
Il s’agit de trouver des règles comportementales permettant de prendre en compte toutes ces
contraintes et ainsi de pouvoir choisir la position se rapprochant le plus de la position
idéale.
2. Gestion des « anti-overlap requirements »
a) Fonction d’évaluation
Les règles évoquées plus haut sont simples :
- Choisir la position qui fait un angle avec le vecteur vitesse le plus proche de
135°
- Choisir la position dont la distance à l’avion est la plus proche de 20 pixels.
- Choisir la position qui provoquera le plus petit déplacement possible.
Chaque règle est facile à respecter individuellement, mais il est difficile de les respecter
toutes en même temps. En effet, une position optimale pour la première règle n’en est pas
forcément une pour la seconde et vice versa.
Comment faire pour contourner ce problème ? Il faut en faire une seule et même règle..
Pour essayer de respecter la première règle on essai d’évaluer la position par rapport à
l’angle qu’elle fait avec le vecteur vitesse de l’avion. Si cet angle est de 135° on dira que la
position est optimale, si cet angle est de 100° on dira que la position est acceptable, si cet angle est
de 45° on dira que cette position est mauvaise. L’angle étant une valeur entière (voire réelle) on
peut essayer d’évaluer cette position mathématiquement, de 0 à 100 par exemple :
- Angle = 135° => évaluation = 100.
- Angle = 0° - 90° => évaluation = 0.
On considérera la symétrie de l’évaluation en réduisant le domaine de 0° à 180°. 0°-90°
sont des positions à éviter (selon les « anti-overlap requirements », valeur 0), 135° est la position
optimale (valeur 100) et finalement pour 180° on peut considérer que c’est une position acceptable
(valeur 50).
On créer ainsi une fonction d’évaluation de la position selon son angle en interpolant entre
ces valeurs :
19
Evaluation
100
50
Angle
0
90°
135°
180°
0°
Fig. IV.2.a. 1 Fonction d’évaluation selon l’angle entre la leader line et la direction de l’avion
20
De même on peut faire la même évaluation pour la distance en prenant comme valeur (en
pixels) 0-10 pour les valeurs à éviter, 40 pour la valeur optimale et 100 comme valeur maximale
(on ne limitera pas le domaine dans ce cas, toutes les valeurs au delà de la valeur maximales ont
pour évaluation 0) :
Evaluation
100
50
0
10
40
100
Distance
(pixels)
0
Fig. IV.2.a. 2 Fonction d’évaluation selon la distance entre le label et l’avion
Pour le déplacement causé on aura le même genre de fonction avec un optimum à 0 et un
maximum à 40 (par exemple).
Toutes ses évaluations sont fonctions de la simple position P du label, appelons les ‘a(P)’
pour l’angle, ‘d(P)’ pour la distance et ‘m(P)’ pour le déplacement. On cherchera, pour chaque
contrainte, à maximiser la fonction qui lui est associée.
On peut maintenant transformer ces trois contraintes en une seule qui aurait comme
fonction d’évaluation la moyenne des fonctions d’évaluation des contraintes qui la composent :
‘f(P) = (a(P) + d(P) + m(P)) /3’
On peut donner plus d’importance à certaines contraintes par rapport aux autres en
changeant cette moyenne en une moyenne pondérée :
‘F(P) = (α*a(P) + β*d(P) + γ*m(P)) / (α+β+γ)’
La recherche de la position idéale se ramène donc à la maximisation de la fonction F.
21
Si le label se positionne toujours sur le maximum de la fonction d’évaluation, les
contraintes de positionnement sont bien respectée, on a bien une solution optimale.
Le problème est maintenant de trouver ce maximum…
b) Recherche de maxima de la fonction d’évaluation
F est une fonction à variables entières, de forme assez complexe (à base de racines carrées
et de fonctions trigonométriques) ne possédant pas de propriétés particulières. Bref, peu
d’algorithmes de recherche de maximum sont applicables à cette fonction. De plus, elle sera
soumise à des modifications par la suite (prise en compte des contraintes d’anti-recouvrement). Le
plus simple est donc de trouver une euristique de recherche de maximum adaptée au problème.
Fig. IV.2.b. 1 Images des fonctions d’évaluation distance (à gauche) et angle (à droite)
22
Fig. IV.2.b. 2 Image de la fonction d’évaluation finale
Par l’observation de l’image de la fonction sur un domaine assez large on voit que la
fonction n’admet que peu de maxima (sans tenir compte de la contrainte de déplacement : deux
maxima globaux symétriques). Ces résultats sont aisément déductibles en analysant les maxima
des fonctions séparées. De plus, on observe que la fonction est assez régulière, pas de maxima
locaux isolés. En se positionnant en un point quelconque, on peut deviner un moyen d’aboutir au
maximum le plus proche : en suivant la pente de la fonction.
23
La méthode consiste donc à partir d’une position arbitraire et de suivre la direction de plus
grande pente : il faut évaluer les huit positions autour et se « déplacer » dans la position offrant la
pente la plus grande. La progression doit s’effectuer jusqu'à arriver à un maximum (position pour
laquelle les positions alentour n’offre que des pentes négatives).
#
##
##
80
85
81
##
78
79
##
65
67
75
##
7
##
63
72
13
53
58
15
48
50
60
62
##
##
45
47
55
##
##
##
Point de départ
Fig. IV.2.b. 3 Fonctionnement de l’euristique de recherche
24
L’expérience montre que l’euristique, telle qu’elle est implémentée, abouti toujours.
Fig. IV.2.b. 4 Exemple de recherche simple
Le problème est que le résultat n’est pas toujours un maximum global et qu’il dépend du
point choisi au départ. Néanmoins, l’euristique donne de façon générale de bons résultats.
Afin d’éviter les maxima locaux souvent loin de la meilleure solution, l’idée est
d’introduire un seuil à partir duquel on effectue une seconde recherche (à partir d’un autre point de
départ). Si l’évaluation de la solution trouvée est en dessous de ce seuil, on recommence la
recherche à partir d’un nouveau point. La prise en compte des contraintes d’anti-recouvrement, par
la suite, justifie encore plus l’utilisation de ce seuil.
Le point de départ de la recherche choisi est l’ancienne position du label. En effet, si aucun
changement n’est intervenu entre deux étapes, le maximum est toujours le même et donc la
recherche abouti immédiatement.
Le second point de départ (si le seuil n’est pas atteint) est la position de l’avion. Ce choix
s’est fait par l’expérience. En effet, les cas les plus fréquents où le seuil n’est pas atteint sont les
25
cas où la solution trouvée est très éloignée de l’avion, le fait de recommencer la recherche à partir
de la position de l’avion fait que la nouvelle solution sera proche de l’avion. De plus, les maxima
apparaissent proche de l’avion. Encore une fois, ce choix est conforté plus loin lors de la prise en
compte des contraintes d’anti-recouvrement.
L’intérêt de cette euristique est surtout sa simplicité et donc sa facilité à être implémentée.
De plus, elle est très facilement modifiable (choix du déplacement, condition d’arrêt..).
Un autre intérêt est sa rapidité de convergence. En effet, la mise à jour des nouvelles
positions se fait toutes les 8 à 10 secondes, ce qui laisse peut de temps pour les 20 ou 30 labels
d’effectuer cette recherche.
La recherche de maximum dans la fonction d’évaluation reste tout de même une direction
de recherche ouverte. L’euristique présentée ici ne peut, bien sur, pas prétendre être une solution
absolue.
c) Les contraintes d’anti-recouvrement dans la fonction d’évaluation
Les contraintes d’anti-recouvrement définissent des positions « interdites » pour le label.
Ces positions ne doivent donc pas être choisie dans la recherche précédente. Pour cela, il suffit que
la fonction d’évaluation leur donne la valeur 0. On a ainsi une nouvelle version de la fonction
d’évaluation :
‘F(P) = δ * (α*a(P) + β*d(P) + γ*m(P)) / (α+β+γ)’
avec δ
=
0 si la position provoque un chevauchement
1 sinon
On voit ainsi apparaître dans la fonction des zones de valeur 0. Ces zones sont des
obstacles pour l’euristique de recherche. Le « chemin » menant du point de départ au maximum
peut être maintenant obstrué, le résultat retourné par l’euristique sera la limite de cet obstacle.
Il faut donc trouver un moyen de passer ce genre d’obstacle. Pour cela, l’euristique traverse
la zone dans la direction qu’elle suivait jusque là. Néanmoins, le fait de trouver le maximum est
moins certain du fait de ces obstacles. L’intérêt du seuil évoqué précédemment apparaît ici comme
la possibilité de contourner ces zones.
Lorsque le point de départ choisi se situe dans une telle zone, l’euristique effectue
simplement une recherche dans les huit directions, afin de commencer des recherches à partir des
limites de la zone.
On voit ici apparaître l’idée de prendre la position de l’avion comme deuxième point de
départ. En effet, fatalement, la position de l’avion se situe dans une zone de valeur 0 de la fonction
et donc, on effectue huit recherches supplémentaires si le seuil n’est pas atteint.
26
Fig. IV.2.c. 1 Exemple de recherche répétée dans une zone à valeur 0
A moins que l’ensemble du domaine de recherche ne soit de valeur 0, l’euristique trouvera
toujours un point de valeur non nulle. Les contraintes de non-recouvrement sont donc respectées,
on a bien une solution admissible. Sous réserve que l’euristique fournisse le maximum de la
fonction, on a aussi une solution optimale. Les objectifs fixés plus haut sont donc atteints,
néanmoins, la solution présentée ici n’est efficace qu’en théorie (la définition de l’optimalité doit
être étendue). Il manque un facteur important pour bien résoudre les problèmes de conflit, il s’agit
maintenant de les anticiper. En effet, la solution actuelle offre, à un instant donné, une solution
optimale mais à l’instant suivant, la position peut provoquer un conflit, alors qu’une solution, à
priori, moins bonne à cette instant peut s’avérer être la meilleure solution à l’instant d’après (par
exemple).
Il s’agit donc, maintenant d’essayer d’anticiper les conflits.
27
d) Anticipation
Prévoir les conflits, comme évoqué au début de cette partie, relève plutôt de l’approche
globale. On peut tout de même tenter cette anticipation avec le modèle individualiste.
Mouvement des avions :
Il est facile de prévoir les positions futures des avions, ils se déplacent selon une direction
(qui varie globalement très peu), suivent un plan de vol… On peut donc connaître à l’avance les
cellules que les avions vont occuper.
Afin d’anticiper ces mouvement, il suffit de « réserver » les cellules dans lesquelles ils
vont se rendre. On ajoute donc une valeur possible aux cellules de la grille : libre, occupée ou
réservée. De plus, les cellules peuvent être réservées par plusieurs avions, on aura donc une
quantité de réservation pour une cellule.
L’idée est de ne pas ignorer les cellules, mais de les proposer comme solution s’il n’y a pas
mieux. Le facteur δ apparaissant dans la dernière forme de F(P) va donc changer et devenir :
δ = 1 / (1 + δ’)
avec δ’
=
0 si la cellule est libre => δ=1
n si la cellule est réservée par n avions => δ=1/(1+n)
+∞ si la cellule est occupée => δ=0
Ainsi, plus la cellule est réservée, moins les positions la recouvrant auront de chance d’être
choisies.
Mouvement des labels :
Les labels étant soumis à une réorganisation constante, il ne vaut mieux pas utiliser la
réservation comme moyen d’anticiper leurs mouvements.
Néanmoins, en considérant que la position qu’il recherche est une position qu’il vont
garder un certain temps (en suivant le mouvement de l’avion), il doivent anticiper leur propre
mouvement et donc, lors de l’évaluation, considérer qu’il ont une forme composée de leur forme
actuelle plus cette même forme projeté dans la direction de leur déplacement.
Les cellules que la forme projetée recouvre seront, si elles sont occupées ou réservées,
considérées comme étant réservées. Ceci afin d’utiliser la même forme pour le δ décrit plus haut.
Les labels n’anticipent donc pas les mouvements des autres labels.
28
Fig. IV.2.d. 1Anticipation des mouvements
L’euristique, telle qu’elle est implémentée, peine à franchir les zones « atténués » par ce
nouveau facteur δ, c’est pourquoi la propriété « réservée » sera assimilée plus tard, dans
l’implémentation de la solution, à la propriété « occupée ».
Cette gestion de l’anticipation est assez simpliste et, ici encore, il s’agit d’une direction de
recherche pouvant être soumise à une étude plus poussée.
29
V. Implémentation de la solution
1. Structure
Ce module a été développé dans l’optique de pouvoir tester les différentes approches sans
avoir à remodeler un programme à chaque fois. De plus, seule la partie gestion des recouvrement
est vouée à être réutilisée est doit donc être détachée du reste.
Dans cette optique de généricité, il faut bien séparer les différents traitements à effectuer. Par
exemple, la gestion des déplacements des avions est totalement indépendante du tout le reste, cela
doit donc faire partie du noyau de la plate-forme. Par contre, le comportement des labels va
dépendre de la solution choisie, il doit donc se trouver dans une partie externe au noyau.
La solution a été développée intégralement en JAVA. L’intérêt de ce langage dans ce cas est le
fait qu’il est orienté objet et donc facilite un conception générique. De plus le développement en
Java est très simple et rapide.
a) Structure générale
La structure du module est la suivante :
Plane
Supervisable
associe
Supervisor
Element
contient
MiniWorld
associe
Renderer
Label
PlaneLabel
Fig. V.1.a. 1 Structure du programme
30
Le noyau correspond aux classes ‘Element’ et ‘MiniWorld’. Elles implémentent toute la partie
concernant les déplacements et les mises à jour des éléments. La plate-forme tente de simuler un
trafic aérien proche des conditions réelles. Pour cela, il suffit de créer des objets correspondant à
des avions en vol, c'est-à-dire des objets ayant une position dans l’espace (position géographique +
altitude) et une vitesse. Il a fallu aussi une modélisation qui permette de manipuler les labels au
même titre que les avions sur l’écran radar. Ainsi, les avions et les labels sont considérés comme
des objets dans un univers 3D.
b) Structure du module Supervisor
Les classes ‘Supervisable’ et ‘Supervisor’ correspondent à la partie traitement des conflits de
chevauchement. Les éléments ‘Supervisable’ sont supervisés par un ‘Supervisor’. Le
fonctionnement est simple : à chaque étape, avant d’effectuer son nouveau mouvement, un
élément ‘Supervisable’ demande la permission au ‘Supervisor’ d’effectuer ce mouvement. Ce
dernier teste la validité du mouvement et renvoie la nouvelle position à laquelle doit se rendre
l’élément ‘Supervisable’. Ce résultat renvoyé est soit le mouvement demandé par l’élément dans
le cas ou il est possible, soit un mouvement suggéré par le ‘Supervisor’ (déterminé selon la
méthode choisie).
Element
Superviseur
Demande de
deplacement au
superviseur
test de
validite
Element
Valide
x, y, z
x, y, z
non
valide
Deplacement
nouvelle position : x', y', z'
Cette technique permet de gérer une solution par « agents intelligents », la classe ‘Supervisor’
contient alors la méthode de comportement des éléments. Elle permet aussi d’appliquer une
technique « globale », la classe ‘Supervisor’ contient alors les renseignements relatifs à l’ensemble
des protagonistes. Pour la dernière approche, cette même classe contiendra les formules de
physique permettant d’obtenir les nouvelles positions.
31
Ce module comprend donc les traitements visant à résoudre les problèmes de chevauchement.
Il faudra tout de même y différencier la fonction d’évaluation de l’euristique de recherche de
maximum. D’où la structure :
Supervisor
Associe
Evaluation
Fonction d'evaluation :
- distance
- angle
- deplacement
positionEvaluation()
CriteriaEvaluation
- test d'occupation
Utilise
Euristique de recherche de maximum :
Algo2OptimisedEvaluation
getBestPosition()
Fig. V.1.b. 1 Construction de la solution
32
2. Dans le détail..
a) Fonction d’évaluation
Les différentes évaluations se font par interpolation linéaire des valeurs. Chaque fonction est
évaluée selon un minimum, un optimum et un maximum. Les interpolations se font
respectivement de 0 à 100 puis de 100 à 0 :
Si (val <= min ou val >= max ) Alors résultat = 0
Sinon
Si (val < opt) Alors résultat = (val - min)*100 / (opt - min)
Sinon résulat = (val - opt)*100 / ( opt – max )
Sauf pour les cas opt=min et opt=max.
b) Implémentation de l’euristique
L’implémentation se situe dans la classe ‘Algo2OptimisedEvaluation’.
Le squelette de l’algorithme est le suivant :
P = P’ = point de départ ;
Répéter
P = P’ ;
P’ = le point proche de P formant la plus grande pente avec P ;
// F(P’) – F(P) est maximale
Jusqu’à (la pente entre P’ et P est négative (F(P’) – F(P) < 0) ;
Pmax = P ;
33
Pour gérer les zones à valeurs nulles, l’algorithme doit s’arrêter et lancer une recherche dans la
direction précédente en partant de l‘intérieur de la zone, on choisi à la fin le maximum des
solutions trouvées par l’ensemble des recherches lancées :
P = P’ = point de départ ;
D = direction de départ ;
Répéter
// permet de traverser une zone à valeurs nulles :
Tant que (quelque soit P’ proche de P, F(P) = 0)
Faire P = P + D ; // addition vectorielle.
P’ = le point proche de P formant la plus grande pente avec P ;
// F(P’) – F(P) est maximale
// Cas où l’on est arrivé en bord de zone à valeurs nulles :
Si ( F(P’) = 0 ) Alors
{
D= P’ - P ;
P2 = P ;
// On s’enfonce totalement dans la zone
Tant que (il existe P’’ proche de P2 tel que F(P)>0)
Faire P2 = P2 + D ;
Lancer une recherche à partir de P2 avec la direction
de départ D ;
}
Jusqu’à (la pente entre P’ et P est négative (F(P’) – F(P) < 0) ;
Pmax = max(P, résultats des recherches lancées);
Cette algorithme peut être étendu, c’est le cas dans le programme fourni en annexe, en lançant
plusieurs recherches au lieu d’une (dans plusieurs directions différentes). Cela permet d’avoir plus
de chances de trouver le maximum. C’est pour cela que la recherche est effectuée par un objet à
part entière ‘SearchGrid’ et non une simple méthode, il suffit de créer un nouvelle objet
‘SearchGrid’ pour déclencher une nouvelle recherche. On peut d’ailleurs envisager d’utiliser
un thread par objet ‘SearchGrid’ pour accélérer la recherche sur une plate-forme
multiprocesseur.
34
VI. Conclusion
La recherche
La solution développée atteint les objectifs fixés au début. Néanmoins, on ne peut pas
considérer cette solution comme une solution parfaite. Elle souffre notamment de quelques
problèmes d’instabilité.
D’une part, la définition des objectifs et, notamment, la définition d’une solution optimale
sont des définitions simplifiées permettant d’avoir des objectifs clairs. En effet, de nombreuses
contraintes supplémentaires peuvent être prises en compte.
D’autre part, l’étude qui précède ouvre de nombreuses directions de recherche : fonction
d’évaluation, recherche du maximum, anticipation. Pour chacune d’entre elle une solution est
proposée qui n’est qu’une solution parmi de nombreuses possibles. Surtout en ce qui concerne la
recherche de maximum dans la fonction d’évaluation, il reste à chercher un algorithme beaucoup
plus efficace. En effet, le fait que l’euristique développée ne trouve pas toujours le maximum est à
l’origine des instabilités observées.
Les autres approches et, en particulier, l’approche globale, constituent aussi des directions
de recherche pouvant aboutir à de bon résultats.
Néanmoins, le principe de fonctionnement de la solution constitue un noyau efficace qui,
sous réserve de mieux étudier les directions de recherche évoquées ci-dessus, devrait aboutir à une
solution efficace et stable.
On peut tout de même considérer que la solution est suffisante au vu des tests effectués.
Elle a été présentée à un certain nombre de contrôleurs, va être bientôt évaluée sur une plate-forme
simulant un trafic aérien et d’ici quelques temps sur une plate-forme pre-opérationnelle placée
dans un centre de contrôle. On peut envisager que cette solution soit utilisée dans tous les centres
de contrôle européen !
Les apports du stage
Ce stage au Centre d’Expérimentation d’Eurocontrol m’a permis de découvrir le monde de
l’ATC (Air Trafic Control), mais aussi de connaître le métier des contrôleurs et leur importance
dans la navigation aérienne.
Il m’a aussi permis de travailler sur un sujet de recherche intéressant et ainsi d’utiliser des
méthodes de travail différentes. J’ai aussi pu renforcer mon expérience dans la programmation
Java et orientée objet.
Pour finir, le contact avec l’équipe du département TEC, m’a beaucoup instruit, tant au
niveau professionnel que relationnel.
35
VII. Remerciements
Le stage s’est déroulé au sein du département Telecom & Multimedia Technologies (TEC)
du Centre Expérimental d’Eurocontrol. L’intégration dans l’équipe s’est effectuée rapidement et
facilement. L’encadrement fut effectué par Horst Hering et Gilles Gawinowski qui ont suivi avec
intérêt mon travail et m’ont beaucoup aidé.
Je tiens à remercier toute l’équipe du département Telecom & Multimedia Technologies
avec laquelle j’ai eu plaisir à travailler :
Je remercie les stagiaires qui ont effectuer leur travail durant cette période, Laetitia
Thernier, Karim Halloumi, Yann Serieye, Francois Philippe, Denis Lalos et Frédéric Salvy qui ont
contribuer à l’ambiance chaleureuse durant ces six mois de stage.
De même, je remercie Laurent Crouzard, Christian Musson, Laurent Guichard, Patrick
Villany et Gilbert Coatleven.
Enfin, je voudrais en particulier remercier mon maître de stage, Horst Hering pour son aide
et son soutien, et surtout Gilles Gawinowski, chef du département, pour ces nombreux conseils.
36

Development of a Mathematical weighted Formula to

Transcription

Documents pareils

Mais que veulent bien dire tous ces sigles et logos ?

LIBYE, SYRIE, YEMEN L`HISTOIRE S`ACCELERE

guide tourisme durable (web1) - Parc Naturel Régional Périgord

Act sportives - air

Le Centre de Transmission, Bawdsey, Suffolk

Dossier de presse "Des artistes pour la vie" du 7 avril 2007

Le Centre de Transmission, Bawdsey, Suffolk

Radar III Leaflet

Organiser une manifestation ou un projet sportif avec le label

Le chant en entreprise L`art d`harmoniser les voix et les