Simulation d`un outil d`aide au contrôle aérien

Transcription

Système d’exploitation
Introduction aux systèmes distribués
Simulation d’un outil d’aide au contrôle aérien
Nicolas Belloir et Eric Cariou
Projet commun SD/SE
Ce document décrit le sujet du projet commun entre l’UE de système d’exploitation et l’UE
d’introduction aux systèmes distribués. Il est à faire en binôme. Il sera rendu un rapport par partie,
suivi d’une évaluation sur machine.
1
Description générale de l’application à développer
On désire simuler le fonctionnement d’un outil d’aide au contrôle aérien (appelé dans la suite
Système de Gestion du Contrôle Aérien SGCA). L’application devra permettre de prendre en charge
plusieurs avions, de présenter au contrôleur aérien la liste triée par priorité des avions dont il a la
charge. Le contrôleur pourra sélectionner un avion de cette liste et entrer au clavier une instruction.
Il n’est pas obligé de prendre le premier avion de la liste.
communication
via sockets TCP
SGCA
communication Console
via RPC
Console
Fig. 1 – Architecture générale de l’application
L’application est constituée d’un ensemble d’éléments étant distribués, comme représenté sur la
figure 1 :
( Des avions
( Un SGCA coordonnant les communications entre les avions et le(s) contrôleur(s)
( Une console pour chaque contrôleur lui permettant, via le SGCA de contrôler des avions
2
Description des éléments formant l’application
2.1
Un avion
Un avion est caractérisé par les informations suivantes : son numéro de vol, son altitude courante,
sa vitesse courante, son cap courant et ses coordonnées. L’état de l’avion doit être donné au contrôleur.
Il doit être d’un de ces types :
( normal : l’avion ne présente pas de problème ;
Université de Pau et des Pays de l’Adour
2006-2007
Licence Informatique 3ème année
( alarme intermédiaire : l’avion présente un problème ne nécessitant pas d’atterrissage ou de
déroutage ; il doit cependant avoir un couloir aérien plus large ;
( alarme critique : l’avion présente un problème nécessitant un atterrissage immédiat.
Un contrôleur, via le SGCA, peut modifier les caractéristiques de l’avion en lui demandant de
changer son altitude, son cap ou sa vitesse. A intervalle de temps régulier, un avion envoie toutes ses
caractéristiques au SGCA.
La communication entre le SGCA et un avion se fait via des sockets TCP.
Pour implémenter un avion, complétez le programme avion.c qui vous a été donné. Ce programme
gère le vol de l’avion en fonction de ses caractèristiques. Il reste à implémenter la partie communication
avec le SGCA.
2.2
Le SGCA
Le SGCA devra être multiprocessus. Il sera composé de quatre processus : un processus qui
calculera l’ordonnancement des avions, un autre qui se chargera de la communication avec les avions,
un troisième qui gérera la sécurité et l’intégrité du système, et enfin un dernier qui se chargera de la
communication avec le contrôleur. Les processus partageront un espace de mémoire partagée. Un cycle
de calcul dure 5 secondes (ce temps n’est pas réaliste mais doit permettre une meilleure observation
du fonctionnement de l’application. Ce temps doit être par ailleurs paramétrable au lancement de
l’application).
2.2.1
Le processus Ordonnanceur
Ce processus a pour rôle de proposer au contrôleur une liste triée des avions qu’il a en charge. Pour
cela, il gère une fille multi-niveaux à retour représentant les 3 niveaux de criticité. En plus de cela,
il doit gérer le temps d’attente des avions. Si un avions n’est pas traité depuis longtemps, sa priorité
augmente. Cette liste doit être établie à chaque cycle.
2.2.2
Le processus Communication
Ce processus reçoit les informations provenant des avions et les écrit en SHM. Il émet également
les ordres du contrôleur à l’intention de l’avion concerné. Chaque avion sera géré par un thread dédié.
2.2.3
Le processus Sécurité
Ce processus surveille le fonctionnement de l’application. Pour cela, il s’assure qu’à chaque cycle les
processus ont tous terminé ce qu’ils avaient à faire. Pour cela, il surveille chaque processus avec un chien
de garde (Un cycle type pour un processus correspond à une suite d’actions : chien de garde = 1 ;
fonctionnel du processus ; chien de garde = 2 ; armerTimer de t secondes ; endormissement).
Si le processus de sécurité détecte trois débordements consécutifs, il arrête l’application après en avoir
averti le contrôleur et avoir marqué le problème dans un fichier log.
2.3
Une console
Elle se décompose en 2 sous-consoles : une première console affiche les données des avions sous
une forme tabulaire triée par ordre de criticité. Il s’agit de la seule console de la partie IHM à être
synchronisée avec l’application.
Une seconde console permet la saisie d’un ordre donné à une avion. Le contrôleur sélectionne
d’abord le numéro de l’avion, puis tape les instructions pour l’avion sélectionné. Il peut y avoir plusieurs
2006-2007
consoles de ce type et bien évidemment il faudra s’assurer que deux contrôleurs ne peuvent traiter le
même avion en même temps.
Les 2 parties d’une console peuvent être découplées : il doit être possible de lancer par exemple
sur une machine une partie affichage sans une partie de saisie, et inversement.
La communication entre une console et le SGCA se fait en utilisant le middleware d’appels de
procédure à distance RPC.
3
Travail à réaliser
La plus grosse partie du projet est commune aux deux matières.
3.1
Partie SE
3.1.1
Spécificités
Développer le SGCA sans les parties SD. Un banc d’essai permettra de simuler les communications
avec les avions. Il pourra émettre les informations données par les avions et recevoir celles données
par le système de gestion de contrôle aérien.
Les avions seront simulés par un banc de test. Celui ci est composé d’une console avec menu
permettant d’envoyer des informations au processus de communication par des files de message. Une
des entrées du menu montrera également les messages émis par le SGCA reçus par le banc de test.
Les différentes consoles IHM seront sur un même poste de travail.
3.1.2
Date importante
Les projets seront évalués la semaine du 1er mai. Un rapport de 10 pages rédigé en LATEX devra
être remis le 27 avril.
3.2
Partie SD
Comme précisé dans le sujet, il y a deux types de communication à utiliser : les sockets TCP pour
la communication entre un avion et le SCGA et RPC pour la communication entre une console et le
SCGA.
Dans le cas où votre SCGA ne serait pas terminé, et afin de pouvoir tester la partie SD, développez
un SCGA basique mettant directement en communication les consoles et les avions sans passer par et
gérer les différents processus et listes de priorités dans le SCGA tels que définis plus haut.
3.2.1
Date importante
Un rapport (format PDF si possible) devra être remis par mail le 27 avril avec les sources de votre
programme. Les projets seront évalués la semaine du 1er mai.
4
Remarques
On devra pouvoir suivre via les IHM le déroulement de la simulation. Essayer de travailler de
manière modulaire afin de toujours fournir un programme exécutable. Si une partie de votre
programme ne marche pas, assurez vous de pouvoir tester le reste.
Toute tricherie impliquera un 0. Les correcteurs se réservent le droit de donner une note différenciée
à chaque membre d’un binôme.
2006-2007

Simulation d`un outil d`aide au contrôle aérien

Transcription

Documents pareils

Simulation d`un outil d`aide au contrôle aérien

La plus grande illusion

Centen`air

L`AKOYA, une véritable révolution dans le monde

CONCOURS DE REALISATION ET LANCER D`AVIONS EN PAPIER

C` est le plus gros avion du monde. Avant le plus grand

lisez ce document relatif a la sécurité et aux informations des vols

Formulaire d´inscription - Luftsportgruppe Kempten

Les objets et personnages volants... Voici le résultat d`une séance

symbolique et tutoriel avion - mus

Solving the Aircraft Landing Problem with time

Préface et table des matières