Devoir Système - 1998-1999
Simulation d'une installation d'ascenseur(s)

© M. Laporte - D. Mathieu mathieu@romarin.univ-aix.fr
I.U.T.d'Aix en Provence - Département Informatique

Sommaire

Sujet
Quelques pistes
Organisation
Outils
Travail à rendre
Le texte
Les listings
Annexe

Sujet : simulation d'une installation d'ascenseur(s) dans un immeuble

    Il s'agit de concevoir et, si possible, de développer un système informatique permettant de simuler le comportement d'un ensemble d'ascenseurs dans un immeuble de plusieurs étages, en fonction de la demande d'individus que nous appellerons "clients". On considérera qu'un ensemble est constitué d'au moins un ascenseur, et, s'il y en a plusieurs, ils sont regroupés géographiquement afin de desservir chacun l'ensemble des paliers. Cela exclut les cas d'ascenseurs aux deux extrémités d'un même bâtiment (il s'agirait alors de deux systèmes indépendants), de plusieurs ascenseurs desservant chacun une partie des étages (par exemple un pour les pairs et un pour les impairs).

    Les objectifs de ce devoir sont multiples : tester votre capacité à

    Compte tenu de la généralité du sujet, chaque devoir ne peut être qu'unique ... Cependant, les indications ci-dessous peuvent vous aider à limiter votre imagination débordante !

Sommaire

Quelques pistes

    Le système simulé doit se rapprocher le plus possible d'un système réel, mais il existe toute une variété de systèmes réels ou réalisables. Il existe des ascenseurs sans mémoire, les plus simples à gérer, mais un peu primitifs. Il existe ou peut exister des ascenseurs optimisés individuellement - un ascenseur ne dessert pas les étages selon l'ordre chronologique des appels, mais selon l'ordre dans lequel il rencontre les étages - ou collectivement – les ascenseurs négocient entre eux pour décider dans quel sens ils vont. De même, certains ascenseurs ne mémorisent que certains appels : vous montez au premier étage dans un ascenseur qui descend, vous appuyez sur l'étage 4. L'ascenseur purge tous les appels lorsqu'il arrive en bas. Votre appel est perdu et vous devez appuyer de nouveau sur l'étage 4.

    En principe, chaque étage devrait être muni de deux boutons, l'un enregistrant les demandes de descente, l'autre les demandes de montée (attention au rez-de-chaussée et au dernier étage !).

    A chaque ascenseur et à chaque client doit correspondre un processus unique. Si besoin est, vous pouvez cependant utiliser des processus supplémentaires (peu conseillé, si possible, sauf solide justification !).

    Pendant la phase de mise au point, vous pouvez lancer "à la main" chacun des processus nécessaires à partir du clavier. Cependant, afin de tester sérieusement votre système, vous devrez concevoir des jeux d'essais correspondant à des cas spécifiques que vous bâtirez sous forme de scripts, soigneusement commentés. Cela vous permettra de "rejouer" autant de fois les mêmes scénarios. Ainsi, on peut imaginer un script lançant successivement :

    Dans un premier temps, vous pouvez ne traiter que des comportements "normaux", mais vous pouvez aussi prendre en compte des clients fous ou bizarres : client qui appelle pour descendre et qui, dans l'ascenseur, demande à monter, client qui monte dans l'ascenseur et qui en descend immédiatement avant la fermeture des portes, client qui reste indéfiniment dans l'ascenseur, etc. Ces comportement pourraient être simulés soit en paramétrant différemment les processus clients, soit en créant des processus clients différents.

    Vous devez gérer la capacité limitée des cabines, par exemple en ne laissant entrer les clients que l'un après l'autre, au moyen d'une simulation de tourniquet, et en bloquant les clients lorsque la cabine est pleine (pas très réaliste), ou bien en laissant entrer autant de client qu'ils le veulent, mais en bloquant la cabine jusqu'à ce que certains clients, excédés ou intelligents, décident eux-mêmes de descendre de l'ascenseur. Imaginez la scène. Au fait, seraient-ils obligés d'appuyer de nouveau sur le bouton pour rappeler une cabine ? On peut aussi imaginer que la cabine a une capacité maximale en nombre de personnes, mais aussi en charge. L'ascenseur pourrait donc laisser rentrer n'importe qui dans la limite des places, puis calculer la charge totale. Cela supposerait que les clients auraient un paramètre supplémentaire qui serait le poids.

    Dès que l'application est un peu complexe, le déroulement de plusieurs processus parallèles ne peut être contrôlé directement par affichage de messages sur un écran. Deux solutions s'offrent à vous :

Sommaire

Organisation :

    Après quelques jours de réflexion, vous devez commencer à imaginer la structure de votre devoir, les outils que vous utiliserez, ce que vous vous sentez capables de faire, etc. Vous devez ensuite vous répartir rapidement le travail de façon équitable, spécifier au mieux les fonctions de chacun, quitte à faire évoluer ces spécifications au fur et à mesure des besoins. Fixez-vous un calendrier prévisionnel de réalisation. Si vous devez utiliser des outils de système non maîtrisés par exemple, essayez de ne pas être tous bloqués et de mener plusieurs activités en parallèle, quitte à court-circuiter provisoirement certaines parties (un sleep() remplaçant une action, une lecture au clavier remplaçant l'attente d'un événement quelconque, etc.)

Outils :

    Pour nous, la partie la plus intéressante du devoir est la synchronisation et la communication des différents processus. Vous pouvez utiliser tous les outils système que vous connaissez, et même ceux que vous ne connaissez pas encore, comme les pipes nommés - dont le comportement se rapproche beaucoup des pipes, mais qui permettent à des processus non parents de communiquer (un exemple suit en annexe) - ou les files de messages, qui ne seront pas étudiés en TP mais dont vous pouvez trouver le principe dans le polycopié des IPCs.

    N'hésitez pas à créer des classes si elles vous paraissent nécessaires, mais ne vous forcez pas à en faire si cela ne vous paraît pas naturel. C'est avant tout un devoir de Système !!!

Sommaire

Travail à rendre

Votre travail donnera lieu a la rédaction d'un rapport en deux parties :

Le texte

    Le texte a différents objectifs. Il doit vous permettre de présenter globalement votre travail, afin de nous permettre de nous y retrouver plus facilement dans les listings. Pour cela, vous devez expliquer le plus clairement comment vous avez compris le sujet, ce que vous avez traité. Vous devez faire une présentation rapide de votre travail, comment il est structuré, comment l'ensemble fonctionne. Quand vous estimez avoir donné suffisamment d'informations pour nous permettre d'entrer dans votre réalisation, vous devez développer plus précisément les points qui vous paraissent importants, difficiles, ou que vous jugez intéressants à mettre en valeur. Nous sommes aussi intéressés par la façon dont vous vous êtes organisés, par les difficultés que vous avez rencontrées et la façon dont vous les avez surmontées.

    Le sujet est très ouvert, vous pouvez donc imaginer de nombreux perfectionnements à votre travail, des généralisations, d'autres façons de résoudre le problème. Cela nous intéresse, même si vous n'avez pas mené la réflexion jusqu'à la réalisation, à condition que vous ayez un peu pensé à la mise en oeuvre !

    Enfin, nous aimerions un bilan de ce travail.

    Pour résumer, le texte doit contenir les informations suivantes :

    Les pages doivent être numérotées.

    Attention : n’utilisez pas des polices de caractères trop grandes, des interlignes immenses, des changements de page abusifs pour que le rapport soit gros, donc pour essayer de nous faire croire que le travail est important ! ...

Sommaire

Les listings

    Les listigns :

    En résumé, tout ce qui peut mettre en valeur votre travail PERSONNEL... et rendre la correction la plus agréable et la plus facile. Merci pour nous!

    Commencez le plus vite possible, afin de voir venir les problèmes, rédigez en parallèle, au moins en prenant quelques notes. N'hésitez pas à nous soumettre vos difficultés avant d'avoir perdu trop de temps. Nous essaierons de vous aider à condition que vous fassiez l'effort de respecter la présentation.

Sommaire

ANNEXE


    Vous pouvez créer un pipe nommé "fifo" par la commande Unix :
 

mkfifo -m 0700 fifo

ou, par programme, comme dans l'exemple ci-dessous :
 

int ppal (int argc, char * argv [])
{
    if (nsSysteme::mkfifo ("fifo", S_IFIFO | 0700)) 
    throw CExcFctSyst ("mkfifo");
 
    if (CSysteme::fork ())
    {
        char Chaine [] = "12345678911234567892123456789312";
        int pfd = CSysteme::open ("fifo", O_WRONLY);
        nsSysteme::write (pfd, Chaine, strlen (Chaine) + 1);
        nsSysteme::close (pfd);
        nsSysteme::wait (); 
        nsSysteme::unlink ("fifo");
    }
    else
    {
        char Chaine [MAX_INPUT];
        int pfd = nsSysteme::open ("fifo", O_RDONLY);
        sleep (2);
        struct stat Stat;
        nsSysteme::fstat (pfd, & Stat);
        cout << "Taille = " << Stat.st_size << endl;
        nsSysteme::read (pfd, Chaine, MAX_INPUT);
        cout << Chaine << endl;
        nsSysteme::close (pfd);
    }
    return 0;
 
} // ppal()

Sommaire

© D. Mathieu     mathieu@romarin.univ-aix.fr
I.U.T.d'Aix en Provence - Département Informatique