FR2960668A1

FR2960668A1 - Procede et dispositif de configuration incrementale de modules de type ima

Info

Publication number: FR2960668A1
Application number: FR1054092A
Authority: FR
Inventors: Philippe Martinez
Original assignee: Airbus Operations SAS
Current assignee: Airbus Operations SAS
Priority date: 2010-05-27
Filing date: 2010-05-27
Publication date: 2011-12-02
Also published as: CN102262551A; CN102262551B; US8782296B2; US20110296151A1; CA2740073A1

Abstract

L'invention a notamment pour objet la configuration incrémentale d'un module de type IMA, le module comprenant des ressources temporelles et matérielles ainsi qu'un système d'exploitation permettant une exécution ségréguée d'au moins deux applications à l'aide d'au moins une partie des ressources. Après avoir obtenu (305) au moins un premier paramètre de configuration d'au moins une partie des ressources, ce paramètre visant une ressource propre au système d'exploitation ou une ressource commune au système d'exploitation et à au moins une des applications ou aux applications, le module est configuré (310) selon ce paramètre. Un second paramètre de configuration d'au moins une partie des ressources est ensuite obtenu (320), ce second paramètre visant une ressource propre à l'une des applications. Le module est alors configuré (330) selon ledit au moins un second paramètres.

Description

La présente invention concerne la configuration de systèmes informatiques dans des structures telles que des aéronefs et plus particulièrement un procédé et un dispositif de configuration incrémentale de modules de calcul et d'entrée/sortie constituant une plateforme avionique modulaire intégrée (IMA), préservant la ségrégation des performances individuelles des applications mises en oeuvre, notamment des applications temps réels. Ce procédé et ce dispositif permettent en particulier une configuration incrémentale d'un module pour chaque application chargée. Le module comprend ici un système d'exploitation partitionné. Les pilotes d'entrée/sortie (appelés drivers en terminologie anglo-saxonne) ont, de préférence, une interface de programmation basée sur la norme ARINC 653. Les aéronefs modernes comprennent de plus en plus de systèmes électroniques et informatiques pour améliorer leurs performances et assister le pilote ainsi que les membres d'équipage lors de leurs missions. Ainsi, par exemple, les commandes de vol électriques permettent de réduire la complexité mécanique de la transmission des commandes aux actuateurs et donc la masse associée à ces commandes. De même, la présentation d'informations pertinentes permet au pilote d'optimiser les trajectoires de vol et de répondre rapidement à tout incident détecté. De telles informations sont notamment la vitesse, la position, le cap, des données de météorologie et de navigation.

L'ensemble de ces systèmes électroniques et informatiques est généralement appelé l'avionique. Pour des raisons de fiabilité, l'avionique a souvent été répartie de façon fonctionnelle par modules spécifiques, aussi appelé LRU (sigle de Line Replaceable Unit en terminologie anglo-saxonne). Selon cette architecture, un mode de transmission point à point est utilisé entre chaque module. Ainsi, par exemple, les commandes de vol sont gérées dans un dispositif particulier tandis que l'alimentation électrique est gérée dans un autre. Une fonction spécifique est ainsi associée à chaque module. Par ailleurs, chaque module supportant une fonction critique est, de préférence, redondant de telle sorte que la défaillance d'un module n'entraîne pas la perte de la fonction associée. L'exploitation d'un aéronef utilisant un module redondant lorsque le module principal est défaillant peut nécessiter une opération de maintenance. Afin d'améliorer les fonctionnalités des aéronefs, réduire le poids des équipements électroniques grâce à une plus grande intégration, réduire les coûts grâce à l'utilisation de modules génériques, et faciliter les opérations de maintenance, l'avionique est maintenant de plus en plus intégrée selon une architecture appelée IMA (sigle d'lntegrated Modular Avionics en terminologie anglo-saxonne). Selon cette architecture, les fonctionnalités des systèmes avioniques utilisent autant que possible des ressources génériques de calcul et d'entrées/sorties dans lesquels elles sont implémentées. Néanmoins, un système de ségrégation ou de partitionnement permet d'isoler chacune des fonctionnalités de telle sorte que la défaillance d'une fonction n'ait pas d'influence sur une autre. La figure la illustre schématiquement un exemple d'architecture IMA.

Le coffret électrique 100, aussi appelé armoire électrique ou cabinet en terminologie anglo-saxonne, comprend ici les baies 105-1 à 105-n adaptées à recevoir des cartes, par exemple des cartes de type PCB (sigle de Printed Circuit Board en terminologie anglo-saxonne). Le coffret électrique 100 comprend dans sa partie arrière des connecteurs pour relier les cartes insérées dans les baies 105-1 à 105-n les unes aux autres et pour connecter ces cartes aux composants de l'aéronef. A titre d'illustration, le coffret électrique 100 comprend ici deux cartes génériques de calcul, aussi appelées calculateurs, adaptées à exécuter des applications logicielles pour implémenter des fonctions d'avionique.

Chaque calculateur comprend ici les ressources qui lui sont nécessaires liées, notamment, à l'alimentation électrique et aux fonctions de communication. A titre d'illustration, la demande de brevet FR 2 903 511 décrit une telle architecture. La figure 1 b illustre l'architecture logique associée à l'architecture IMA illustrée sur la figure la. Les calculateurs peuvent ici recevoir et/ou transmettre des données via un réseau de communication 115. Chaque unité de calcul 110-i comprend un système d'exploitation 120-i permettant l'exécution d'une ou de plusieurs applications 125-i. Ainsi, l'architecture IMA offre une couche réseau, une couche matérielle formée par l'ensemble des unités de calcul, une couche logiciel de bas niveau et une couche logicielle applicative fournissant les fonctions d'avioniques. L'avionique modulaire intégrée offre donc des capacités de calcul et de communications aux applications avioniques requérant des performances stables, garanties et reproductibles, tout en assurant un confinement des erreurs et donc une non-interférence du comportement d'une application sur une autre. Ces capacités sont fournies au sein de modules offrant des ressources de calcul et de communications partagées ou mises en commun. La norme ARINC 653 définit une interface de programmation pour les applications avioniques permettant d'accéder à des services du système d'exploitation utilisé. Ce dernier permet d'exécuter les applications en temps partagé au travers d'une allocation ségrégée des ressources temporelles, notamment des accès à l'unité centrale, et matérielles, notamment des accès à de la mémoire et à des périphérique d'entrée/sortie, par exemple des périphériques de type AFDX (sigle d'Avionic Full DupleX en terminologie anglo- saxonne), ARINC 429, CAN (acronyme de Controller Area Network en terminologie anglo-saxonne), discret et analogique. La configuration d'un module est typiquement réalisée à partir d'un seul fichier binaire obtenu par la compilation des données de configuration propres à chaque application mise en oeuvre dans le module. Une telle compilation doit donc être réalisée pour chaque évolution des applications qui entraîne une modification de la configuration de leur interface de programmation afin de permettre la configuration correspondante du module. Il est donc nécessaire de disposer d'une multitude de fichiers de configuration du module pour pallier à la combinatoire des évolutions propres de chaque application en vue de leur intégration. La nécessité de produire des fichiers de configuration couvrant cette combinatoire limite la réactivité des développements concurrents des applications et nécessite un travail important. L'invention permet de résoudre au moins un des problèmes exposés précédemment. L'invention a ainsi pour objet un procédé de configuration d'un module dans un système informatique modulaire, ledit module comprenant des ressources temporelles et matérielles ainsi qu'un système d'exploitation permettant une exécution ségréguée d'au moins deux applications à l'aide d'au moins une partie desdites ressources, ce procédé comprenant les étapes suivantes, - obtention d'au moins un premier paramètre de configuration d'au moins une partie desdites ressources dudit module, ledit au moins un premier paramètre de configuration visant une ressource propre audit système d'exploitation ou une ressource commune audit système d'exploitation et à au moins une desdites au moins deux applications ou auxdites au moins deux applications ; - configuration dudit module selon ledit au moins un premier paramètre ; - obtention d'au moins un second paramètre de configuration d'au moins une partie desdites ressources dudit module, ledit au moins second paramètre de configuration visant une ressource propre à l'une desdites au moins deux applications ; et, - configuration dudit module selon ledit au moins un second paramètres. La configuration incrémentale d'un module selon l'invention permet ainsi l'installation d'applications dans un module informatique sans qu'il soit nécessaire de prédéfinir la configuration correspondante. De façon avantageuse, le procédé comprend en outre une étape de chargement et d'exécution de ladite une desdites au moins deux applications.

Le procédé permet d'installer des applications indépendamment les unes des autres. Selon un mode de réalisation particulier, le procédé comprend en outre une étape de vérification dudit au moins un second paramètre, ladite étape de vérification comprenant une étape de comparaison dudit au moins un second paramètre à au moins une donnée de configuration de ressources dudit module, ladite au moins une donnée de configuration définissant l'ensemble des ressources dudit module pouvant être utilisées par ladite une desdites au moins deux applications.

Le procédé selon l'invention permet ainsi le partage de ressources du module prévenant tout problème d'interférence ou de dépassement de capacité du module lors de l'intégration d'applications. Il permet également de garantir le maintien des performances temporelles démontrées pour chaque application développée seule sur le module lorsqu'elle est intégrée avec d'autres applications et de garantir une non-interférence des comportements individuels des applications entre elles. Lesdits au moins un premier et au moins un second paramètres sont, de préférence, définis dans des fichiers de configuration distincts pouvant ainsi être facilement préparés indépendamment.

Toujours selon un mode de réalisation particulier, le procédé comprend en outre les étapes suivantes - obtention d'au moins un troisième paramètre de configuration d'au moins une partie desdites ressources dudit module, ledit au moins un troisième paramètre de configuration visant une ressource partagée entre ladite une desdites au moins deux applications et ledit système d'exploitation ou l'autre desdites au moins deux applications ; et, - configuration dudit module selon ledit au moins un troisième paramètres. Une telle configuration incrémentale d'un module permet de développer indépendamment chaque application utilisant des ressources partagées d'un module sans qu'il soit nécessaire de prédéfinir la configuration correspondante.

En outre, le procédé comprend, de préférence, une étape de vérification de la conformité dudit au moins un troisième paramètre selon ledit au moins un premier paramètre, ledit au moins un premier paramètre visant une ressource commune audit système d'exploitation et à ladite une desdites au moins deux applications. Le partage de ressources du module n'engendre ainsi pas de problème d'interférence ou de dépassement de capacité du module lors de l'intégration d'applications tout en garantissant les performances temporelles des applications et une non-interférence des comportements individuels des applications entre elles.

Toujours selon un mode de réalisation particulier, lesdites étapes d'obtention d'au moins un troisième paramètre de configuration et de configuration dudit module selon ledit au moins un troisième paramètre sont répétées pour ladite autre desdites au moins deux applications, ledit au moins un troisième paramètre de configuration associé à ladite une desdites au moins deux applications et ledit au moins un troisième paramètre de configuration associé à ladite autre desdites au moins deux applications visant une ressource partagée entre ladite une desdites au moins deux applications et ladite autre desdites au moins deux applications. Cette configuration incrémentale d'un module permet le développement concurrent d'applications ayant des cycles de développement différents et utilisant des ressources partagées sans qu'il soit nécessaire de prédéfinir la configuration correspondante. Le procédé comprend en outre, de préférence, une étape de vérification de la conformité dudit au moins un troisième paramètre associé à ladite une desdites au moins deux applications selon ledit au moins un troisième paramètre associé à ladite autre desdites au moins deux applications. Le partage de ressources du module n'engendre ainsi pas de problème d'interférence ou de dépassement de capacité du module lors de l'intégration d'applications tout en garantissant les performances temporelles des applications et une non-interférence des comportements individuels des applications entre elles.

Selon un mode de réalisation particulier, le procédé comprend en outre une étape préalable de démarrage dudit module, ladite étape de démarrage étant réalisée selon une configuration définie par défaut, ladite configuration définie par défaut permettant l'obtention desdits paramètres et la configuration dudit module. L'invention a également pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé décrit précédemment lorsque ledit programme est exécuté sur un ordinateur, un dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé décrit précédemment ainsi qu'un aéronef comprenant un module incluant ce dispositif. Les avantages procurés par ce programme d'ordinateur, ce dispositif et cet aéronef sont similaires à ceux évoqués précédemment. D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, au regard des dessins annexés dans lesquels : - la figure 1, comprenant les figures 1 a et 1 b, représente schématiquement un exemple d'architecture IMA ; - la figure 2 illustre le principe de configuration incrémentale de modules disposant d'un système d'exploitation de type ARINC 653 selon l'invention ; - la figure 3 illustre un exemple d'algorithme pouvant être mis en oeuvre dans le module illustré sur la figure 2 ; - la figure 4 illustre certains processus et outils pouvant être utilisés pour produire des fichiers de configuration ; et, - la figure 5 illustre un exemple d'architecture matérielle adaptée à mettre en oeuvre l'invention ou une partie de l'invention. De façon générale, l'invention vise un système permettant d'obtenir une configuration d'un module avionique à travers l'installation d'un fichier de configuration du module indépendant des cycles de vie des applications mises en oeuvre et l'installation de chacune des applications mises en oeuvre par ce module, comprenant l'installation d'un fichier de configuration associé à chacune de ces applications. Les applications et les fichiers de configuration correspondants peuvent être installées à la demande, en fonction des besoins. La configuration d'un module est ici basée sur l'utilisation de trois types de fichiers de configuration : - un fichier de configuration du module, appelé MOT. Il comporte les paramètres de configuration du système d'exploitation qui ne sont pas spécifiques à une application particulière. Ce fichier fait l'objet d'une installation propre avant les installations des applications ; - un fichier de configuration des ressources, appelés RCS. Il vise les paramètres de configuration du système d'exploitation qui permettent l'allocation de ressources temporelles, par exemple des tranches de temps déterminés par des ordonnanceurs cycliques, et matérielles, par exemple des plages de mémoire et des accès à des périphériques d'entrée/sortie (bus CAN, bus ARINC429, lignes discrètes, lignes analogiques, ...), du module à une application donnée. Ce fichier est spécifié par un gestionnaire des ressources de la plateforme pour une application donnée. Il est donné aux développeurs d'applications susceptibles d'être mises en oeuvre dans le module. En d'autres termes, ce fichier spécifie un périmètre de ressources utilisables par une application pour un cycle de développement, c'est-à-dire un budget de ressources allouées à cette application ; et, - un fichier de configuration locale d'une application, appelé ACT. Il spécifie l'utilisation réelle des ressources du module par l'application au travers des services de l'interface de programmation (API, acronyme d'Application Program Interface en terminologie anglo-saxonne) du système d'exploitation et des pilotes des ressources matérielles. Ces services ne permettent l'accès qu'aux ressources matérielles à l'intérieur du périmètre définies par le fichier de configuration de ressource et le fichier de configuration locale. Ce fichier de configuration locale est spécifié par le développeur d'application en fonction du fichier de configuration de ressources associé.

En d'autres termes, le fichier de configuration locale d'une application dérive du fichier de configuration des ressources associé à cette application selon les ressources réellement utilisées par l'application. Il s'agit

donc d'un sous ensemble du fichier de configuration des ressources correspondant. Les fichiers de configuration utilisent, par exemple, la syntaxe XML (sigle d'eXtended Markup Language en terminologie anglo-saxonne) ou UML (sigle d'Unified Modeling Language en terminologie anglo-saxonne). Chacun de ces fichiers comprend une référence aux ressources visées, par exemple une zone mémoire, ainsi que les paramètres associés, par exemple une plage mémoire de la zone mémoire visée. Un exemple de contenu d'un tel fichier de configuration est le suivant : <MEMORY> <MEMORY CODE AREA> <RESOURCE REF ID="CODE P1"/> <ACT CODE AREA ADDRESS="OXOOA00000" SIZE="0x00040000" /> <PARTITION CODE AREA ADDRESS="OXO08D0000" SIZE="0x00040000" /> </MEMORY CODE AREA> <MEMORY DATA AREA> <RESOURCEREF ID="DATA P1"/> <PARTITION OS DATA AREA ADDRESS="OXOOD90000" OSAREA SIZE="0x00040000" LOCAL AREA SIZE="0x00040000" STACK AREA SIZE="0x0008000/> <PARTITION CACHEABLE DATA AREA ADDRESS="OXOOF74000" SIZE="0x0190000" /> <1M EMORY DATA AREA> </MEMORY> <TIME> <PARTITION_SCHEDULE RESOURCEREF ID="SCHEDULE A2"> <PERIODIC_ RELEASE_POINT SLICE REF ID="11"/> </PARTITION SCHEDULE/> </TI M E> Il est rappelé qu'une plateforme est composée d'une cible comprenant des ressources matérielles (notamment un microprocesseur, une horloge, une mémoire et des entrées/sorties), typiquement un module, d'une couche d'abstraction permettant de dématérialiser la cible, de l'implémentation de services, typiquement des services de la norme ARINC 653, d'une interface de configuration de la plateforme et d'outils de maintenance.

Chaque application comprend ici un fichier de configuration local (ACT) et un fichier de type exécutable (EXE) correspondant à l'application en elle-même. Le système d'exploitation interdit à toute application d'accéder aux ressources matérielles ou temporelles d'une autre application qui sont spécifiées dans le fichier de configuration de ressources (RCS) qui lui est associé. Une application ne peut donc consommer plus de ressources qu'attribuées dans le fichier de configuration de ressources qui lui est associé. A ces fins, une vérification des fichiers de configuration locale au regard des fichiers de configuration des ressources correspondants est, de préférence, effectuée avant l'installation des applications. Pour faciliter le développement et la maintenance des applications, un gestionnaire de ressources attribue à chaque application des ressources qu'elle peut utiliser librement.

Ainsi, à titre d'illustration, un outil installé chez un gestionnaire des ressources de la plateforme permet de développer le fichier de configuration du module et les fichiers de configuration de ressources propres à chaque application, en attribuant des ressources matérielles et temporelles disjointes à chaque application. Certaines ressources peuvent néanmoins être partagées, en mode lecture uniquement. Les fichiers de configuration de ressources sont utilisés pour configurer des outils de production de fichiers de configuration locale. De même, un outil installé chez un développeur d'applications et configuré par un fichier de configuration de ressources propre à une application permet de développer un fichier de configuration locale pour permettre l'utilisation de toutes ressources matérielles ou temporelles du module à l'intérieur d'une enveloppe de ressources, définie dans le fichier de configuration de ressources correspondant, prévenant ainsi tout problème d'intégration.

Un élément logiciel du module permet de construire, de façon incrémentale, au démarrage de chaque application, la configuration complète du système d'exploitation et des pilotes de gestion des ressources matérielles à partir du fichier de configuration du module et des fichiers de configuration locale des applications chargées. Il détecte les ressources communes à plusieurs applications et ne les configure qu'une seule fois (fusion des éléments communs de configuration locale des applications).

Le schéma représenté sur la figure 2 illustre le principe de configuration incrémentale de modules disposant d'un système d'exploitation de type ARINC 653, conformément à l'invention. Après avoir été démarré dans un mode de configuration par défaut, permettant notamment le chargement du module, le module est configuré au travers du fichier de configuration du module (MCT). La configuration par défaut est, de préférence, une configuration minimale permettant le chargement du module, c'est-à-dire permettant la réception de données et l'installation d'applications. Comme indiqué précédemment, un mécanisme logiciel de fusion de données de configuration locale propres à chaque application est chargé au démarrage du module pour construire la configuration propre au système d'exploitation et au pilote lors du chargement des applications. Ensuite, les applications requises sont chargées. Le module est alors configuré selon chaque application installée, à partir du fichier de configuration locale de l'application (ACT). Lors de la configuration du module, réalisée ici lorsqu'une application est chargée, une fusion du fichier de configuration locale avec la configuration du module est réalisée de telle sorte que les ressources communes ne soient configurées qu'une seule fois. La fusion consiste, par exemple, à déterminer si les ressources partagées visées par le fichier de configuration locale de l'application en cours de chargement ont été configurées conformément à ce fichier de configuration. Si elles n'ont pas été configurées, elles le sont. S'il existe une différence entre la configuration de ces ressources et la configuration visées dans le fichier de configuration locale de l'application en cours de chargement, le chargement de cette dernière est abandonné. Une erreur est alors signalée. Plus précisément, l'environnement 200 comprend le module 205 devant être configuré et des moyens de stockage 210 comprenant notamment le fichier 215 de configuration du module et des fichiers 220-1 à 220-n de configuration locale associés aux applications 1 à n pouvant être chargées dans le module 205. Les moyens de stockages 210 comprennent également le code exécutable, noté 225-1 à 225-n, de ces applications. Il est observé ici que les moyens de stockage 210 peuvent appartenir au module 205. Il est également noté que le code exécutable des applications ainsi que les fichiers de configuration peuvent être reçus d'un système distant. Le module 205 est ici exploité à travers un système d'exploitation 230 utilisant des pilotes, référencés 235-1 à 235-p, ainsi que l'API 240.

Dans une première phase de démarrage du module 205, un fichier de configuration par défaut (non représenté) est utilisé pour lancer le système d'exploitation et permettre ensuite le chargement du fichier 215 de configuration du module et la configuration du module selon les paramètres de configuration définis dans ce fichier, notamment du système d'exploitation 230 et des pilotes 235-1 à 235-p utilisés. Les fichiers 220-1 à 220-n de configuration locale sont ensuite utilisés pour déterminer la configuration du module, de façon incrémentale, lors du chargement de chaque application. A ces fins, une fusion des paramètres de configuration de l'application en cours de chargement avec les paramètres de configuration du module, c'est-à-dire avec le fichier de configuration du module et les fichiers de configuration locale des applications préalablement chargées, est effectuée pour éviter une configuration multiple des ressources communes et vérifier la conformité de configuration avec le fichier de configuration locale de l'application en cours de chargement.

Comme illustré, la fusion est ici réalisée de façon répartie, par type de paramètres. Ainsi, par exemple, lors du chargement de l'application n, suivant le chargement des applications 1 à (n-1), une première fusion de paramètres du fichier 215 de configuration du module et de paramètres des fichiers 220-1 à 220-n de configuration locale est réalisée dans le module 240-0 pour obtenir la configuration 245-0 utilisée pour configurer le système d'exploitation 230. Comme indiqué précédemment, cette fusion permet de vérifier la conformité de configuration des ressources communes utilisées par l'application n et de configurer les ressources spécifiques à cette application. De façon similaire, d'autres fusions de paramètres du fichier 215 de configuration du module et de paramètres des fichiers 220-1 à 220-n de configuration locale sont réalisées dans les modules 240-1 à 240-p pour obtenir les configurations 245-1 à 245-p utilisées pour configurer les pilote 235-1 à 235-p utilisés. Lorsqu'elles sont mises en oeuvre dans le module 205, les applications 1 à n peuvent interagir avec le système d'exploitation 230 via l'API 240.

La figure 3 illustre un exemple d'algorithme pouvant être mis en oeuvre dans le module 205 illustré sur la figure 2. Après le démarrage du module 205, une première étape (étape 300) a pour objet le lancement du système d'exploitation, aussi appelé OS (sigle d'Operating System en terminologie anglo-saxonne). Le système d'exploitation utilise ici une configuration par défaut permettant le chargement ultérieur de fichiers de configuration et d'applications. Cette configuration peut notamment être mémorisée sous forme d'un fichier stocké avec ceux du système d'exploitation, par exemple dans une mémoire non volatile du module. Une étape suivante a pour objet l'obtention du fichier de configuration du module (étape 305) et la configuration du module (étape 310). Comme indiqué précédemment, ce fichier de configuration peut être chargé à partir d'une mémoire du module, de moyens de stockage externes ou de tout autre dispositif, génériquement référencés 215. Durant cette étape, un élément logiciel est chargé en mémoire du module pour construire, de façon incrémentale, au démarrage de chaque application, la configuration complète du système d'exploitation et des pilotes de gestion des ressources matérielles à partir du fichier de configuration du module et des fichiers de configuration locale des applications chargées. Cet élément logiciel est notamment en charge de mettre en oeuvre les étapes 315 à 330 décrites ci-dessous. Suite à la configuration du module, un test est effectué pour déterminer si une application doit être chargée (étape 315). La sélection d'une ou de plusieurs applications à charger peut être effectuée par un utilisateur, déterminer dans un fichier de configuration d'applications accessible au module ou déterminer de façon automatique selon des règles logiques prédéterminées. Si aucune application ne doit être chargée, l'algorithme prend fin.

Au contraire, si au moins une application doit être chargée, elle est identifiée et le fichier de configuration locale correspondant (ACT;) est obtenu (étape 320). L'indice i est ici incrémenté après chaque installation (réussie) d'application. Il représente donc le nombre d'applications chargées ou en cours de chargement. A nouveau, ce fichier de configuration locale peut être chargé à partir d'une mémoire du module, de moyens de stockage externes ou de tout autre dispositif, génériquement référencés 220. Une étape de fusion (étape 325) est alors mise en oeuvre pour fusionner les paramètres de configuration de l'application en cours de chargement avec les paramètres de configuration du module et les paramètres de configuration des applications précédemment chargées. Selon un mode de réalisation particulier, cette étape a notamment pour objet de vérifier que la configuration de ressources communes définie dans le fichier de configuration locale de l'application en cours de chargement est conforme au fichier de configurations des ressources correspondant. A ces fins, les paramètres du fichier de configuration locale sont comparés avec ceux définis dans le fichier de configuration des ressources correspondant. Si les ressources matérielles ou temporelles liées à l'application en cours de chargement se trouvent dans une enveloppe de ressources définie dans le fichier de configuration de ressources correspondant, un autre test est effectué pour vérifier la conformité de configuration des ressources communes. Dans le cas contraire, il est mis fin au chargement de l'application. Pour vérifier la conformité de configuration des ressources communes, les paramètres de configuration de ressources communes, généralement définies par typage, visées dans le fichier de configuration locale de l'application en cours de chargement sont comparés avec la configuration du module, c'est-à-dire, par exemple, avec le fichier de configuration du module et les fichiers de configuration locale des applications chargées précédemment. Si les paramètres de configuration de ressources communes visées dans le fichier de configuration locale de l'application en cours de chargement ne sont pas conformes avec la configuration du module, il est mis fin au chargement de l'application.

Si, au contraire, les paramètres de configuration de ressources communes visées dans le fichier de configuration locale de l'application en cours de chargement sont conformes avec la configuration du module, la configuration du module est mise à jour selon les paramètres de configuration locale propres à l'application en cours de chargement et le module est configuré en conséquence (étape 330). L'application est alors chargée et exécutée (étape 335). Le code exécutable de l'application peut être chargé à partir d'une mémoire du module, de moyens de stockage externes ou de tout autre dispositif, génériquement référencés 225. Alternativement, le code exécutable de l'application peut être chargé en même temps que le fichier de configuration locale (étape 320). Ainsi, lorsqu'une nouvelle application ou une nouvelle version d'une application préalablement installée sur le module est installée dans le module, la configuration est automatiquement adaptée en conséquence. Le schéma représenté sur la figure 4 illustre certains processus et outils pouvant être utilisés pour produire des fichiers de configuration tels que ceux décrits précédemment. Un outil 400 de gestion des ressources permet ici d'affecter des ressources d'un module à des applications et de vérifier la cohérence de ces paramètres vis-à-vis de la ségrégation nécessaire à la démonstration de la non interférence des comportements des applications entre-elles. L'outil 400 est, par exemple, un environnement logiciel mis en oeuvre sur un ordinateur de type PC (sigle de Persona/ Computer en terminologie anglo-saxonne) ou un serveur, permettant à un opérateur de déterminer ou de contrôler l'affectation des ressources à chaque application. L'outil 400 a notamment pour objet de déterminer le fichier MCT de configuration du module qui comporte les paramètres de configuration du système d'exploitation qui ne sont pas spécifiques à une application particulière ainsi que des fichiers RCS1 à RCSn de configuration de ressources qui indiquent les ressources temporelles et matérielles du module allouées à chaque application 1 à n pouvant être mise en oeuvre dans le module. Les fichiers de configuration des ressources RCS1 à RCSn, propres à chaque application, sont transmis aux développeurs de chacune de ces applications. Les développeurs utilisent ici des outils référencés 405-1 à 405-n pour développer le code de ces applications et générer le code exécutable correspondant ainsi que pour déterminer les ressources effectivement utilisées par ces applications, dans la limite des ressources définies dans les fichiers de configuration de ressources correspondants. En d'autres termes, des fichiers de configuration de ressources sont utilisés pour configurer des outils de spécification des configurations locales. Ces outils garantissent le confinement des configurations locales à l'intérieur du périmètre définit par le gestionnaire de ressources du module et, par conséquent, le crédit de qualification (performances démontrées) de chaque application lorsque ces applications s'exécutent ensemble en temps partagé sur le module. Comme illustré, le fichier de configuration du module (MCT) ainsi que les fichiers de configuration locale (ACT1 à ACTn) et le code exécutable associés aux applications 1 à n sont transmis au module ou à des moyens de stockage associés pour permettre leur mise en oeuvre. La figure 5 illustre un exemple d'architecture matérielle, par exemple un calculateur, un serveur ou un ordinateur, adaptée à mettre en oeuvre l'invention, notamment l'algorithme représenté sur la figure 3, ainsi que les outils de gestion de ressources et de développement décrit en référence à la figure 5. Le dispositif 500 comporte ici un bus de communication 505 auquel sont reliés : - une ou plusieurs unités centrales de traitement ou microprocesseurs 510 (CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ; - une mémoire morte 515 (ROM, acronyme de Read Only Memory en terminologie anglo-saxonne) pouvant comporter les programmes (prog, prog1 et prog2) nécessaires à la mise en oeuvre de l'invention ; - une mémoire vive ou mémoire cache 520 (RAM, acronyme de Random Access Memory en terminologie anglo-saxonne) comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution des programmes précités ; et - une interface de communication 550 adaptée à transmettre et à recevoir des données. De façon optionnelle, le dispositif 500 peut également disposer des éléments suivants : - une ou plusieurs unités d'affichage 525 permettant de visualiser des données et pouvant servir d'interface graphique avec l'utilisateur qui pourra interagir avec les programmes selon l'invention, à l'aide d'un clavier et d'une souris 530 ou d'un autre dispositif de pointage tel qu'un écran tactile ou une télécommande ; - d'un disque dur 535 pouvant comporter les programmes précités, des informations à traiter selon l'invention, un référentiel de configuration, un rapport de configuration théorique et/ou réelle et/ou des règles de calcul de clés de vérification ; et - d'un lecteur de cartes mémoires 540 adapté à recevoir une carte mémoire 545 et à y lire ou à y écrire des données traitées ou à traiter selon l'invention. Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le dispositif 500 ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément du dispositif 500 directement ou par l'intermédiaire d'un autre élément du dispositif 500. Le code exécutable de chaque programme permettant au dispositif programmable de mettre en oeuvre les processus selon l'invention, peut être stocké, par exemple, dans le disque dur 535 ou en mémoire morte 515.

Selon une variante, la carte mémoire 545 peut contenir des informations, notamment des informations à traiter selon l'invention, ainsi que le code exécutable des programmes précités qui, une fois lu par le dispositif 500, est stocké dans le disque dur 535. Selon une autre variante, le code exécutable des programmes et les informations à traiter selon l'invention pourront être reçus, au moins partiellement, par l'intermédiaire de l'interface 550, pour être stocké de façon identique à celle décrite précédemment. De manière plus générale, le ou les programmes ainsi que les informations à traiter selon l'invention pourront être chargés dans un des moyens de stockage du dispositif 500 avant d'être exécutés.

L'unité centrale 510 va commander et diriger l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur 535 ou dans la mémoire morte 515 ou bien dans les autres éléments de stockage précités. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 535 ou la mémoire morte 515, sont transférés dans la mémoire vive 520 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention.

Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente.

Claims

REVENDICATIONS1. Procédé de configuration d'un module (205) dans un système informatique modulaire, ledit module comprenant des ressources temporelles et matérielles ainsi qu'un système d'exploitation (230) permettant une exécution ségréguée d'au moins deux applications à l'aide d'au moins une partie desdites ressources, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes, - obtention (305) d'au moins un premier paramètre de configuration d'au moins une partie desdites ressources dudit module, ledit au moins un premier paramètre de configuration visant une ressource propre audit système d'exploitation ou une ressource commune audit système d'exploitation et à au moins une desdites au moins deux applications ou auxdites au moins deux applications ; - configuration (310) dudit module selon ledit au moins un premier paramètre ; - obtention (320) d'au moins un second paramètre de configuration d'au moins une partie desdites ressources dudit module, ledit au moins second paramètre de configuration visant une ressource propre à l'une desdites au moins deux applications ; et, - configuration (330) dudit module selon ledit au moins un second paramètres.
2. Procédé selon la revendication 1 comprenant en outre une étape de chargement et d'exécution (335) de ladite une desdites au moins deux applications.
3. Procédé selon la revendication 1 ou la revendication 2 comprenant en outre une étape de vérification dudit au moins un second paramètre, ladite étape de vérification comprenant une étape de comparaison dudit au moins un second paramètre à au moins une donnée de configuration de ressources dudit module, ladite au moins une donnée de configurationdéfinissant l'ensemble des ressources dudit module pouvant être utilisées par ladite une desdites au moins deux applications.
4. Procédé selon l'une quelconque des revendications précédentes selon lequel lesdits au moins un premier et au moins un second paramètres sont définis dans des fichiers de configuration distincts.
5. Procédé selon l'une quelconque des revendications précédentes comprenant en outre les étapes suivantes, - obtention (320) d'au moins un troisième paramètre de configuration d'au moins une partie desdites ressources dudit module, ledit au moins un troisième paramètre de configuration visant une ressource partagée entre ladite une desdites au moins deux applications et ledit système d'exploitation ou l'autre desdites au moins deux applications ; et, - configuration (330) dudit module selon ledit au moins un troisième paramètres.
6. Procédé selon la revendication précédente comprenant en outre une étape de vérification (325) de la conformité dudit au moins un troisième paramètre selon ledit au moins un premier paramètre, ledit au moins un premier paramètre visant une ressource commune audit système d'exploitation et à ladite une desdites au moins deux applications.
7. Procédé selon la revendication 5 ou la revendication 6 selon lequel lesdites étapes d'obtention d'au moins un troisième paramètre de configuration et de configuration dudit module selon ledit au moins un troisième paramètre sont répétées pour ladite autre desdites au moins deux applications, ledit au moins un troisième paramètre de configuration associé à ladite une desdites au moins deux applications et ledit au moins un troisième paramètre de configuration associé à ladite autre desdites au moins deux applications visant une ressource partagée entre ladite une desdites au moins deux applications et ladite autre desdites au moins deux applications.
8. Procédé selon la revendication précédente comprenant en outre une étape de vérification (325) de la conformité dudit au moins un troisième paramètre associé à ladite une desdites au moins deux applications selon leditau moins un troisième paramètre associé à ladite autre desdites au moins deux applications.
9. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape préalable de démarrage (300) dudit module, ladite étape de démarrage étant réalisée selon une configuration définie par défaut, ladite configuration définie par défaut permettant l'obtention desdits paramètres et la configuration dudit module.
10. Programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications précédente lorsque ledit programme est exécuté sur un ordinateur.
11. Dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 9.
12. Aéronef comprenant un module incluant le dispositif selon la revendication précédente.