FR2972821A1 - Procede et dispositif d'installation/desinstallation de modules logiciels, avec resolution centralisee de contraintes, dans des equipements d'aeronef - Google Patents

Abstract

L'invention a notamment pour objet l'installation et/ou la désinstallation d'au moins un module logiciel, avec résolution centralisée de contraintes, dans des équipements d'aéronef. Après avoir reçu une liste de références de modules logiciels, ladite liste comprenant au moins une référence audit au moins un module logiciel, et au moins une commande, liée à ladite au moins une référence, d'installation ou désinstallation dudit au moins un module logiciel, les contraintes sont accédées. Cet accès est indépendant de l'accès audit au moins un module. Une séquence d'opérations élémentaires résolvant lesdites contraintes est alors évaluée pour appliquer ladite au moins une commande à ladite au moins une référence.

Description

La présente invention concerne la configuration d'équipements informatiques dans les aéronefs et plus particulièrement un procédé et un dispositif d'installation/désinstallation de modules logiciels, avec résolution centralisée de contraintes, dans des équipements d'aéronefs. 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'Integrated 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. Ces ressources sont réparties dans des équipements qui comprennent chacun de nombreux modules logiciels. 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. A titre d'illustration, la demande de brevet FR 2 903 511 décrit une telle architecture.

Au sein de chaque équipement de l'aéronef, des modules logiciels sont chargés et mis à jour par un opérateur qui se trouve à bord de l'aéronef pour effectuer ces opérations. Le rôle de l'opérateur est notamment de lancer le chargement de ces modules ou de ces mises à jour et de vérifier que la configuration sélectionnée a été convenablement chargée dans l'équipement.

Ces opérations sont typiquement effectuées en utilisant un système de chargement centralisé qui permet d'adresser l'ensemble des équipements téléchargeables. La figure 1 illustre un exemple d'aéronef 100 comprenant un système embarqué de traitement de l'information 105. Le système 105 comprend lui- même un réseau de communication 110, par exemple un réseau de communication conforme au standard AFDX (sigle d'Avionic Full DupleX en terminologie anglo-saxonne), auquel sont connectés des équipements référencés ici 115 à 135. Parmi, ces équipements, certains peuvent avoir un rôle particulier dans le cadre du chargement et de la mise à jour de modules logiciels dans les équipements. Ainsi, par exemple, l'équipement 115 peut comprendre un module logiciel offrant une fonction de système de chargement centralisé permettant d'adresser l'ensemble des équipements téléchargeables, notamment lui-même. Toujours à titre d'illustration, l'équipement 120 peut être utilisé comme emplacement de stockage, aussi appelé repository en terminologie anglo-saxonne, pour stocker les modules logiciels devant être installés sur des équipements. L'équipement 120 comprend alors typiquement un dispositif de lecture, par exemple un lecteur de cartes mémoires ou un lecteur de DVD, permettant de transférer des modules logiciels provenant d'équipementiers dans l'emplacement de stockage. Les modules logiciels sont généralement fournis par des équipementiers sous forme de loads, c'est-à-dire d'ensembles comprenant des applications ou fonctions logicielles ainsi que des éléments infalsifiables permettant d'authentifier ces applications ou fonctions logicielles, c'est-à-dire d'en démontrer l'intégrité et l'origine. Les opérations devant être réalisées par un opérateur pour charger des équipements peuvent être différentes d'un équipement à un autre, notamment en fonction de contraintes propres à certains équipements. De telles contraintes peuvent être multiples. Elles peuvent concerner, par exemple, des ordres d'installation ou d'effacements. Elles sont liées à la complexité des modules logiciels et leurs interactions. Pour tenir compte de ces contraintes, les concepteurs des systèmes embarqués de traitement de l'information écrivent généralement des procédures qui doivent être suivies par les opérateurs lors des opérations de chargement et de mise à jour de modules logiciels. Cependant, de telles procédures complexifient les opérations des opérateurs, sont consommatrices de temps pour ces derniers et constituent une source potentielle de problèmes liés à des erreurs de manipulation. Pour limiter ces problèmes, la réalisation de contraintes peut être effectuée à l'aide de fonctions de traitement par lots, appelées fonctions batch. Une fonction batch est ici une fonction permettant de réaliser de manière automatique l'installation de modules logiciels dans un ordre donné.

Cependant, cette fonction ne couvre pas tous les types de contraintes. En outre, les fonctions batch peuvent être considérées comme une traduction de procédures. Par conséquent, l'utilisation de fonctions batch à la place de procédures ne fait que déplacer une partie de la complexité liée aux procédures des opérateurs vers la programmation de fonctions batch. Enfin, le nombre de fonctions batch à réaliser est directement lié au nombre de cas possibles de chargements des modules logiciels, ce qui est prohibitif pour une solution standard. Il existe donc un besoin, dans les systèmes embarqués, notamment les systèmes embarqués d'aéronefs, pour gérer les contraintes lors de l'installation ou la mise à jour de modules logiciels, permettant de définir des procédures uniformes pour les opérateurs en charge de ces opérations. La gestion des contraintes ne doit pas, de préférence, nécessiter de modification des loads générés par des équipementiers afin qu'il ne soit pas nécessaire de modifier les loads existants (de telle sorte que les loads existants soient utilisables sans modification). L'invention permet de résoudre au moins un des problèmes exposés 15 précédemment. L'invention a ainsi pour objet un procédé pour ordinateur pour l'installation ou la désinstallation d'au moins un module logiciel dans au moins un équipement d'un système embarqué, selon au moins une contrainte de dépendance visant ledit au moins un module logiciel, ce procédé comprenant 20 les étapes suivantes, - réception d'une liste de références de modules logiciels, ladite liste comprenant au moins une référence audit au moins un module logiciel ; - réception d'au moins une commande, liée à ladite au moins une référence, d'installation ou désinstallation dudit au moins un module logiciel ; 25 - accès à ladite au moins une contrainte, l'accès à ladite au moins une contrainte étant indépendant de l'accès audit au moins un module ; et - évaluation d'une séquence d'opérations élémentaires résolvant ladite au moins une contrainte pour appliquer ladite au moins une commande à ladite au moins une référence. 30 Le procédé selon l'invention permet ainsi de traiter une commande d'installation et/ou de désinstallation de modules logiciels selon des contraintes gérées automatiquement, indépendamment des modules logiciels. Il n'est ainsi pas nécessaire de modifier ces modules logiciels pour qu'ils soient traités selon des contraintes déterminées indépendamment de leur développement. Selon un mode de réalisation particulier, le procédé comprend en outre, suite à l'exécution de ladite étape d'évaluation de ladite liste d'opérations élémentaires, une étape d'obtention dudit au moins un module logiciel permettant ainsi de l'installer. De façon avantageuse, le procédé comprend en outre une étape d'authentification dudit au moins un module logiciel, ledit au moins un module logiciel étant codé dans une structure permettant son authentification. Le procédé selon l'invention permet ainsi de contrôler l'intégrité d'un module avant son installation afin de contrôler la sûreté de l'équipement du système embarqué. Le procédé comprend en outre, de préférence, une étape d'authentification de ladite au moins une contrainte, ladite au moins une contrainte étant codée dans une structure permettant son authentification, lesdites structures de codage dudit au moins un module logiciel et de ladite au moins une contrainte étant distinctes et indépendantes. Le procédé selon l'invention permet ainsi de contrôler l'intégrité de contraintes avant l'installation et/ou la désinstallation de modules logiciels afin de contrôler la sûreté de l'équipement du système embarqué. 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. Les avantages procurés par ce programme d'ordinateur sont similaires à ceux évoqués précédemment. L'invention a aussi pour objet un dispositif pour l'installation ou la désinstallation d'au moins un module logiciel dans au moins un équipement d'un système embarqué, selon au moins une contrainte de dépendance visant ledit au moins un module logiciel, ce dispositif comprenant les moyens suivants, - moyens de réception d'une liste de références de modules logiciels, ladite liste comprenant au moins une référence audit au moins un module logiciel, et d'au moins une commande, liée à ladite au moins une référence, d'installation ou désinstallation dudit au moins un module logiciel ; - moyens d'accès à ladite au moins une contrainte ; et - moyens d'évaluation d'une liste d'opérations élémentaires résolvant ladite au moins une contrainte pour appliquer ladite au moins une commande à ladite au moins une référence. Le dispositif selon l'invention permet ainsi de traiter une commande d'installation et/ou de désinstallation de modules logiciels selon des contraintes gérées automatiquement, indépendamment des modules logiciels. Il n'est ainsi pas nécessaire de modifier ces modules logiciels pour qu'ils soient traités selon des contraintes déterminées indépendamment de leur développement. Le dispositif comprend en outre, de préférence, des moyens d'obtention dudit au moins un module logiciel et de transmission dudit au moins un module logiciel audit au moins un équipement, permettant son installation.

L'invention a également pour objet un système embarqué comprenant le dispositif décrit précédemment, ledit système embarqué comprenant au moins deux équipements connectés l'un à l'autre via un réseau de communication, ledit dispositif appartenant à l'un desdits au moins deux équipements pour permettre l'installation ou la désinstallation dudit au moins un module logiciel dans l'autre desdits au moins deux équipements. L'invention a aussi pour objet un système embarqué comprenant le dispositif décrit précédemment, ledit système embarqué comprenant au moins deux équipements connectés l'un à l'autre via un réseau de communication, lesdits moyens de réception appartenant à l'un desdits au moins deux équipements et lesdits moyens d'accès et d'évaluation appartenant à l'autre desdits au moins deux équipements pour permettre l'installation ou la désinstallation dudit au moins un module logiciel dans ledit autre desdits au moins deux équipements. L'invention a aussi pour objet un aéronef comprenant le système 30 embarqué décrit précédemment. Les avantages procurés par ces systèmes embarqués et cet aéronef sont similaires à ceux décrits 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 illustre un exemple d'aéronef comprenant un système embarqué standard de traitement de l'information ; - la figure 2, comprenant les figures 2a et 2b, illustre un premier exemple de mise en oeuvre de l'invention ; - la figure 3, comprenant les figures 3a et 3b, illustre un second exemple de mise en oeuvre de l'invention ; - la figure 4 illustre schématiquement certaines étapes d'un exemple d'algorithme selon l'invention pour permettre une installation/désinstallation de modules logiciels dans des équipements d'un système embarqué, selon des contraintes de dépendances, sans contrainte spécifique ni pour l'utilisateur ni pour les développeurs des modules logiciels ; et - la figure 5 illustre un exemple de dispositif de traitement d'informations adapté à mettre en oeuvre, au moins partiellement, l'invention. De façon générale, l'invention permet de résoudre des contraintes de dépendances de chargement/déchargement de modules logiciels, dans des équipements d'un système embarqué de traitement de l'information, par un système de chargement centralisé utilisant une déclaration externe des contraintes. L'ensemble de ces contraintes est, de préférence, exprimé dans des structures externes, par exemple des fichiers tiers, comprenant les contraintes elles-mêmes et des informations permettant d'authentifier ces contraintes, c'est-à-dire dans un load tiers. Un tel load tiers est indépendant des loads des équipementiers ayant fourni les équipements concernés. Le load tiers peut notamment être créé par le concepteur du système embarqué comprenant les équipements. Les contraintes sont, par exemple, fournies par les équipementiers dans un document formel. Selon un mode de réalisation particulier, un équipement du système embarqué comprend au moins une partie d'une application de chargement centralisé offrant une interface utilisateur. Cette interface permet notamment à un opérateur de sélectionner un ou plusieurs équipements particuliers et, pour chacun de ces équipements, une liste de modules logiciels ou de loads à charger, décharger ou mettre à jour. Il peut alors lancer les opérations de chargement, déchargement et/ou mise à jour. Les interactions demandées à l'opérateur vis-à-vis de l'application de chargement sont ici similaires quelque soit l'équipement et la liste des modules logiciels à charger, décharger et/ou mettre à jour. Le système de chargement centralisé utilise alors la liste des modules logiciels à charger, décharger et/ou mettre à jour ainsi que le contenu du load tiers comprenant des contraintes pour déterminer une séquence d'opérations élémentaires de chargement, déchargement et/ou mise à jour devant effectuer et permettant de vérifier l'ensemble des contraintes. Le système de chargement centralisé réalise ensuite ces opérations élémentaires sur les équipements concernés. Les opérations qui peuvent être demandées par un opérateur sont typiquement des opérations d'installation de modules logiciels sur un ou plusieurs équipements et des opérations de désinstallation de modules logiciels sur un ou plusieurs équipements. De façon avantageuse, une installation a deux variantes, l'une visant l'installation d'un module logiciel sur un équipement et l'autre visant la mise à jour de ce module logiciel dans cet équipement. Les opérations élémentaires sont ainsi des opérations d'installation et de désinstallation de loads. Ainsi, il n'est pas nécessaire de mettre en oeuvre de fonction de mise à jour, en tant que telle, de modules logiciels.

A titre d'illustration, les contraintes envisagées ici sont des contraintes de dépendances, notamment des contraintes de dépendances d'installation, de désinstallation et de mise à jour. Ainsi, considérant deux modules logiciels (ou loads) A et B, une règle d'application d'une contrainte de dépendances d'installation entre ces modules peut s'exprimer sous la forme suivante : si le module B dépend du module A, alors le module B ne peut être installé correctement que si le module A a déjà été installé dans l'équipement.

De même, une règle d'application d'une contrainte de dépendances de désinstallation entre ces modules peut s'exprimer sous la forme suivante : si le module A dépend du module B, alors le module A ne peut être désinstallé correctement que si le module B a déjà été désinstallé dans l'équipement.

De façon similaire, une règle d'application d'une contrainte de capacité d'un module logiciel à gérer une mise à jour peut être exprimée de la façon suivante : si le module A ne sait pas gérer les mises à jour alors, pour installer une version n+1 du module A, il faut préalablement désinstaller une version antérieure installée du module A, dans le cas contraire, la version n+1 peut être installée directement. Si, dans un souci de clarté, les règles énoncées précédemment à titre d'exemple ne visent que deux modules logiciels, elles peuvent viser plus de deux modules. Ainsi, si un module logiciel A dépend de deux modules logiciels B et C, l'installation du module A requiert l'installation préalable des modules B et C. En outre, si une contrainte et une règle d'application de cette contrainte peuvent être exprimées de façon distincte, sous forme d'une contrainte particulière (par exemple « l'installation de A dépend de 8 ») et d'une règle générique (par exemple « si l'installation de y dépend de x, alors y ne peut être installé que si x est installé »), elles peuvent également être exprimées de façon commune, par exemple sous forme de règle instanciée (par exemple « si l'installation de 8 dépend de A, alors 8 ne peut être installé que si A est installé »), c'est-à-dire d'une règle visant des modules logiciels spécifiques. Comme indiqué précédemment, les contraintes de dépendances associées à tous les modules logiciels susceptibles d'être installés dans les équipements d'un système embarqué sont décrites dans un load tiers. Ces contraintes sont avantageusement exprimées par type. Ainsi le load tiers peut comprendre trois parties, une première partie liée aux contraintes de dépendances d'installation, une deuxième partie liée aux contraintes de dépendances de désinstallation et une troisième partie liée à la capacité d'un load à gérer une mise à jour. Ces trois parties peuvent être génériques, c'est-à- dire communes à tous équipements (à l'exception des équipements visés par des contraintes spécifiques) ou spécifiques à certains équipements. A titre d'illustration, les lignes de pseudo-code données dans l'annexe Al montre un exemple d'un extrait du contenu d'un Joad tiers comprenant des contraintes génériques et des contraintes spécifiques à un équipement EQUIP_AA. Dans cet exemple, les symboles suivant les caractères « //» sont considérés comme représentant des commentaires et ne sont pas traités. Par ailleurs, la notation « i : expression » signifie que l'expression suivant l'identifiant i ne s'applique qu'à l'équipement référencé « i », l'absence de référence d'un équipement signifiant que l'expression s'applique de façon générique, c'est-à-dire à tous les équipements (à l'exception de ceux visés par des contraintes spécifiques). Les caractères « » créent un lien de dépendance d'installation entre les modules logiciels référencés de chaque côté de ces caractères. De même, les caractères « » créent un lien de dépendance de désinstallation entre les modules logiciels référencés de chaque côté de ces caractères et le caractère « = » exprime une contrainte de mise à jour sur les modules logiciels référencés à gauche de ce caractère. Bien entendu, d'autres conventions peuvent être utilisées. Ainsi, l'expression «A 8, C » signifie que, de façon générale, l'installation du module logiciel A dépend de l'installation des modules logiciels B et C. De même, l'expression « EQUIP AA : A 8 » signifie que, pour l'équipement référencé EQUIP AA, l'installation du module logiciel A dépend de l'installation du module logiciel B. De la même façon, l'expression « 8 A » signifie que, de façon générale, la désinstallation du module logiciel B dépend de la désinstallation du module logiciel A et l'expression « 8 = » signifie que, de façon générale, le module logiciel B ne supporte pas de mise à jour (c'est-à-dire qu'il requiert sa désinstallation avant l'installation d'une version différente). Il est observé ici que seules les contraintes positives peuvent être mentionnées dans le Joad tiers. Ainsi, par exemple, la contrainte « C » n'est pas obligatoire dans la mesure où il ne s'agit pas réellement d'une contrainte mais seulement d'une information visant à préciser que le module logiciel C n'a pas de dépendance d'installation.

Ainsi, à partir d'une liste de modules logiciels ou de loads à installer et/ou à désinstaller, il est possible, en utilisant des contraintes d'un load tiers et des règles d'application de contraintes, d'en déduire une séquence d'opérations élémentaires.

Bien entendu, les contraintes de dépendances doivent être accessibles avant toute opération d'installation et/ou de désinstallation, ces contraintes étant nécessaires pour générer une séquence d'opérations élémentaires d'installation/désinstallation. Par ailleurs, il est observé que les contraintes de dépendances n'ont pas vocation à évoluer constamment. En effet, les raisons essentielles conduisant à un changement de contraintes de dépendances sont l'apparition de nouveaux modules logiciels à installer et la modification de modules logiciels existants. Ainsi, à titre d'illustration, en reprenant les règles d'application de contraintes décrites précédemment et les contraintes données en annexe A1, si un opérateur demande l'installation des modules logiciels A, B, C, D et E dans un équipement ne comprenant aucun module logiciel, le système central de chargement en déduit la séquence d'installation suivante : C, B, A, E, D qui vérifie les contraintes imposées par l'équipement. De façon similaire, si un équipement comprend les modules logiciels A, B, C, D et E et si un opérateur demande la désinstallation des modules logiciels B et E, le système central de chargement, toujours sur la base des règles d'application de contraintes décrites précédemment et des contraintes données en annexe Al, détermine la séquence de désinstallation suivante : A, B, D et E qui vérifie les contraintes imposées par l'équipement.

De même, si un équipement comprend les modules logiciels A, B, C, D et E, ces modules logiciels étant dans une version n, et si un opérateur demande la mise à jour des modules logiciels A, B et C avec une version n+1, le système central de chargement, toujours sur la base des règles d'application de contraintes décrites précédemment et des contraintes données en annexe Al, détermine la séquence suivante : installation du module logiciel C, désinstallation du module logiciel A puis du module logiciel B puis installation du module logiciel B puis du module logiciel A, qui vérifie les contraintes imposées par l'équipement. Il est observé ici que si un opérateur peut, selon un mode de réalisation particulier, fournir la liste de tous les modules logiciels devant être installés et/ou désinstallés et répondant aux contraintes de dépendances, le système central de chargement signalant une erreur s'il manque des modules, il est également possible, pour un opérateur, selon un autre mode de réalisation, de ne fournir que la liste des modules logiciels à installer et/ou désinstaller, sans tenir compte des contraintes de dépendance. Dans ce cas, la liste des modules logiciels à installer et/ou désinstaller est complétée par le système central de chargement selon les contraintes exprimées dans le load tiers et les règles d'application de contraintes prédéfinies. La figure 2, comprenant les figures 2a et 2b, illustre un premier exemple de mise en oeuvre de l'invention.

La figure 2a illustre schématiquement l'architecture d'un système embarqué de traitement de l'information 200 mettant en oeuvre l'invention, selon un premier mode de réalisation. Comme représenté, ce système comprend un réseau de communication 205, par exemple un réseau AFDX, auquel sont connectés des équipements, notamment les équipements 210-i et 210-j. Chaque équipement comprend, ou peut comprendre, des modules logiciels. Ainsi, par exemple, l'équipement 210-j comprend les modules logiciels u, v et w, référencés 215-1, 215-2, 215-3, respectivement. L'équipement 210-i comprend ici un module particulier, référencé 220-1, correspondant au système de chargement centralisé (noté SCC). Ce module comprend lui-même plusieurs éléments, par exemple plusieurs modules logiciels. Comme indiqué précédemment, le système de chargement centralisé permet d'adresser l'ensemble des équipements téléchargeables, notamment l'équipement mettant en oeuvre le système de chargement centralisé lui-même, pour installer ou désinstaller des modules logiciels. Ainsi, par exemple, le module logiciel 220-1 permet à un opérateur d'installer le module logiciel 220-2. Le module logiciel correspondant au système de chargement centralisé est, de préférence, préinstallé dans un équipement particulier, par exemple dans une mémoire non volatile de cet équipement (alternativement, il peut, par exemple, comprendre des moyens pour installer ce module logiciel). L'équipement 210-i comprenant le système de chargement centralisé 5 est, par exemple, un serveur ANSU (sigle d'Aircraft Network Server Unit en terminologie anglo-saxonne). La figure 2b illustre un exemple d'architecture logique du module logiciel correspondant au système de chargement centralisé 220-1 illustré sur la figure 2a. Le système de chargement centralisé 220-1 comprend ici un module 10 logiciel de gestion référencé 225, utilisé pour gérer les modules logiciels dans les équipements du système embarqué. Ce module comprend une interface utilisateur 230, de préférence une interface graphique, permettant notamment à un opérateur de sélectionner des équipements et des modules logiciels ainsi que d'actionner des opérations d'installation et/ou désinstallation. 15 Le système de chargement centralisé 220-1 comprend en outre un module de téléchargement 235 permettant de contrôler le chargement à distance de modules logiciels dans des équipements ainsi que la désinstallation de modules logiciels dans ces équipements. Le système de chargement centralisé 220-1 comprend également ici 20 un module logiciel 240 de résolution de contraintes pouvant accéder à des contraintes 245 pour établir, selon une liste de modules logiciels à installer et/ou désinstaller, une séquence d'opérations élémentaires. Les contraintes 245, de préférence exprimées dans un load tiers, et/ou les modules logiciels à installer peuvent provenir d'un support amovible de 25 stockage, par exemple une carte mémoire de type SD (sigle de Secure Digital en terminologie anglo-saxonne) ou un DVD, auquel le système central de chargement peut accéder ou à un emplacement de stockage spécifique (repository). Un opérateur peut interagir avec le module 225 de gestion des 30 équipements, via l'interface utilisateur 230, pour permettre la sélection d'équipements et de modules logiciels et activer leur installation ou désinstallation.

Les sélections d'un opérateur sont transmises par le module de gestion 225 qui les transmet au module de résolution de contraintes 240 afin d'obtenir une séquence d'opérations élémentaires d'installation et/ou désinstallation de modules logiciels. Après avoir été évaluée, la séquence définie est transmise au module de gestion 225 qui contrôle les opérations élémentaires effectuées par le module de téléchargement 235 en conséquence. Si le module de résolution de contraintes ne peut pas évaluer une séquence d'instructions élémentaires satisfaisant la demande d'un opérateur et les contraintes de dépendances, un message d'erreur est, de préférence, adressé à l'opérateur, via l'interface 230. Le cas échéant, le message d'erreur comprend avantageusement une liste de modules logiciels manquants qui permettraient de résoudre les contraintes. L'opérateur peut ainsi sélectionner les modules logiciels manquants ou valider un choix proposé et ré-effectuer une demande d'installation.

Ainsi, selon l'exemple illustré sur la figure 2, le système de chargement centralisé est mis en oeuvre dans un équipement particulier à partir duquel un opérateur peut contrôler les opérations d'installation et désinstallation de modules logiciels dans d'autres équipements ou dans l'équipement particulier lui-même.

Selon un autre exemple de mise en oeuvre de l'invention, illustré sur la figure 3, une partie du système de chargement centralisé est mise en oeuvre dans un équipement particulier à partir duquel un opérateur peut contrôler les opérations d'installation et désinstallation de modules logiciels dans d'autres équipements ou dans l'équipement particulier lui-même tandis qu'une autre partie du système de chargement centralisé est mise en oeuvre dans l'équipement dans lequel un ou plusieurs modules logiciels sont installés et/ou désinstallés. La figure 3a illustre schématiquement l'architecture d'un système embarqué de traitement de l'information 200' mettant en oeuvre l'invention, selon un second mode de réalisation. Comme le système 200 décrit en référence à la figure 2a, ce système comprend un réseau de communication 205 tel qu'un réseau AFDX auquel sont connectés des équipements, notamment les équipements 210'-i et 210'-j. A nouveau, chaque équipement comprend, ou peut comprendre, des modules logiciels. L'équipement 210'-j comprend ici un module particulier, référencé 215'-1, correspondant à une partie du système de chargement centralisé (noté SOC) ainsi que des modules logiciels v et w, référencés 215-2, 215-3, respectivement. De même, l'équipement 210'-i comprend un module particulier, référencé 220'-1, correspondant à une partie du système de chargement centralisé ainsi que d'autres modules logiciels, par exemple le module logiciel référencé 220-2. Il est observé ici que parmi ces autres modules logiciels peut figurer un module logiciel 220-3 correspondant à une partie du système de chargement centralisé et similaire au module logiciel 215'-1. Ce module logiciel permet, en relation avec le module 220'-1, d'installer ou désinstaller des modules logiciels dans l'équipement i(210'-i). A nouveau, le système de chargement centralisé permet d'adresser l'ensemble des équipements téléchargeables pour installer ou désinstaller des modules logiciels. Ainsi, par exemple, le module logiciel 220'-1, combiné avec le module logiciel 215'-1, permet à un opérateur d'installer le module logiciel 215-3. Les équipements 210'-i et 210'-j sont, par exemple, des serveurs 20 ANSU. La figure 3b illustre un exemple d'architecture logique du système de chargement centralisé réparti entre les modules logiciels 220'-1 et 215'-1, et donc entre les équipements 210'-i et 210'-j, illustrés sur la figure 3a. La partie du système de chargement centralisé mise en oeuvre dans 25 le module 220'-1 de l'équipement 210'-i correspond essentiellement à un module logiciel connu sous le nom de DLCS (sigle de data loading and configuration system en terminologie anglo-saxonne), comprenant lui-même un module logiciel de gestion référencé 300, utilisé pour gérer des modules logiciels dans des équipements, et un modèle de téléchargement référencé 305 30 permettant de contrôler le chargement de modules logiciels dans des équipements. Le module de gestion 300 comprend ici une interface utilisateur 310, de préférence une interface graphique, permettant notamment à un opérateur de sélectionner des équipements et des modules logiciels ainsi que d'actionner des opérations d'installation et/ou désinstallation. Le module de téléchargement peut accéder à un support amovible de stockage, par exemple une carte mémoire de type SD ou un DVD, ou à un emplacement de stockage spécifique (repository) pour obtenir un Joad tiers ou des modules logiciels à installer. La partie du système de chargement centralisé mise en oeuvre dans le module 215'-1 d'un équipement 210'-j dans lequel des modules logiciels doivent être installés et/ou désinstallés peut être considérée comme un service basic d'installation (BS inst.). Ce service comprend ici un module logiciel de résolution de contraintes 315 et un module logiciel d'installation 320 permettant l'installation de modules logiciels transmis par le module de téléchargement 305. Comme décrit précédemment, les contraintes de dépendances sont, de préférence, exprimées dans un Joad tiers. Ces contraintes, référencées ici 325, doivent être transférées à l'équipement 210'-j dans lequel des modules logiciels doivent être installés ou désinstallés avant que des opérations élémentaires d'installation et/ou de désinstallation ne soient adressées à ce dernier. Le Joad tiers provient avantageusement de l'équipement 210'-i mettant en oeuvre l'autre partie du système de chargement centralisé. Un opérateur peut interagir avec le module 300 de gestion des équipements, via l'interface utilisateur 310, pour permettre la sélection d'équipements et de modules logiciels et activer leur installation ou désinstallation.

Comme dans le premier mode de réalisation décrit précédemment, les sélections d'un opérateur sont transmises par le module de gestion 300 au module de résolution de contraintes 315 afin d'obtenir une séquence d'opérations élémentaires d'installation et/ou désinstallation de modules logiciels. Après avoir été déterminée, la séquence définie est transmise au module de gestion 300 qui contrôle les opérations élémentaires effectuées par le module de téléchargement 305 et le module d'installation 320 en conséquence.

Comme décrit précédemment, si le module de résolution de contraintes ne peut pas trouver une séquence d'instructions élémentaires satisfaisant la demande d'un opérateur et les contraintes de dépendances, un message d'erreur est, de préférence, adressé à l'opérateur, via l'interface 310.

Le cas échéant, le message d'erreur comprend avantageusement une liste de modules logiciels manquants qui permettraient de résoudre les contraintes. L'opérateur peut ainsi sélectionner les modules logiciels manquants ou valider un choix proposé et ré-effectuer une demande d'installation. Le module de téléchargement transmet alors des instructions élémentaires au module d'installation 320 en charge d'installer ou désinstaller des modules logiciels dans l'équipement 210'-j. Lorsqu'une instruction élémentaire d'installation d'un module logiciel est transmise au module d'installation 320, cette instruction est, de préférence, accompagnée du module logiciel à installer ou d'une référence à ce dernier permettant au module d'installation 320 d'y accéder. Ce dernier peut ainsi, par exemple, installer le module logiciel 215-3 dans l'équipement 210'-j. Comme décrit précédemment, les modules logiciels à installer peuvent provenir d'un support amovible de stockage, par exemple une carte mémoire de type SD ou un DVD, ou un emplacement de stockage spécifique (repository).

De façon avantageuse, le module 320 fait appel au module 315 pour procéder à une vérification des dépendances avant de procéder à une installation ou désinstallation. Cette double vérification permet de prévenir une erreur ou un problème dans le module 210'-j. De façon avantageuse, les modules de résolution des contraintes 240 et 315 utilise un tri topologique, conformément à la théorie des graphes, pour déterminer une solution des contraintes. Une description du tri topologique est par exemple donnée dans l'ouvrage intitulé « Introduction to algorithms » de Thomas H. Cormen (ISBN 0-262-03293-7). La figure 4 illustre schématiquement certaines étapes d'un exemple 30 d'algorithme selon l'invention pour permettre une installation/désinstallation de modules logiciels dans des équipements d'un système embarqué, selon des contraintes de dépendances, sans contrainte spécifique ni pour l'utilisateur ni pour les développeurs des modules logiciels. Comme illustré, une première étape (étape 400) a ici pour objet la réception d'une liste de références à des modules logiciels devant être installés et/ou désinstallés. Cette liste de références peut être saisie par un opérateur ou être constituée par la sélection (effectuée par l'opérateur ou partiellement automatique) de modules logiciels. Cette étape comprend également la réception d'un identifiant du ou des équipements devant faire l'objet de l'installation ou la désinstallation des modules logiciels sélectionnés.

Dans une étape suivante (étape 405) une commande d'installation ou de désinstallation est reçue de l'opérateur. Il peut s'agir d'une commande globale à un ensemble de références de modules logiciels (par exemple la commande « installer les modules logiciels A et 8 ») ou de commandes spécifiques à chaque référence ou à des groupes de références (par exemple « installer le module A et désinstaller les modules 8 et C »). Les étapes 400 et 405 sont typiquement mises en oeuvre dans le module de gestion 225 ou 330 en utilisant l'interface 230 ou 310. Parallèlement, avant ou après, les contraintes ainsi que les règles d'application de ces contraintes, exprimées sous forme commune ou distincte, sont accédées (étape 410). Comme décrit précédemment, les contraintes sont, de préférence, accédées dans un load tiers, disponible à un emplacement spécifique (repository) ou dans un support amovible de stockage, tandis que les règles d'application sont, par exemple, accédées dans un fichier lié au système de chargement centralisé. Les règles d'application sont typiquement associées au module de résolution de contraintes 240 ou 315 ou comprises dans ce dernier. Dans un souci de sécurité et bien que non imposée par le procédé selon l'invention (comme illustré par l'emploi de trait pointillé sur la figure 4), les contraintes sont avantageusement authentifiées (étape 415). Les contraintes étant ici codées dans un load, l'authentification peut être réalisée de façon standard, comme les loads correspondant aux modules logiciels.

Il est observé que les étapes 410 et 415 sont avantageusement exécutées indépendamment des étapes 400 et 405, de telle sorte que lorsque plusieurs itérations d'installations/désinstallations sont envisagées, les étapes 410 et 415 ne sont exécutées qu'une seule fois. De même, s'il n'est pas possible de résoudre les contraintes et qu'une nouvelle sélection de modules logiciels est nécessaire, il est préférable de ne pas ré-exécuter les étapes 410 et 415. Dans une étape suivante (étape 420), une séquence d'opérations élémentaires permettant l'installation et/ou la désinstallation des modules logiciels sélectionnés est évaluée. Cette évaluation est basée sur la sélection opérée par l'opérateur, les contraintes et les règles d'application de ces contraintes, comme décrit précédemment. S'il n'est pas possible d'obtenir une telle séquence, un message est, de préférence, adressé à l'opérateur qui peut alors sélectionner de nouveaux modules logiciels à installer et/ou désinstaller ou valider un choix proposé par le système de chargement centralisé. Les étapes 410 et 420 sont ici mises en oeuvre dans le module de résolution de contraintes 240 ou 315. L'étape 415 est typiquement mise en oeuvre dans le module d'installation 320 qui centralise les fonctions d'authentification pour un équipement.

Les modules logiciels devant être installés sont alors obtenus (étape 425), par exemple à partir d'un emplacement de stockage spécifique (repository) ou d'un support amovible de stockage. Il est observé que cette étape d'obtention de modules logiciels, mise en oeuvre par les modules de téléchargement et/ou d'installation (DLCS ou SCC), est avantageusement exécutée après l'étape d'évaluation d'une séquence d'opérations élémentaires afin d'éviter un transfert inutile de ces modules. Le DLCS ou le SCC transmet ainsi les modules à l'équipement cible. A nouveau, pour des raisons de sécurité et bien que non imposée par le procédé selon l'invention (comme illustré par l'emploi de trait pointillé sur la figure 4), une étape d'authentification est, de préférence, mise en oeuvre afin d'authentifier les modules logiciels devant être installés (étape 430). Les modules logiciels étant ici codés dans des loads, l'authentification peut être réalisée de façon standard. En outre, comme décrit précédemment, une étape de vérification des contraintes de dépendances est, de préférence, conformément au second mode de réalisation décrit, effectuée après l'étape d'authentification des modules reçus (contrôle de l'intégrité des modules pour s'assurer de leur identification). Dans une étape suivante, les opérations élémentaires sont exécutées selon la séquence définie précédemment afin d'installer et/ou désinstaller les modules logiciels sélectionnés par l'opérateur (et éventuellement d'autres modules logiciels automatiquement sélectionnés selon les contraintes de dépendances). Comme illustré par la flèche en trait pointillé, le processus peut être répété pour traiter d'autres équipements et/ou modules logiciels. La figure 5 illustre un exemple de dispositif pouvant être utilisé pour mettre en oeuvre, au moins partiellement, l'invention, notamment des étapes décrites en référence aux figures 2, 3 et 4. Le dispositif 500 est par exemple un serveur, notamment un serveur de type ANSU. Le dispositif 500 comporte de préférence un bus de communication 502 auquel sont reliés : - une unité centrale de traitement ou microprocesseur 504 (CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ; - une mémoire morte 506 (ROM, acronyme de Read Only Memory en terminologie anglo-saxonne) pouvant comporter le système d'exploitation et des programmes tels que "Prog" ; - une mémoire vive ou mémoire cache 508 (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 ; - un lecteur 510 de support amovible de stockage 512 tel qu'une carte mémoire ou un disque, par exemple un disque DVD ; et - une carte graphique 514 reliée à un écran 516. Optionnellement, le dispositif 500 peut également disposer des éléments suivants : - un disque dur 520 pouvant comporter les programmes "Prog" précités et des données traitées ou à traiter selon l'invention ; - un clavier 522 et une souris 524 ou tout autre dispositif de pointage comme un crayon optique, un écran tactile ou une télécommande permettant à l'utilisateur d'interagir avec les programmes selon l'invention, en particulier pour sélectionner des équipements et des modules logiciels à installer et/ou désinstaller ; et - une interface de communication 526 reliée à un réseau de communication distribué 528, par exemple le réseau AFDX, l'interface étant apte à transmettre et à recevoir des données, notamment vers et en provenance d'un équipement d'un aéronef. 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 à l'appareil programmable de mettre en oeuvre les processus selon l'invention, peut être stocké, par exemple, dans le disque dur 520 ou en mémoire morte 506. Selon une variante, le code exécutable des programmes pourra être reçu par l'intermédiaire du réseau de communication 528, via l'interface 526, pour être stocké de façon identique à celle décrite précédemment. De manière plus générale, le ou les programmes pourront être 25 chargés dans un des moyens de stockage du dispositif 500 avant d'être exécutés. L'unité centrale 504 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 520 ou dans la 30 mémoire morte 506 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 520 ou la mémoire morte 506, sont transférés dans la mémoire vive 508 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.

10 15 20 25 23 ANNEXE // Contraintes génériques // Contraintes d'installation A~B, C B AC C~ D IE E~ // Contraintes de désinstallation A~ B OA C~ D ~ END // Contraintes de mise à jour B= // Contraintes équipement EQUIP AA // Contraintes d'installation EQUIP_AA : A B EQUIP_AA : B C EQUIP_AA : D E, C // Contraintes de désinstallation EQUIP_AA : B A, D EQUIP_AA : E D // Contraintes de mise à jour EQUIP AA : B, C = Annexe Al 30

Claims (6)

1. REVENDICATIONS1. Procédé pour ordinateur pour l'installation ou la désinstallation d'au moins un module logiciel dans au moins un équipement d'un système embarqué, selon au moins une contrainte de dépendance visant ledit au moins un module logiciel, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes, - réception (400) d'une liste de références de modules logiciels, ladite liste comprenant au moins une référence audit au moins un module logiciel ; - réception (405) d'au moins une commande, liée à ladite au moins une référence, d'installation ou désinstallation dudit au moins un module logiciel ; - accès (410) à ladite au moins une contrainte, l'accès à ladite au moins une contrainte étant indépendant de l'accès audit au moins un module ; et - évaluation (420) d'une séquence d'opérations élémentaires résolvant ladite au moins une contrainte pour appliquer ladite au moins une commande à ladite au moins une référence.
2. 2. Procédé selon la revendication 1 comprenant en outre, suite à l'exécution de ladite étape d'évaluation de ladite liste d'opérations élémentaires, une étape d'obtention (425) dudit au moins un module logiciel.
3. 3. Procédé selon la revendication 2 comprenant en outre une étape d'authentification (430) dudit au moins un module logiciel, ledit au moins un module logiciel étant codé dans une structure permettant son authentification.
4. 4. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape d'authentification (415) de ladite au moins une contrainte, ladite au moins une contrainte étant codée dans une structure permettant son authentification, lesdites structures de codage dudit au moins unmodule logiciel et de ladite au moins une contrainte étant distinctes et indépendantes.
5. 5. 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édentes lorsque ledit programme est exécuté sur un ordinateur.
6. 6. Dispositif pour l'installation ou la désinstallation d'au moins un module logiciel dans au moins un équipement d'un système embarqué, selon au moins une contrainte de dépendance visant ledit au moins un module logiciel, ce dispositif étant caractérisé en ce qu'il comprend les moyens suivants, - moyens de réception (225, 300) d'une liste de références de modules logiciels, ladite liste comprenant au moins une référence audit au moins un module logiciel, et d'au moins une commande, liée à ladite au moins une référence, d'installation ou désinstallation dudit au moins un module logiciel ; - moyens d'accès (240, 315) à ladite au moins une contrainte ; et - moyens d'évaluation (240, 315) d'une liste d'opérations élémentaires résolvant ladite au moins une contrainte pour appliquer ladite au moins une commande à ladite au moins une référence. 10. Dispositif selon la revendication 6 comprenant en outre des moyens d'obtention (235, 320) dudit au moins un module logiciel et de transmission dudit au moins un module logiciel audit au moins un équipement. 11. Système embarqué comprenant le dispositif selon la revendication 6 ou la revendication 7, ledit système embarqué comprenant au moins deux équipements connectés l'un à l'autre via un réseau de communication, ledit dispositif appartenant à l'un desdits au moins deux équipements pour permettre l'installation ou la désinstallation dudit au moins un module logiciel dans l'autre desdits au moins deux équipements. 9. Système embarqué comprenant le dispositif selon la revendication 6 ou la revendication 7, ledit système embarqué comprenant au moins deux équipements connectés l'un à l'autre via un réseau decommunication, lesdits moyens de réception appartenant à l'un desdits au moins deux équipements et lesdits moyens d'accès et d'évaluation appartenant à l'autre desdits au moins deux équipements pour permettre l'installation ou la désinstallation dudit au moins un module logiciel dans ledit autre desdits au moins deux équipements. 10. Aéronef comprenant le système embarqué selon la revendication 8 ou la revendication 9.