2.2.2 Gestion « tactique »
Il s'agit ici de définir les actions de gestion
à mener à court terme et en temps réel. Cela revient
à attribuer un poste de stationnement aux aéronefs à
l'arrivée et à faire en sorte qu'il n'y ait pas de
collision/abordage entre les aéronefs qui entrent ou sortent des postes
de stationnement ou ceux qui sont stationnés dans les différents
postes. Pour parvenir au but visé, il faut donc une gestion rationnelle
et méthodique de l'aire de trafic. Les tâches cidessous
énumérées permettent d'atteindre ce but :
1. quand un aéronef se présente sur la
plate-forme, le gestionnaire lui attribue le poste jadis réservé
ou à défaut un poste compatible et disponible ;
2. quand un aéronef effectue une demande de mise en
route, le gestionnaire répond en fonction de la configuration du trafic
(la piste, l'itinéraire pour y accéder, la tranche d'espace qui
sera utilisée pour l'envol) ;
3. le gestionnaire doit également indiquer à
l'aéronef, l'itinéraire du poste de stationnement à la
piste et vice versa ;
4. le gestionnaire doit pouvoir communiquer l'heure de roulage
à l'aéronef ;
2.3 Méthodologie de résolution
2.3.1 Présentation des outils supports de
développement :
Pour automatiser les tâches ci-dessus décrites dans
le cahier de charge, nous allons
proposer une application qui peut être consultée
par des machines distantes ou locales (application client/serveur). Notre
application sera le serveur, les clients seront soit, les systèmes
embarqués (datalink), soit un système sol destiné à
la planification des vols (divers usagers).
L'application sera développée dans
l'environnement Windows à l'aide du RAD1 visual basic comme
support de programmation. La communication avec les machines clientes sera
établie par l'intermédiaire de la bibliothèque de liaison
dynamique DLL2 Winsock. Cette bibliothèque utilise le
protocole IP3 de la couche réseau.
1 Rapid Application development
2 Dynamic Link Library
3 Internet Protocol
La solution proposée s'articule autour des deux classes de
gestion définies précédemment.
2.3.2 Automatisation «prétactique»
L'application proposée, dans son fonctionnement
prétactique, sera consultée par d'autres applications distantes
ou locales en mode connecté ; le protocole TCP1 de la couche
transport sera utilisé.
Pour la résolution de cette classe, une fenêtre
temporelle d'une semaine à un mois sera considérée. La
solution retenue consiste à créer un fichier dans lequel les
réservations des postes de stationnement seront enregistrées.
Chaque réservation sera représentée par une chaîne
de caractères. Celle-ci contiendra : l'identification du poste,
l'indicatif de l'aéronef et l'intervalle de temps réservé
ou créneau. Ainsi, on notera Crij le
créneau correspondant à un poste numéro i
réservé à un aéronef numéro j.
La demande de la réservation d'un créneau
comprendra l'indicatif de l'aéronef, sa masse maximale de structure au
décollage, l'heure estimée d'arrivée et la durée
estimée d'escale. Ceux-ci constituent une demande de créneau
Cr (Cr est un intervalle de temps) dont les bornes sont
ETA-å1 et
ETA+Rotation+å2. ETA est l'heure
prévue d'arrivée à
l'IAF, Rotation la durée prévue de l'escale (en
minutes) et les åi sont, quant à eux, des durées
additionnelles pour tenir compte de l'imprécision de l'ETA. Nous fixons
å1=5 minutes et å2=10 minutes.
Lorsqu'une requête de réservation est
reçue par l'application, celle-ci cherche le poste le plus proche de la
voie de sortie, compatible avec l'avion. Ensuite, dans le fichier de
réservation, les créneaux associés au poste sont lus. S'il
n'y a aucune interférence entre ces créneaux et le créneau
demandé, le poste est alloué à l'aéronef et la
réservation concernée est enregistrée dans le fichier.
Dans le cas où la réservation demandée interfère
avec un des créneaux, un autre poste est cherché selon le
même procédé. Lorsqu'il n y a aucun poste libre et
compatible, l 'ETA est incrémentée de 10 minutes et une nouvelle
recherche de
1 Transmission Control Protocol
créneau est engagée. A la fin de ces recherches le
poste octroyé et l'ETA acceptée sont retournés et
envoyés à l'application cliente.
L'algorithme décrit ci-dessus attribue dans tous les
cas un poste. Dans certains cas, l'ETA acceptée peut être
très différente de l'ETA demandée ; il revient alors au
demandeur de créneau de l'accepter ou non. Lorsque le demandeur accepte
la proposition, le contrat de réservation est conclu.
L'algorithme de la gestion prétactique est
résumé par le logigramme ci-dessous.
Figure 41: Logigramme de la gestion prétactique
:
| 
