CVAR : projet C est l train fou!!! Rapport de fin de projet

Transcription

1 CVAR : projet C est l train fou!!! Rapport de fin de projet Benoît MERLET Matthieu MUFFATO Résumé Dans le cadre de l option Conception et Validation d Applications Réactives, ce projet consiste à piloter un circuit féroviaire électrique constitué de 16 tronçons, de 2 voies de garage, de 7 aiguillages indépendants et d un ensemble de signalisations bicolores. Sur ce circuit peuvent évoluer entre 3 et 5 trains, voire plus pour les plus courageux. Le circuit est contrôlé via un ordinateur sur lequel tourne un mininoyau temps réel, le noyau Yacoubat. Il s agit de produire un logiciel permettant de récupérer des informations via l interface COM du PC, de les analyser et d envoyer les informations de contrôle au dispositif, principalement pour commander les locomotives et les feux de signalisation. Cependant, il existe une alternative aux tests rééls effectués sur la maquette présente au foyer : Le simulateur du réseau développé pas un ancien élève sous le système d exploitation temps réél QNX. 1

2 1 Structures utilisées Au début de la réalisation de notre logiciel, nous exploitions grandement le code donné en exemple : train5. Cependant nous nous sommes vite rendu compte des limites de sa conception. Il fallait en effet donner en dur le circuit d un train tronçon après tronçon. Cette approche ne nous a pas paru des plus généralisable, notamment dans le cas de changements matériels sur le réseau. Nous avons alors essayé de réfléchir à un autre moyen de modéliser le réseau. Au lieu de nous focaliser sur l élément tronçon qui n est rien d autre qu un bout de piste entre deux réceptivités, nous avons pris l option de raisonner plus spécifiquement sur l élément connexion, mot barbare pour désigner un lien fictif entre deux tronçons. Grâce à cette astuce, nous pouvons faire en sorte que les trains que l on rajoute sur le réseau soient autonomes en ce sens qu ils choisissent eux-même leurs trajets en tenant compte des contraintes physiques du circuit (ne pas pouvoir tourner si les angles sont trop aigus) et des tronçons occupés (pour ne pas provoquer la plus grande catastrophe féroviaire du siècle). Voici un descriptif des différentes structures utilisées tout au long du code. Ces structures sont définies dans le fichier reseau.h et initialisées dans le fichier reseau.c. Structure Champs Description troncon num troncon numéro du tronçon pour y accéder dans le tableau global des tronçons connexion1 connexion2 liste des connexions que l on peut prendre à l extrémité 1 du tronçon liste des connexions que l on peut prendre à l extrémité 2 du tronçon 2

3 Structure Champs Description connexion tronc1 le troncon à l extrémité 1 de la connection recept1 tronc2 recept2 feu12 feu21 aiguill la réceptivité à l extrémité 1 de la connection le troncon à l extrémité 2 de la connection la réceptivité à l extrémité 2 de la connection le feu à allumer quand on va de tronc1 à tronc2 le feu à allumer quand on va de tronc2 à tronc1 la liste des aiguillages à positionner pour que le train puisse passer d un tronçon à l autre de la connexion pos aiguill Structure Champs Description la liste des positions des aiguillages précédents train id le numéro du train pour son pilotage sur le réseau troncon tronçon sur lequel se trouve le train sens sens de parcours du tronçon : 1 si on va de 1 vers 2 dans le troncon et 2 sinon Nous maintenons grace à ces structures un tableau (indexé par num troncon) de tous les tronçons libres et occupés du réseau. Ce tableau constitue une ressource partagée par tous les trains sur le réseau et son accès, en lecture ou écriture, est donc sujet à une exclusion mutuelle. 3

4 2 Fonctionnement Comme nous l avons dit au début, nous avons tout conceptualiser pour faire en sorte que les trains puissent choisir leurs chemins comme des grands (éventuellement aléatoirement dans le cas où ils ont plusieurs alternatives). La solution a donc été de créer un processus par train ainsi qu un processus de lecture de la ligne série. Comme on peut le voir dans le pseudo-code qui va suivre, nous avons donné plus d importance aux processus pilotant les trains. Le processus pilotant un train sur le réseau : TANT QUE vrai FAIRE récupérer la réceptivité r de fin du tronçon courant récupérer l évènement Er associé à r faire avancer le train attendre l évènement Er stopper le train P(MUTEX) choisir aléatoirement une connection c donnant sur un tronçon libre SI c existe ALORS reserver le tronçon à l autre bout de la connection c V(MUTEX) SI c n existe pas ALORS inverser le sens de marche du train SINON positionner les aiguillages pour pouvoir passer la connection c allumer le feu permettant de passer la connection c récupérer la réceptivité r de début du tronçon suivant récupérer l évènement Er associé à r faire avancer le train attendre l évènement Er stopper le train éteindre le feu permettant de passer la connection c P(MUTEX) libérer le tronçon que l on vient de quitter V(MUTEX) FAIT 4

5 Le processus pilotant la ligne série : TANT QUE vrai FAIRE purger la ligne série lire les réceptivités du réseau sur la ligne série SI des receptivités ont été activées ALORS envoyer les évènements correspondant aux réceptivités s endormir pour un temps fixé au départ FAIT Nous disposons également d un master process qui se charge d utiliser le noyau Yacoubat de façon à créer les évènements associés aux réceptivités, à initialiser la ligne série, à créer le processus censé la gérer, à créer le sémaphore permettant d implémenter l exclusion mutuelle, à initialiser le réseau, à y placer les trains et enfin à créer les processus pilotant les trains. Il se charge également de quitter le programme proprement en détruisant les processus et en fermant la ligne série 5