FR 2875923 A1 20060331 FR 0410267 A 20040928 DISPOSITIF D'OPTIMISATION ET DE MISE EN ROUTE D'UNE APPLICATION COMMANDEE PAR UN CALCULATEUR A SYSTEME D'EXPLOITATION MULTITACHE La présente invention se rapporte à un dispositif d'optimisation et de mise en route d'une application commandée par un calculateur à système d'exploitation (SE) multitâche. Dans le domaine des matériels embarqués commandés par des applications logicielles embarquées ( embedded en anglais) comportant au moins un calculateur, lorsque l'on modifie le SE de ce calculateur, par exemple lors de mises à jour, il faut souvent procéder à des modifications importantes des matériels enfouis qu'il gère. D'autre part, ces SE (même lorsqu'ils sont très allégés , tels que des systèmes Linux), mettent un temps non négligeable (plusieurs minutes) à se charger, ce qui peut constituer un obstacle très gênant à l'utilisation immédiate des matériels gérés, car certains doivent être opérationnels dans un très court laps de temps (moins d'une minute ou même moins d'une demi-minute pour certains) après leur mise sous tension. La présente invention a pour objet un dispositif d'optimisation et de mise en route (dispositif A) d'une application commandée par un calculateur à système d'exploitation multitâche, dispositif qui permette d'apporter des modifications au SE avec un impact minime sur les applications qu'il gère, ce dispositif étant opérationnel dans un temps le plus court possible après la mise en route des matériels qu'il gère. La présente invention comporte en outre un outil (prévu pour générer ce dispositif A), aussi automatique et intuitif que possible, destiné à obtenir un support amovible auto-démarrable ( auto-bootable en anglais) , tel qu'un CD-ROM, permettant l'installation automatique du système d'exploitation et des applications à gérer sur le calculateur cible gérant ces applications. Le dispositif conforme à l'invention est caractérisé en ce qu'il comporte une couche logicielle entre le système d'exploitation et l'application, cette couche 30 logicielle comprenant: 1. des fonctions d'optimisation du démarrage de l'application, 2. des fonctions de test du matériel géré par le système d'exploitation et 3. des fonctions d'ordonnancement des tâches gérées par le SE. Un des avantages de l'invention, est que la couche logicielle est chargée automatiquement dans le calculateur de gestion des applications à partir d'informations délivrées par l'application considérée et sélectionnant sur un support 5 amovible les fonctions à installer parmi un ensemble de fonctions prévues pour plusieurs applications différentes. La présente invention sera mieux comprise à la lecture de la description détaillée d'un mode de réalisation, pris à titre d'exemple non limitatif et illustré par le dessin annexé, sur lequel: la figure 1 est un blocdiagramme simplifié d'un système applicatif incorporant le dispositif conforme à l'invention, et la figure 2 est un chronogramme des principales étapes du processus de mise en route du système applicatif de la figure 1. La présente invention est décrite ci-dessous en référence à la gestion d'un appareillage embarqué par un système d'exploitation de type Linux , mais il est bien entendu qu'elle n'est pas limitée à cette seule application, et qu'elle peut être mise en oeuvre dans d'autres types d'applications et avec d'autres systèmes d'exploitation multitâches, qu'ils soient préemptifs ou non. Sur la figure 1, on a représenté les éléments essentiels d'un système applicatif mettant en oeuvre l'invention. Ce système applicatif 1 comporte une application logicielle 2 existante, associée à un matériel quelconque (appareil de mesure, de télécommunication, matériel électromécanique,....) non représenté et dénommé ici matériel applicatif . L'application 2 est gérée par au moins un calculateur ayant son propre système d'exploitation. Cette application logicielle est supportée par un langage quelconque (ADA, JAVA, CORBA, C, C++ , ). L'application 2 communique avec une couche logicielle 3 qui a trois fonctions principales: la gestion des services GNU/Linux (tels que des daemons , c'est- à-dire des programmes tournant en arrière-plan, des pilotes de gestion de matériels,...), l'optimisation des étapes de démarrage ( boot en anglais), afin de réduire leur durée, les tests intégrés des périphériques et de la partie matérielle gérée par l'application, qui peuvent être réalisés avant (off-line) et après (on-line) le lancement de l'applicatif 2. Les fonctions assurant ces tests sont dénommées ici BITEs , soit: Built In Test Equipments ). Les deux premières fonctions et la gestion des BITEs sont réalisées par la couche dénommée ici Slushware , L'application 2 et la couche 3 communiquent entre elles directement, et éventuellement par l'intermédiaire d'un composant logiciel optionnel 4 assurant exactement le même rôle que le composant Unix X11, mais avec des processeurs de type Intel X 86). Le système applicatif 1 comporte en outre un ensemble de composants matériels (5), comme par exemple une carte graphique (6), des périphériques classiques (7) (tels que des lecteurs de disques et/ou disquettes, des lecteurs de CD- ROM, des disques optiques,....), et des périphériques spécifiques (tels que des cartes d'entrés/sorties, des afficheurs spéciaux, ...). Ces composants matériels sont gérés par des pilotes ( drivers en anglais) appropriés, respectivement référencés dans leur ensemble 6A à 8A. Ces pilotes communiquent de façon bi-directionnelle avec la couche logicielle 3. En outre, le système applicatif 1 utilise un noyau ( kernel en anglais) Linux qui communique avec la couche 3 et l'ensemble des matériels 5, ainsi que l'ensemble 9A de fonctions Unix ou Linux (commandes de base Unix permettant d'inter-agir avec le matériel). Le système applicatif 1 est donc constitué d'une couche logicielle intermédiaire , le Slushware qui gère le matériel et tous les composants logiciels (daemons) GNU/Linux personnalisés, ce qui permet de minimiser l'impact des modifications ultérieures (évolutions du système d'exploitation ou du matériel) sur cette application 2. Sur le chronogramme de la figure 2, on a représenté les principales étapes de la mise en route du système applicatif 1. Cette mise en route commence après la mise sous tension du matériel géré par l'application. Dès que le processeur supportant le système applicatif décrit en référence à la figure 1 est mis sous tension, et comme c'est le cas pour un micro-ordinateur classique, le premier élément logiciel activé est le BIOS du calculateur. Ce BIOS vérifie (11) tous les éléments qu'il gère: 1. la mémoire RAM, 2. les contrôleurs de mémoires de masse, 3. les ports d'entrée/sortie, 4. les cartes additionnelles,... Ensuite se fait le chargement du noyau du système d'exploitation Linux (Procédure LILO- étape 12). Puis, le système d'exploitation Linux démarre (13) pour assurer la supervision du système applicatif. Après le démarrage du système d'exploitation, le Slushware active (14) 1. les tests de bas niveau du matériel (tests off-line), 2. les initialisations des entrées/sorties du système d'exploitation 3. (Ethernet, transmission série,....), le lancement des applications et 4. la gestion de ces applications. D'autre part, à l'étape 15 (l'étape 14 est un complément à l'étape 15), le Slushware gère les fonctions BITE qui procèdent aux tests en ligne (on-line). Ainsi, la couche Slushware assure les fonctions suivantes: elle gère les pilotes des différents périphériques (utilisés par le système applicatif ou le système d'exploitation), elle gère l'utilisation des services du système d'exploitation (c'est-à-dire les daemons Linux), elle gère l'initialisation des matériels périphériques et les tests de ces matériels, elle lance et gère les applications. Selon un mode de réalisation avantageux de l'invention, le système d'exploitation embarqué (Linux dans le cas présent) et les différents composants logiciels du système applicatif sont chargés à partir d'un support amovible (un CD-ROM ou un type équivalent, dans le cas présent) dans le calculateur gérant le système applicatif de la figure 1 le choix du système applicatif est fait via un dialogue entre le calculateur et le programme d'installation. Ce mode d'installation 25 est particulièrement avantageux lorsque l'on doit installer plusieurs systèmes applicatifs sur divers matériels différents. Selon l'invention, le CD-ROM d'installation comporte toutes les options du système applicatif nécessaires à l'installation de ce système sur les différents matériels et/ou calculateurs à équiper. Ce CD-ROM est réalisé à l'aide d'un outil spécifique fonctionnant sur une station de travail à partir d'une version maître du système d'exploitation, dite master distribution . Ce CD-ROM comporte, pour l'installation de chaque système applicatif, les composants suivants: / le système d'exploitation prévu pour tolérer des arrêts électriques 10 inopinés, / la couche Slushware , / les applications embarquées et É un programme d'installation de tous ces composants sur le calculateur correspondant. L'outil de réalisation du CD-ROM en question tire profit des possibilités offertes par le format El Torito définissant les caractéristiques de CD-ROM autodémarrables pour fabriquer un tel CD-ROM. Ce CD-ROM réalise les opérations d'installation appropriées grâce à une version réduite du système d'exploitation GNU/Linux (par exemple d'environ 2,88 Mo) qui est exécutée à partir de ce CD- ROM. Dans ce cas de chargement du système applicatif, à partir d'un CD-ROM, le Slushware a également pour rôle de personnaliser et d'optimiser automatiquement les fonctions standard relatives au démarrage du système d'exploitation GNU/Linux, et en particulier, il écrase , lors de l'installation du système applicatif, les scripts standard pour les remplacer par des scripts optimisés de démarrage du système applicatif, d'ordonnancement des tâches et de lancement des applications (voir l'annexe ci-dessous). ANNEXE: exemple simplifié d'un script optimisé. Le système d'exploitation allégé s'appuie sur une architecture System V . Cette architecture est basée sur un script /etc/inittab qui contient la configuration du programme /sbinlinit et un ou plusieurs scripts permettant de démarrer les services adéquats: /etc/rc.d/rc.S /etc/inittab # # inittab This file describes how the INIT process should set up the system # # Default runlevel id:S:initdefault: # System initialisation (runs when system boots). si: S:sysinit:/etc/rc.d/rc. S # End of /etc/inittab /etc/rc.d/rc.S #!/bin/bash # # rc.S System initialisation script # PATH=/sbin:/bin #/Start update /sbin/update & # Remount the root filesystem in read-only mode echo "Remounting root device with read-only enabled" /bin/mount -o -n -o remount / if [ $? -gt 0]; then echo echo "Attempt to remount root device as read-only failed!" echo "This is going to cause serious problems..." fi echo "Cleaning mtab" /bin/rm -f /etc/mtab # Mounting local fs from /etc/fstab echo "Mounting local filesystems" /binJmount -at noies # Launching network services /etc/rc.d/rc.inetl start /etc/rc.d/rc.inet2 start # Starting a bash shell 10 HOME /root USER=root export HOME USER cd $HOME /bin/sh # End of /etc/rc.d/rc.S REVENDICATIONS 1. Dispositif d'optimisation et de mise en route d'une application commandée par un calculateur à système d'exploitation multitâche, caractérisé en ce qu'il comporte une couche logicielle (3) entre le système d'exploitation (9) et l'application (2), cette couche logicielle comprenant des fonctions d'optimisation du démarrage de l'application, des fonctions de test (BITE) du matériel géré par le système d'exploitation et des fonctions d'ordonnancement des tâches gérées par le système d'exploitation. 2. Système selon la revendication 1, caractérisé en ce que la couche logicielle est chargée automatiquement dans le calculateur de gestion des applications à partir d'informations délivrées par l'application considérée et sélectionnant sur un support amovible les fonctions à installer parmi un ensemble de fonctions prévues pour plusieurs matériels et/ou applications différent(e)s. 3. Système selon la revendication 2, caractérisé en ce que le support amovible est de type CD-ROM.