FR3003366A1 - Procede, dispositif et programme d'ordinateur pour l'installation ou la desinstallation automatique de modules logiciels dans des equipements embarques d'un aeronef - Google Patents

Abstract

L'invention concerne l'installation et la désinstallation automatique de modules logiciels dans des équipements embarqués d'un aéronef. Pour chaque référence d'une liste obtenue de références de modules logiciels à installer ou désinstaller, des règles de résolution liées à une opération associée au module logiciel considéré sont identifiées. Ces règles comprennent au moins une référence à une opération d'installation ou désinstallation d'au moins le module logiciel considéré et une liste d'actions à effectuer. Pour chaque référence de la liste obtenue de références, une liste de références d'opérations à réaliser est déterminée (315) en fonction de cette liste obtenue et des règles de résolution identifiées. Une liste d'actions à effectuer est ensuite déterminée (325) en fonction de la liste de références d'opérations à réaliser et des règles de résolution identifiées. Au moins une action référencée dans la liste d'actions à effectuer est ensuite exécutée (330) en faisant appel à un agent logiciel spécifique.

Description

La présente invention concerne la mise à jour de modules logiciels dans des équipements et plus particulièrement un procédé, un dispositif et un programme d'ordinateur pour l'installation ou la désinstallation automatique de modules logiciels dans des équipements embarqués d'un aéronef. 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. 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 20 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 25 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 30 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. En outre, l'utilisation de fonctions batch ne permet pas de résoudre toutes les contraintes, notamment des contraintes entre systèmes et des contraintes liées à des actions devant être effectuées avant ou après la mise à jour. Il existe donc un besoin, dans les systèmes embarqués, notamment les systèmes embarqués d'aéronefs, pour automatiser l'installation de mise à jour de modules logiciels et gérer les contraintes liées à ces installations, 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 précédemment. L'invention a ainsi pour objet un procédé pour ordinateur d'installation ou désinstallation d'au moins un module logiciel dans un équipement embarqué d'un système comprenant une pluralité d'équipements embarqués, au moins une opération étant associée audit au moins un module logiciel, ce procédé étant mis en oeuvre dans un équipement distinct dudit équipement dans lequel ledit au moins un module logiciel doit être installé ou désinstallé et comprenant les étapes suivantes, - obtention d'une liste d'au moins une référence de module logiciel à installer ou désinstaller ; - pour chaque référence de module logiciel de la liste obtenue, o identification de règles de résolution liées à une opération associée au module logiciel considéré, lesdites règles de résolution comprenant au moins une référence à une opération d'installation ou désinstallation d'au moins le module logiciel considéré dans un équipement embarqué dudit système et une liste comprenant au moins une référence d'une action à effectuer et o détermination d'une liste d'au moins une référence d'opération à réaliser en fonction de ladite liste obtenue et desdites règles de résolution identifiées ; - détermination d'une liste d'au moins une référence d'action à effectuer en fonction de ladite liste d'au moins une référence d'opération à réaliser et desdites règles de résolution identifiées ; et - exécution d'au moins une action référencée dans ladite liste d'au moins une référence d'action à effectuer déterminée, l'exécution de ladite au moins une action référencée faisant appel à un agent logiciel spécifique à un équipement distinct dudit équipement mettant en oeuvre ledit procédé. Le procédé selon l'invention permet ainsi d'homogénéiser les procédures d'installation et désinstallation de modules logiciels dans des équipements d'aéronefs. Il permet également l'exécution d'opérations sur l'environnement des équipements, en particulier avant, pendant et/ou après le chargement proprement dit. Il permet en outre de paralléliser des opérations pour gagner du temps. Selon un mode de réalisation particulier, le procédé comprend en outre une étape de vérification de la complétude de ladite liste obtenue d'au moins une référence de module logiciel à installer ou désinstaller en fonction desdites règles de résolution identifiées. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape d'identification d'au moins un module logiciel manquant nécessaire à l'installation ou la désinstallation dudit au moins un module logiciel, aucune référence audit au moins un module logiciel manquant ne figurant dans ladite liste obtenue d'au moins une référence de module logiciel à installer ou désinstaller, et une étape d'ajout d'une référence audit au moins un module logiciel manquant dans ladite liste obtenue d'au moins une référence de module logiciel à installer ou désinstaller. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de détermination d'une liste d'au moins une référence d'opération réalisable, ladite au moins une référence d'opération réalisable appartenant à ladite liste d'au moins une référence d'opération à réaliser. Selon un mode de réalisation particulier, le procédé comprend en outre une étape de détermination d'une liste d'au moins une référence d'opération à réaliser après que toutes les opérations dont une référence appartient à ladite liste d'au moins une référence d'opération à réaliser aient été réalisées. Toujours selon un mode de réalisation particulier, le procédé 10 comprend en outre une étape de génération d'une synthèse des opérations dont une référence appartient à ladite liste d'au moins une référence d'opération à réaliser ont été réalisées. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de validation par un utilisateur. 15 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 de ce procédé et un aéronef comprenant ce 20 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, 25 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 illustre schématiquement un exemple d'architecture d'un système permettant le téléchargement de modules logiciels dans des 30 équipements d'un aéronef selon un mode de réalisation particulier ; - la figure 3 illustre schématiquement une séquence d'étapes mise en oeuvre selon un mode de réalisation particulier pour réaliser une opération de téléchargement de modules logiciels dans des équipements ; et - la figure 4 illustre un exemple de dispositif de traitement d'informations adapté à mettre en oeuvre, au moins partiellement, un mode de réalisation. De façon générale, l'invention a pour objet, selon un mode de réalisation particulier, un système centralisé de chargement permettant, avant d'effectuer un chargement, de vérifier des conditions initiales requises, proposer à un opérateur des opérations devant être effectuées avant et/ou après un chargement, réaliser ces actions automatiquement (après ou sans confirmation d'un opérateur selon la configuration), en utilisant des agents agissant sur des équipements tiers (en l'absence d'agent, le système de chargement peut indiquer au moment opportun les instructions nécessaires à un opérateur pour qu'il réalise l'action) et résoudre des contraintes de chargement de modules logiciels en indiquant à un opérateur, le cas échéant, les modules logiciels manquants. La figure 2 illustre schématiquement un exemple d'architecture d'un système permettant le téléchargement de modules logiciels dans des équipements d'un aéronef selon un mode de réalisation particulier. Le système de traitement de l'information 200 d'un aéronef (non représenté) comprend ici un système de chargement centralisé SCC 205 et des équipements 210-1 à 210-n dans lesquels peuvent être téléchargés des modules logiciels.

Selon l'exemple illustré sur la figure 2, le système de chargement centralisé 205 comprend un module de gestion 215 auquel est associée une interface homme-machine 220, un moteur de résolution 225, une base de données 230 de règles de résolution et un module d'exécution d'actions 235 qui comprend lui-même des agents 240-1 à 240-n spécifiques aux équipements de l'aéronef comprenant le système de traitement de l'information 200.

Le module de gestion 215 est relié au moteur de résolution 225 qui est lui-même relié à la base de données 230 de règles de résolution et au module d'exécution d'actions 235. Toujours selon cet exemple, chaque équipement génériquement référencé 245 comprend un module de chargement, ici les modules 245-1 et 245-n, des modules permettant d'effectuer des actions particulières (par exemple l'arrêt ou la réinitialisation de l'équipement, le téléchargement d'un module logiciel ou la désinstallation d'un module logiciel), ici les modules 25011 à 250-1p et 250-n1 à 250-nq, et des modules permettant de mettre en oeuvre des fonctions propres à l'équipement, ici les modules 255-1 et 255-n. Le module de gestion 215 est, via l'interface 220, de préférence graphique, un point d'entrée pour l'utilisateur, lui permettant notamment de sélectionner une liste de modules logiciels (loads) à télécharger sur des équipements d'un aéronef. Il pilote le moteur de résolution 225 et informe l'utilisateur de l'avancement des opérations, en particulier en lui soumettant des messages de confirmation et en lui proposant une liste des modules logiciels manquants lorsque nécessaire. Des règles de résolutions, mémorisées dans la base de données 230, sont avantageusement définies pour chaque opération, une opération ayant pour objet, par exemple, le téléchargement d'un module logiciel dans un équipement ou la désinstallation d'un module logiciel dans un équipement. Les règles de résolutions sont typiquement définies par : - une liste d'opérations à réaliser avant d'effectuer les actions définies par l'opération visée, intitulée, par exemple, « opérations à réaliser avant ». Ainsi, à titre d'illustration, si, pour réaliser l'opération « télécharger le module logiciel B », il faut, au préalable, télécharger le module logiciel A, l'opération « télécharger le module logiciel B» aura, dans sa liste « opérations à réaliser avant », la désignation de l'opération « télécharger le module logiciel B » , - une liste d'actions à effectuer (« liste des actions »). Elles peuvent être de tous types et concerner, notamment, des équipements et des interrogations d'un utilisateur. Ainsi, par exemple, une première action peut consister à demander une confirmation à un utilisateur que l'équipement X peut être atteint tandis qu'une seconde action a pour objet d'éteindre l'équipement X et qu'une troisième action vise l'installation d'un module logiciel A sur un équipement Y; - une liste d'opérations à réaliser après avoir effectué les actions définies par l'opération visée, intitulée, par exemple, « opérations à réaliser après ». Selon un mode de réalisation particulier, ces opérations sont à faire au moins une fois mais n'ont pas de contrainte temporelle et peuvent être mutualisées. A titre d'illustration, si l'opération « installer le module logiciel A sur l'équipement X» nécessite, après avoir été réalisée, la réalisation de l'opération « réinitialisation de l'équipement X », tout comme l'opération « installer le module logiciel B sur l'équipement X », l'opération « réinitialisation de l'équipement Y» est réalisée dès lors que l'installation du module logiciel A ou B est terminée ; et, - une liste de conditions et contraintes (« liste des conditions et contraintes »). Elle peut notamment comprendre la contrainte notée, par exemple, « skip/condition [X] » selon laquelle l'opération n'est pas effectuée si l'expression [X] n'est pas vérifiée. La liste peut également comporter une indication de type « non parallèle » précisant que les actions de la liste d'actions de l'opération ne peuvent pas être effectuées parallèlement à celles d'autres opérations car leurs exécutions peuvent les perturber. Ainsi, par exemple, les actions visant l'opération « éteindre l'alimentation de l'aéronef » imposent de ne pas effectuer d'opérations sur d'autres équipements de l'aéronef.

Un exemple de règles de résolution d'une opération est donné à titre d'illustration en annexe (table 1). Cet exemple concerne une opération de téléchargement d'un module A sur un équipement X. La liste des opérations devant être réalisées avant d'effectuer les actions définies par l'opération visée comprend ici uniquement l'opération consistant à désinstaller le module logiciel B de l'équipement X. Les actions de l'opération de téléchargement du module A sur l'équipement X comprennent une demande de confirmation à l'utilisateur d'ouvrir un relai Z, 3003 366 10 d'ouvrir ce relai si la confirmation est donnée, d'installer le module logiciel A sur l'équipement X et de fermer le relais Z. La liste des opérations devant être réalisées après avoir effectué les actions définies par l'opération visée comprend ici uniquement l'opération de réinitialisation de l'aéronef dans lequel 5 est effectué le téléchargement. Comme indiqué dans la liste de conditions et de contraintes, l'opération de téléchargement d'un module A sur un équipement X n'est effectuée que si le module A n'est pas déjà installé sur l'équipement X. En outre, cette opération ne peut pas être effectuée parallèlement à une autre. Selon un mode de réalisation particulier, les règles de résolution de 10 chaque module logiciel, c'est-à-dire l'ensemble de la description correspondante, est fournie dans ou avec le module logiciel lors de son téléchargement par le système de chargement centralisé. Ainsi, par exemple, comme illustré en annexe, table 2, les règles de résolution figurant dans la table 1 peuvent être associées à un module logiciel 15 X_IoadA, associé à un équipement X. Ce module logiciel comprend une application logicielle à charger dans un équipement cible, ici l'équipement X, ainsi que des descripteurs d'opérations, ici les descripteurs « télécharger module logiciel A que équipement B» et « désinstaller module logiciel A d'équipement B ». Ces descripteurs permettent d'appeler des règles de 20 résolution (e.g. le descripteur « télécharger module logiciel A que équipement B» permet d'appeler les règles de description portant le même nom). Le moteur de résolution 225 obtient de la base de données 230 les règles de résolution applicables aux modules logiciels sélectionnés par l'utilisateur. Il vérifie, en particulier, la complétude de la liste fournie par 25 l'utilisateur en fonction des règles de résolution, en particulier des opérations devant être réalisées avant ou après la réalisation des opérations de téléchargement des modules logiciels sélectionnés par l'utilisateur, et des opérations dépendantes définies dans les modules logiciels. La liste des modules logiciels manquants est transmise à l'utilisateur. 30 Toujours à partir des règles de résolution, il calcul ensuite la liste des actions élémentaires à effectuer, vérifie la disponibilité des agents nécessaires pour effectuer ces actions et cadence leur soumission au module d'exécution d'actions 235 en fonction de leur éligibilité (en particulier la réalisation de préconditions et la vérification de conditions de type skip/condition). Le moteur de résolution 225 supervise l'avancement de l'exécution des actions et en informe le module de gestion 215.

Le module d'exécution d'actions 235 pilote les équipements en charge d'exécuter les actions demandées via des agents dédiés 240-1 à 240-n. Chaque agent utilise ici un protocole propre avec le module distant de l'équipement concerné. L'avancement et le statut des actions effectuées sont signalés au moteur de résolution.

Ainsi, conformément au mode de réalisation décrit précédemment, des règles de résolution sont définies pour chaque opération pouvant être effectuée. De telles règles sont, par exemple, définies par les équipementiers en charge du développement des modules logiciels correspondants. Selon un autre mode de réalisation, certaines règles de résolution sont définies de façon générique. Il est ainsi possible de préconfigurer le système de chargement centralisé avec des règles de résolution génériques, ou canevas, pouvant être utilisé pour des opérations différentes de même nature, telles que le chargement ou la désinstallation d'un module logiciel dans un équipement. Il n'est ainsi pas nécessaire de réécrire des règles de résolution similaires pour des opérations similaires. A titre d'illustration, il est possible de mettre en oeuvre des règles de résolution générique pour le chargement d'un module logiciel identifié par un numéro de type PN (sigle de Part Number en terminologie anglo-saxonne) dans un équipement identifié par un code invariant, appelé FIN (sigle de Functional Item Number en terminologie anglo-saxonne). Lorsqu'il est fait appel à de telles règles, il convient de préciser les paramètres auxquels elles s'appliquent, ici la désignation du module logiciel et de la cible ainsi que, le cas échéant, les dépendances. Selon un mode de réalisation particulier, le moteur de résolution 225 gère plusieurs listes parmi lesquelles les listes suivantes : - la « liste à faire » qui contient l'ensemble des opérations à réaliser ; - la « liste faisable » qui contient l'ensemble des opérations à réaliser dont les dépendances sont vérifiées ; - la « liste après » qui comprend l'ensemble des opérations à réaliser ultérieurement lorsque les listes « liste à faire » et « liste faisable » sont vides ; et - la « liste fait » qui comprend toutes les opérations déjà réalisées. Comme décrit précédemment, le moteur de résolution commande les actions à réaliser au module d'exécution d'actions et, lorsque ces actions sont réalisées, met à jour les listes correspondantes.

La figure 3 illustre schématiquement une séquence d'étapes mise en oeuvre selon un mode de réalisation particulier pour réaliser une opération de téléchargement de modules logiciels dans des équipements. Comme illustré, une première étape (étape 300) a pour objet l'acquisition et la validation d'une liste de modules logiciels à installer, au moins un identifiant d'équipement dans lequel doit être installé un module logiciel étant associé à chacun de ces modules logiciels. Une telle étape est ici mise en oeuvre dans le module de gestion 215 et fait intervenir un utilisateur via l'interface 220. La liste de modules logiciels est alors transmise au moteur de résolution 225 qui en vérifie la complétude (étape 305) et, le cas échéant, détermine les modules logiciels manquants à partir des informations contenues dans les modules logiciels eux-mêmes et des règles de résolution contenues dans la base de données 230. S'il manque des modules logiciels dans la liste, le moteur de résolution 225 adresse un message comprenant, de préférence, une liste de modules logiciels manquants et nécessaires, au module de gestion 215. Ce dernier peut alors interroger un utilisateur, via l'interface 220, pour obtenir une confirmation de l'ajout des modules logiciels manquants à la liste des modules logiciels à télécharger établie par un utilisateur (étape 310).

A partir de la liste des modules logiciels à télécharger établie par un utilisateur, complétée, le cas échéant, suite à une vérification de complétude, des listes d'opérations à réaliser sont établies par le moteur de résolution 225 (étape 315). Comme décrit précédemment, ces listes sont établies en fonction des modules logiciels à télécharger et des règles de résolution. Elles comprennent typiquement une liste d'opérations à faire et une liste d'opérations à faire après.

La liste des opérations pouvant être réalisées est ensuite déterminée (étape 320). Cette liste est établie à partir de la liste des opérations à faire et des règles de résolution. Les opérations pouvant être réalisées sont alors décomposées en actions pouvant être exécutées de façon parallèle ou non selon les indications des règles de résolution (étape 325). L'exécution de ces actions, contrôlée par le moteur de résolution 225, est effectuée par le module d'exécution d'actions 235, par des agents spécifiques aux équipements visés. Ainsi, le module d'exécution d'actions 235 pilote, via ses agents, la réalisation des actions sur les différents équipements.

Les résultats d'exécution d'actions sont transmis par le module d'exécution d'actions 235 au moteur de résolution 225 (étape 335) qui met à jour la liste d'opérations à réaliser, la liste d'opérations réalisables et une liste d'opérations réalisées. Les listes d'opérations à réaliser et réalisables sont notamment mises à jour selon les opérations réalisées et les opérations à réaliser après. Un test est alors effectué pour déterminer si les listes d'opérations à réaliser et à réaliser après sont vides (étape 340). Dans la négative, les étapes précédentes sont répétées comme représenté. Dans le cas contraire, le module de gestion 215 fait une synthèse des opérations réalisées qui est, de préférence, mémorisée et adressée à un utilisateur (étape 345). Lors de la vérification de la complétude de la liste des opérations à réaliser, l'état de ces opérations et des actions qu'elles mettent en oeuvre est avantageusement vérifié. Selon un mode de réalisation particulier, les états possibles d'une opération dans le système de chargement centralisé sont les suivants : - opération inconnue : le descripteur de l'opération n'est disponible ni dans une zone de stockage appelée repository contenant les modules logiciels installés dans l'aéronef (qui peut être utilisée par le système de chargement centralisé pour mettre à jour des équipements) ni sur un media tel qu'un CD-ROM (acronyme de Compact Disc - Read Only Memory en terminologie anglo-saxonne) ou un DVD (acronyme de Digital Versatile Disc en terminologie anglo-saxonne) ; - opération disponible : le descripteur de l'opération est disponible dans le repository ou sur un média ; - opération faisable : l'opération est disponible, les opérations à faire avant et après sont faisables et les actions de la liste d'actions correspondantes sont faisables (chaque action de la liste est faisable) ; - opération réalisable : l'opération est faisable, les opérations à faire avant sont réalisées et les actions de la liste d'actions correspondantes sont réalisables : - opération réalisée : les actions de la liste d'actions correspondantes ont été effectuées ou une condition de type « skip/condition » est vérifiée ; et - opération finalisée : l'opération a été réalisée et les opérations à réaliser après sont réalisées. Toujours selon un mode de réalisation particulier, les états possibles d'une action dans le système de chargement centralisé sont les suivants : - action inconnue : le descripteur de l'agent pour l'action n'est pas disponible dans le repository ou sur le media ; - action disponible : le descripteur de l'agent pour l'action est disponible dans le repository ou sur le media ; - action faisable : l'action est disponible et l'opération pour installer l'agent correspondant, permettant l'exécution de l'action, est faisable ; et - action réalisable (une action réalisable implique qu'elle est faisable) : l'agent permettant l'exécution de l'action est installé dans le système de chargement centralisé.

A titre d'illustration, il est admis ici qu'un utilisateur ait pour mission de mettre à jour deux équipements El et E2 embarqués d'un aéronef en téléchargeant des modules logiciels (modules logiciels El_loadA et El_loadB sur l'équipement El et module logiciel E2_loadC sur l'équipement E2). Il est également admis qu'une telle mise à jour nécessite une action préalable pour configurer un équipement E3 dans un mode de maintenance, 5 puis une action pour reconfigurer cet équipement dans un mode normal d'utilisation et une action finale de réinitialisation du système. L'action de configuration en mode de maintenance de l'équipement E3, réalisée par un module logiciel E3_loadD, doit être réalisée avant toute installation effectuée sur l'équipement E2. De façon similaire, l'action de 10 configuration en mode normal de l'équipement E3, également réalisée par le module logiciel E3_loadD, doit être réalisée après toute intervention de maintenance effectuée sur l'équipement E2. Pour que l'action de configuration de l'équipement E3 soit disponible, il est nécessaire qu'un agent permettant d'interfacer un équipement soit installé 15 dans le système de chargement centralisé. Un tel agent est ici contenu dans un module logiciel SCC_IoadE. Il est également nécessaire qu'un module correspondant, ici contenu dans le module logiciel E3_loadD, soit installé dans l'équipement E3. Par conséquent, le module logiciel El_loadA doit être installé après les modules logiciels SCC_IoadE, E3_load D. 20 L'action finale de réinitialisation du système est ici contenue dans le module logiciel E4_loadF devant être installé dans un équipement E4. A nouveau, pour que cette action soit disponible, il est nécessaire qu'un agent permettant d'interfacer un équipement (contenu ici dans le module logiciel SCC_IoadE) soit installé dans le système de chargement centralisé. Il est 25 également nécessaire qu'un module correspondant, ici contenu dans le module logiciel E4_loadF, soit installé dans l'équipement E4. Par ailleurs, il est considéré que le module logiciel El_loadA doit être installé avant le module logiciel El _loadB et que ce dernier doit être désinstallé avant le module logiciel El_loadA. 30 La table 3 donnée en annexe illustre un exemple de module logiciel El_loadA. Comme représenté, le module logiciel El_loadA est associé à un équipement cible particulier (El) ) et comprend deux descripteurs, l'un d'installation (opération installation El_loadA) et l'autre de désinstallation (opération désinstallation El_loadA), ainsi que l'application logicielle. Des tables similaires peuvent représenter les modules logiciels El_loadB, E2_loadC, E3_loadD et E4_loadF, respectivement. Deux descripteurs, l'un d'installation et l'autre de désinstallation, peuvent être associés à chacun de ces modules logiciels. La table 4 donnée en annexe illustre un exemple de module logiciel SCC_IoadE. Comme illustré, il comprend des descripteurs d'opérations mais également des descripteurs d'agents, notamment des agents de configuration et de réinitialisation permettant d'interfacer des équipements (ici les équipements E3 et E4), ainsi que le code logiciel correspondant à ces agents. Les tables 5a et 5b données en annexe illustrent un exemple de règles de résolution des opérations d'installation et de désinstallation associées au module logiciel El_loadA, respectivement. Des tables similaires peuvent être utilisées pour représenter les règles de résolution des opérations d'installation et de désinstallation associées aux modules logiciels El_loadB, E2_loadC, E3_loadD et E4_loadF. Les tables 6a, 6b et 6c données en annexe illustrent un exemple de règles de résolution des opérations de réinitialisation, d'installation et de désinstallation associées au module logiciel SCC_IoadE, respectivement. Lorsque l'utilisateur souhaite mettre à jour les équipements El et E2, le logiciel opérationnel du système de chargement centralisé (SCC) est installé, rendant ainsi disponible les actions d'installation de modules logiciels (notée SCC_install), de désinstallation de modules logiciels (notée SCC_desinstall) et des actions d'interaction avec un utilisateur. Le module logiciel correspondant est ici disponible dans le repository. Aucun autre module logiciel n'est disponible dans le repository et par conséquent le SCC ne propose aucune opération supplémentaire. Pour mettre à jour les équipements El et E2, l'utilisateur dispose ici d'un DVD qui contient les modules logiciels suivants : - El_loadA; - El_loadB; - E2_loadC; - E3_loadD; - SCC_IoadE; et - E4_loadF.

Lorsque l'utilisateur insère son DVD dans le lecteur, le moteur de résolution lit son contenu pour, en particulier, déterminer les opérations et actions disponibles à partir de celui-ci. Selon cet exemple, les opérations suivantes (définies dans les modules logiciels) sont disponibles : - installation El_loadA, installation El_loadB, installation E2_loadC, installation E3_loadD, installation SCC_IoadE et installation E4_I oad F ; - désinstallation El_loadA, désinstallation El_loadB, désinstallation E2_LoadC, désinstallation E3_loadD, désinstallation SCC_IoadE et désinstallation E4_LoadF ; et - réinitialisation de l'aéronef. De même, les actions suivantes (définies dans les modules logiciels) sont disponibles : - actions disponibles : - action de configuration ; - action de réinitialisation ; et - actions d'interaction avec l'utilisateur ; - actions faisables : - SCC_Install ; et - SCC_Desinstall. Les étapes mises en oeuvre pour mettre à jour les équipements El et E2 sont alors conformes à celles décrites en référence à la figure 3. Tout d'abord, la liste des modules logiciels à télécharger est obtenue par le module de gestion. Conformément au scénario de l'exemple visé ici, un utilisateur sélectionne les modules logiciels suivants : El_loadA, El_loadB et E2_loadC.

Le module de gestion communique ensuite cette liste au moteur de résolution afin qu'il vérifie la complétude de la liste et détermine les modules logiciels manquants et la faisabilité des opérations à réaliser. Au cours de cette analyse, le moteur de résolution détermine que les 5 modules logiciels SCC_IoadE et E3_loadD sont manquants. Cette analyse peut être résumée comme représenté dans la table 7 donnée en annexe. Dans une étape suivante, le moteur de résolution communique au module de gestion la liste des modules logiciels manquants, c'est-à-dire, ici, une liste comprenant les modules logiciels SCC_IoadE et E3_loadD. Le module 10 de gestion propose cette liste à l'utilisateur qui met alors à jour la liste des modules logiciels à installer. Cette liste comprend alors les modules logiciels suivants : E1_loadA, E1_loadB, E2_loadC, SCC_IoadE et E3_LoadD. Le moteur de résolution vérifie ensuite cette nouvelle liste qui est alors complète et faisable comme il résulte de l'analyse présentée dans la table 15 7 puis calcul la liste des opérations à réaliser et des opérations à réaliser après. La liste des opérations à réaliser comprend ici les opérations suivantes : installation E1_loadA, installation E1_loadB, installation E2_loadC, installation SCC_IoadE et installation E3_loadD. La liste des opérations à réaliser après ne comprend que la réinitialisation de l'aéronef. 20 Le moteur de résolution détermine ensuite les opérations réalisables en vérifiant que les opérations à faire avant sont réalisées et que la liste des actions est réalisable. La table 8 donnée en annexe cette étape. Toutes les opérations sont exécutées sous le contrôle du moteur de résolution qui exécuté ensuite l'opération de réinitialisation de l'aéronef. 25 La figure 4 illustre un exemple de dispositif pouvant être utilisé pour mettre en oeuvre, au moins partiellement, un mode de réalisation, notamment des étapes décrites en référence aux figures 2 et 3. Le dispositif 400 est par exemple un serveur. Le dispositif 400 comporte de préférence un bus de communication 30 402 auquel sont reliés : - une unité centrale de traitement ou microprocesseur 404 (CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ; - une mémoire morte 406 (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 408 (RAM, acronyme de 5 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 410 de support amovible de stockage 412 tel qu'une carte mémoire ou un disque, par exemple un disque DVD ; et 10 - une carte graphique 414 reliée à un écran 416. Optionnellement, le dispositif 400 peut également disposer des éléments suivants : - un disque dur 420 pouvant comporter les programmes "Prog" précités et des données traitées ou à traiter selon l'invention ; 15 - un clavier 422 et une souris 424 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 20 - une interface de communication 426 reliée à un réseau de communication distribué 428, 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 25 l'interopérabilité entre les différents éléments inclus dans le dispositif 400 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 400 directement ou par l'intermédiaire d'un autre élément du dispositif 400. 30 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 420 ou en mémoire morte 406.

Selon une variante, le code exécutable des programmes pourra être reçu par l'intermédiaire du réseau de communication 428, via l'interface 426, 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 5 chargés dans un des moyens de stockage du dispositif 400 avant d'être exécutés. L'unité centrale 404 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 420 ou dans la 10 mémoire morte 406 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 420 ou la mémoire morte 406, sont transférés dans la mémoire vive 408 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour 15 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. La présente invention ne se limite pas aux 20 formes de réalisation décrites, d'autres variantes et combinaisons de caractéristiques sont possibles. La présente invention a été décrite et illustrée dans la présente description détaillée en référence aux figures jointes. Toutefois, la présente invention ne se limite pas aux formes de réalisation présentées. D'autres 25 variantes et modes de réalisation peuvent être déduits et mis en oeuvre par la personne compétente dans le domaine de l'invention à la lecture de la présente description et des figures annexées. Dans les revendications, le terme « comporter » n'exclut pas d'autres éléments ou d'autres étapes. L'article indéfini « un » n'exclut pas le pluriel. Un 30 seul processeur ou plusieurs autres unités peuvent être utilisées pour mettre en oeuvre l'invention. Les différentes caractéristiques présentées et/ou revendiquées peuvent être avantageusement combinées. Leur présence dans la description ou dans des revendications dépendantes différentes n'exclut pas, en effet, la possibilité de les combiner. Les signes de référence ne sauraient être compris comme limitant la portée de l'invention.

ANNEXE Opération : télécharger module logiciel A sur équipement X Opérations à réaliser avant : désinstaller module logiciel B d'équipement X Liste des actions : confirmation utilisateur ouvrir le relais Z? ouvrir relais Z installer module logiciel A sur équipement X fermer le relais Z Opérations à réaliser après : ré initialiser aéronef Liste de conditions et contraintes : skip/condition module logiciel A installé sur l'équipement X non parallèle 20 Table 1 : exemple de règles de résolution d'une opération Module logiciel : X loadA Cible : X Descripteur d'opération: télécharger module logiciel A sur équipement X désinstaller module logiciel A d'équipement X Application logicielle Table 2 : exemple de module logiciel Module logiciel : El loadA Cible : El Descripteur d'opération: opération installation El loadA opération désinstallation El loadA 10 15 25 30 35 15 25 30 Application logicielle Table 3 : module logiciel El loadA Module logiciel : SCC loadE Cible : SOC Descripteur d'opération: opération réinitialisation aéronef opération installation SCC loadE opération désinstallation SCC loadE Descripteur d'adent: agent de configuration agent de réinitialisation Application logicielle agent de configuration Application logicielle agent de réinitialisation Table 4 : module logiciel SOC loadE Opération : opération installation El loadA Opérations à réaliser avant : néant Liste des actions : action confirmation utilisateur configuration mode maintenance E4? action mode maintenance E4 action SCC install El loadA sur El action confirmation utilisateur configuration mode normal E4? action mode normal E4 Opérations à réaliser après : opération réinitialiser aéronef Liste de conditions et contraintes : skip/condition module logiciel El loadA installé sur El non parallèle Table 5a : règles de résolution de l'opération installation El loadA 20 35 40 Opération : opération désinstallation El loadA Opérations à réaliser avant : opération désinstallation El loadB Liste des actions : action confirmation utilisateur configuration mode maintenance E4? action mode maintenance E4 action SCC désinstall El loadA sur El action confirmation utilisateur configuration mode normal E4 ? action mode normal E4 Opérations à réaliser après : néant Liste de conditions et contraintes : skip/condition module logiciel El loadA non installé sur El non parallèle Table 5b : règles de résolution de l'opération désinstallation El loadA Opération : opération réinitialisation aéronef Opérations à réaliser avant : néant Liste des actions : action confirmation utilisateur réinitialisation aéronef ? action réinitialisation Opérations à réaliser après : néant Liste de conditions et contraintes : skip/condition NA non parallèle Table 6a : règles de résolution de l'opération réinitialisation aéronef Opération : opération installation SCC loadE Opérations à réaliser avant : opération installation E3 loadD Liste des actions : action SCC install SCC loadE sur SCC Opérations à réaliser après : néant Liste de conditions et contraintes : skip/condition module logiciel SCC loadE installé sur SCC parallèle supporté Table 6b : règles de résolution de l'opération installation SCC loadE Opération : opération désinstallation SCC loadE Opérations à réaliser avant : néant Liste des actions : action SCC désinstall SCC loadE sur SCC Opérations à réaliser après : néant Liste de conditions et contraintes : skip/condition module logiciel SCC loadE non installé sur SCC parallèle supporté Table 6c : règles de résolution de l'opération désinstallation SCC loadE Décisions prises par le moteur de résolution Description de la Résolution Opération à réaliser : opération installation El loadA 1. Opération installation El_loadA est-elle faisable ? Opération est-elle disponible ? OUI Opérations à faire avant sont-elles faisables ? NA La liste des actions est-elle faisable ? Action de confirmation utilisateur est-elle faisable ? OUI Action de configuration est-elle faisable ? voir décision numéro 2 + OUI * Action SCC install est-elle faisable ? OUI Opérations à faire après sont-elles faisables ? Réinitialisation aéronef est-elle faisable voir décision numéro 5 + OUI Opération installation El_LoadA est faisable * 2. Action de configuration est- elle faisable ? Action de configuration est-elle disponible ? OUI L'opération pour installer l'agent est-elle faisable ? Installer le module logiciel contenant l'agent de l'action de configuration (=load SCC loadE) Mettre à jour la liste des modules logiciels manquants, comprenant SCC_IoadE Vérifier que l'opération installation SCC loadE est faisable ? voir décision numéro 3 + OUI * Action A est faisable 3. Opération installation SCC_LoadE est-elle faisable ? Opération est-elle disponible ? OUI Opérations à faire avant sont-elles faisables ? Opération installation E3 loadD est-elle faisable ? voir décision numéro 4 + OUI Mettre à jour la liste des modules logiciels manquants, comprenant SCC loadE et E3_loadD La liste des actions est-elle faisable ? Action SCC install est faisable Opérations à faire après sont-elles faisables ? NA Opération installation SCC_IoadE est faisable 4. Opération installation E3_LoadD est-elle faisable ? Opération est-elle disponible ? OUI Opérations à faire avant sont-elles faisables ? NA La liste des actions est-elle faisable ? Action SCC install est faisable Opérations à faire après sont-elles faisables ? NA Opération installation E3_loadD est faisable 5. Opération de réinitialisation de l'aéronef est-elle faisable ? Opération est-elle disponible ? OUI Opérations à faire avant sont-elles faisables ? NA La liste des actions est-elle faisable ? Action de réinitialisation est-elle faisable ? voir décision numéro 6 + OUI * Opérations à faire après sont-elles faisables ? NA Opération réinitialisation de l'aéronef est faisable 6. Action de réinitialisation est- Action B est-elle disponible ? OUI elle faisable ? L'opération pour installer l'agent est-elle faisable ? Installer le module logiciel contenant l'agent de l'action de réinitialisation (=load SCC loadE) La liste des modules logiciels manquants contient Load SCC loadE Vérifier que l'opération installation SCC loadE est faisable ? voir décision numéro 3 + OUI Action de réinitialisation est faisable Opération à réaliser : Opération installation El LoadB 7. Opération installation El_LoadB est-elle faisable ? Opération est-elle disponible ? OUI Opérations à faire avant sont-elles faisables ? Installation El loadA est-elle faisable ? voir décision numéro 1 + OUI La liste des actions est-elle faisable ? Action SCC install est-elle faisable ? OUI Opérations à faire après sont-elles faisables ? Réinitialisation aéronef est-elle faisable ? voir décision numéro 5 + OUI Opération installation El_loadB est faisable Opération à réaliser : Opération installation E2 loadC 8. Opération installation E2 JoadC est-elle faisable ? Opération est-elle disponible ? OUI Opérations à faire avant sont-elles faisables ? NA La liste des actions est-elle faisable ? Action SCC install est-elle faisable ? OUI Opérations à faire après sont-elles faisables ? NA Opération installation E2_loadC est faisable La faisabilité de l'opération prend pour hypothèse que l'utilisateur sélectionne la liste des modules logiciels manquants demandée par le système de chargement centralisé. Table 7 : exemple d'analyse de la faisabilité d'opérations à effectuer Opérations à faire Opérations à faire Opérations Commentaires et réalisables mais non réalisable réalisées installation El loadA Aucune Etat initial installation El loadB installation E2 loadC installation SCC loadE installation E3 loadD Evaluation des opérations réalisables installation E2 loadC installation El loadA E2 loadC et installation E3 loadD installation El loadB E3 loadD peuvent être installés, pour les autres des opérations à faire avant ou des actions ne sont pas disponibles installation SCC loadE Réalisation des actions installation El loadA installation E2 loadC E2 loadC et installation El loadB installation E3 loadD E3 loadD ont été installé en parallèle installation SCC loadE Evaluation des opérations réalisables installation SCC loadE installation El loadA installation E2 loadC L'installation de SCC loadE devient réalisable car installation El loadB installation E3 loadD E3 loadD a été installé Réalisation des actions installation El loadA installation E2 loadC installation E3 loadD installation SCC loadE a été installé installation El loadB SCC loadE Evaluation des opérations réalisables installation El loadA installation El loadB installation E2 loadC L'action de configuration est disponible suite à l'installation de SCC loadE, donc installation E3 loadD El loadA peut être installation SCC loadE installé Réalisation des actions installation El loadA installation E2 loadC installation E3 loadD installation SCC loadE installation El loadA a été installation El loadB El loadA installé.

Evaluation des opérations réalisables installation El loadB installation E2 loadC L'installation de installation E3 loadD El loadB devient installation SCC loadE installation réalisable car El loadA El load A a été installé Réalisation des actions installation E2 loadC El loadB a été installation E3 loadD installé installation SCC loadE Condition d'arrêt atteinte car la liste à faire et réalisable est vide installation El loadA installation El loadB Lors de l'opération installation El loadA, les actions de configuration qui nécessitent une confirmation de l'opérateur doivent être réalisées. Table 8 : détermination des opérations réalisables5

Claims (10)

1. REVENDICATIONS1. Procédé pour ordinateur d'installation ou désinstallation d'au moins un module logiciel dans un équipement embarqué d'un système comprenant une pluralité d'équipements embarqués, au moins une opération étant associée audit au moins un module logiciel, ce procédé étant caractérisé en ce qu'il est mis en oeuvre dans un équipement distinct dudit équipement dans lequel ledit au moins un module logiciel doit être installé ou désinstallé et en ce qu'il comprend les étapes suivantes, - obtention (300) d'une liste d'au moins une référence de module logiciel à installer ou désinstaller ; - pour chaque référence de module logiciel de la liste obtenue, o identification de règles de résolution liées à une opération associée au module logiciel considéré, lesdites règles de résolution comprenant au moins une référence à une opération d'installation ou désinstallation d'au moins le module logiciel considéré dans un équipement embarqué dudit système et une liste comprenant au moins une référence d'une action à effectuer et o détermination (315) d'une liste d'au moins une référence d'opération à réaliser en fonction de ladite liste obtenue et desdites règles de résolution identifiées ; - détermination (325) d'une liste d'au moins une référence d'action à effectuer en fonction de ladite liste d'au moins une référence d'opération à réaliser et desdites règles de résolution identifiées ; et - exécution (330) d'au moins une action référencée dans ladite liste d'au moins une référence d'action à effectuer déterminée, l'exécution de ladite au moins une action référencée faisant appel à un agent logiciel spécifique à un équipement distinct dudit équipement mettant en oeuvre ledit procédé.
2. 2. Procédé selon la revendication 1 comprenant en outre une étape de vérification (305) de la complétude de ladite liste obtenue d'au moins uneréférence de module logiciel à installer ou désinstaller en fonction desdites règles de résolution identifiées.
3. 3. Procédé selon la revendication 2 comprenant en outre une étape d'identification d'au moins un module logiciel manquant nécessaire à l'installation ou la désinstallation dudit au moins un module logiciel, aucune référence audit au moins un module logiciel manquant ne figurant dans ladite liste obtenue d'au moins une référence de module logiciel à installer ou désinstaller, et une étape d'ajout (310) d'une référence audit au moins un module logiciel manquant dans ladite liste obtenue d'au moins une référence de module logiciel à installer ou désinstaller.
4. 4. Procédé selon l'une quelconque des revendications 1 à 3 comprenant en outre une étape de détermination d'une liste d'au moins une référence d'opération réalisable, ladite au moins une référence d'opération réalisable appartenant à ladite liste d'au moins une référence d'opération à réaliser.
5. 5. Procédé selon l'une quelconque des revendications 1 à 4 comprenant en outre une étape de détermination d'une liste d'au moins une référence d'opération à réaliser après que toutes les opérations dont une référence appartient à ladite liste d'au moins une référence d'opération à réaliser aient été réalisées.
6. 6. Procédé selon l'une quelconque des revendications 1 à 5 comprenant en outre une étape de génération (345) d'une synthèse des opérations dont une référence appartient à ladite liste d'au moins une référence d'opération à réaliser ont été réalisées.
7. 7. Procédé selon l'une quelconque des revendications 1 à 6 comprenant en outre une étape de validation par un utilisateur.
8. 8. 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 1 à 7 lorsque ledit programme est exécuté sur un ordinateur.
9. 9. Dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 7.
10. 10. Aéronef comprenant le dispositif selon la revendication 9.