Brevet FR2946769A1 — publié le 20101217

La présente invention concerne l'architecture et la gestion de l'avionique d'un aéronef et plus particulièrement un procédé et un dispositif de reconfiguration et de maintenance automatique ou semi-automatique de l'avionique. Les aéronefs modernes comprennent de plus en plus de systèmes électroniques et informatiques pour améliorer leurs performances et assister le pilote ainsi que les membres d'équipage lors de leurs missions. Ainsi, par exemple, les commandes de vol électriques permettent de réduire la complexité mécanique de la transmission des commandes aux actuateurs et donc la masse associée à ces commandes. De même, la présentation d'informations pertinentes permet au pilote d'optimiser les trajectoires de vol et de répondre rapidement à tout incident détecté. De telles informations sont notamment la vitesse, la position, le cap, des données de météorologie et de navigation. L'ensemble de ces systèmes électroniques et informatiques est généralement appelé l'avionique. Pour des raisons de fiabilité, l'avionique a souvent été répartie de façon fonctionnelle par modules spécifiques, aussi appelé LRU (sigle de Line Replaceable Unit en terminologie anglo-saxonne). Selon cette architecture, un mode de transmission point à point est utilisé entre chaque module. Ainsi, par exemple, les commandes de vol sont gérées dans un dispositif particulier tandis que l'alimentation électrique est gérée dans un autre. Une fonction spécifique est ainsi associée à chaque module. Par ailleurs, chaque module supportant une fonction critique est, de préférence, redondant de telle sorte que la défaillance d'un module n'entraîne pas la perte de la fonction associée. L'exploitation d'un aéronef utilisant un module redondant lorsque le module principal est défaillant peut nécessiter une opération de maintenance. Afin d'améliorer les fonctionnalités des aéronefs, réduire le poids des équipements électroniques grâce à une plus grande intégration, réduire les coûts grâce à l'utilisation de modules génériques, et faciliter les opérations de maintenance, l'avionique est maintenant de plus en plus intégrée selon une architecture appelée IMA (sigle d'lntegrated Modular Avionics en terminologie anglo-saxonne). Selon cette architecture, les fonctionnalités des systèmes avioniques utilisent autant que possible des ressources génériques de calcul et d'entrées/sorties dans lesquels elles sont implémentées. Néanmoins, un système de ségrégation ou de partitionnement permet d'isoler chacune des fonctionnalités de telle sorte que la défaillance d'une fonction n'ait pas d'influence sur une autre. La figure la illustre schématiquement un exemple d'architecture IMA. Le coffret électrique 100, aussi appelé armoire électrique ou cabinet en terminologie anglo-saxonne, comprend ici les baies 105-1 à 105-n adaptées à recevoir des cartes, par exemple des cartes de type PCB (sigle de Printed Circuit Board en terminologie anglo-saxonne). Le coffret électrique 100 comprend dans sa partie arrière des connecteurs pour relier les cartes insérées dans les baies 105-1 à 105-n les unes aux autres et pour connecter ces cartes aux composants de l'aéronef. A titre d'illustration, le coffret électrique 100 comprend ici deux cartes génériques de calcul, aussi appelées calculateurs, référencées 110, adaptées à exécuter des applications logicielles pour implémenter des fonctions d'avionique. Chaque calculateur comprend ici les ressources qui lui sont nécessaires liées, notamment, à l'alimentation électrique et aux fonctions de communication. A titre d'illustration, la demande de brevet FR 2 903 511 décrit une telle architecture. La figure 1 b illustre l'architecture logique associée à l'architecture IMA illustrée sur la figure 1 a. Les calculateurs 110 peuvent ici recevoir et/ou transmettre des données via un réseau 115. Chaque unité de calcul 110-i comprend un système d'exploitation 120-i permettant l'exécution d'une ou de plusieurs applications 125-i. Les applications n'étant pas liées à une unité de calcul particulière, les applications exécutées par une unité de calcul peuvent être transférées à une autre unité de calcul non utilisée lorsqu'une défaillance matérielle est détectée. De même, des applications ayant un faible niveau de priorité peuvent être arrêtées pour permettre l'exécution d'applications ayant un plus haut niveau de priorité. En d'autres termes, l'architecture IMA offre une couche réseau, une couche matériel formée par l'ensemble des unités de calcul, une couche logiciel de bas niveau et une couche logicielle applicative fournissant les fonctions d'avionique. Bien qu'il existe des systèmes de reconfiguration permettant de déplacer l'exécution d'une application d'un calculateur à un autre lorsqu'une défaillance est détectée, il existe néanmoins un besoin pour améliorer ces systèmes de reconfiguration et de maintenance de l'avionique. L'invention permet de résoudre au moins un des problèmes exposés précédemment. L'invention a ainsi pour objet un procédé de reconfiguration d'un système d'avionique comprenant au moins deux calculateurs et au moins une application logicielle, dans un aéronef comprenant ledit système, chacun desdits au moins deux calculateurs étant adapté à exécuter ladite au moins une application logicielle, ledit aéronef comprenant en outre un module de détection de défaillance d'au moins l'un desdits au moins deux calculateurs ainsi qu'un module de chargement d'applications permettant de charger ladite au moins une application logicielle dans chacun desdits au moins deux calculateurs, ce procédé comprenant les étapes suivantes, - réception, dudit module de détection, d'au moins une information relative à l'état d'au moins l'un desdits au moins deux calculateurs ; - détection d'au moins une défaillance d'au moins un desdits au moins deux calculateurs selon ladite au moins une information ; - détermination d'une configuration selon laquelle au moins une application exécutée par ledit au moins un calculateur défaillant est exécutée par un autre desdits au moins deux calculateurs ; - reconfiguration dudit système selon ladite configuration, ladite étape de reconfiguration comprenant une étape de transmission d'une requête audit module de chargement pour charger ladite au moins une application exécutée par ledit au moins un calculateur défaillant dans ledit un autre desdits calculateurs. Le procédé selon l'invention vise ainsi un dispositif de reconfiguration automatique ou semi-automatique des ressources génériques de calcul utilisées par les fonctions avioniques permettant d'améliorer la disponibilité opérationnelle de l'aéronef tout en limitant les interventions des personnels de maintenance. De façon avantageuse, le procédé comprend en outre une étape de réception d'au moins une information relative à l'état dudit aéronef, lesdites étapes de détection, détermination et reconfiguration étant exécutées selon ladite au moins une information relative à l'état dudit aéronef. Ainsi, le procédé selon l'invention peut notamment adapter les possibilités de reconfiguration selon l'état de l'aéronef pour respecter des contraintes de sécurité. Selon un mode de réalisation particulier, le procédé comprend en outre une étape de validation de ladite configuration pour garantir la sécurité de l'aéronef. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de désactivation dudit au moins un calculateur défaillant pour, notamment, réduire la consommation électrique et la puissance dissipée. Le procédé comprend en outre, de préférence, une étape d'activation d'un calculateur non utilisé parmi lesdits au moins deux calculateurs, ladite au moins une application exécutée par ledit au moins un calculateur défaillant étant chargée dans ledit calculateur non utilisé. Ainsi, le procédé permet d'optimiser l'utilisation des calculateurs, en particulier en termes de consommation électrique et de puissance dissipée. De façon avantageuse, le procédé comprend en outre une étape de transfert d'une application exécutée dans un premier calculateur desdits au moins deux calculateurs vers un second calculateur desdits au moins deux calculateurs, ladite au moins une application exécutée par ledit au moins un calculateur défaillant étant chargée dans ledit second calculateur. Toujours selon un mode de réalisation particulier, le procédé comprend également une étape de mise à jour d'au moins une table de routage, ladite au moins une table de routage permettant à au moins un calculateur desdits au moins deux calculateurs d'échanger des données avec un dispositif dudit aéronef. Le procédé selon l'invention permet ainsi d'assurer une totale transparence de la reconfiguration d'un équipement, aucune modification des équipements dialoguant avec un équipement reconfiguré n'étant nécessaire. L'invention a également pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé décrit précédemment lorsque ledit programme est exécuté sur un ordinateur, un dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé décrit précédemment ainsi qu'un aéronef comprenant le dispositif selon la revendication précédente. Les avantages procurés par un tel programme d'ordinateur et un tel dispositif sont similaires à ceux évoqués précédemment. D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, au regard des dessins annexés dans lesquels : - la figure 1, comprenant les figures la et 1 b, représente schématiquement un exemple d'architecture IMA ; - la figure 2 illustre schématiquement les différents scénarii 25 envisagés pour les opérations de reconfiguration et de maintenance de l'avionique selon l'état de l'aéronef ; - la figure 3 représente schématiquement un exemple d'architecture de cabinet permettant sa reconfiguration conformément à l'invention ; - la figure 4 représente schématiquement un exemple d'architecture 30 selon l'invention permettant la reconfiguration de l'avionique ; - la figure 5 illustre schématiquement certaines étapes d'un exemple d'algorithme permettant de déterminer une nouvelle configuration du cabinet ; - la figure 6 illustre schématiquement certaines étapes d'un exemple d'algorithme de reconfiguration de l'avionique conforme à l'invention ; - la figure 7, comprenant les figures 7a, 7b et 7c, illustre un exemple de reconfiguration d'un système avionique, conformément à l'invention, suite à la détection successive de deux défaillances de calculateurs ; - la figure 8 illustre un exemple d'architecture matérielle adaptée à mettre en oeuvre l'invention, notamment les algorithmes représentés sur les figures 5 et 6. L'invention a pour objet la reconfiguration et la maintenance de l'avionique. Celles-ci peuvent être automatiques ou supervisées, c'est-à-dire que les choix opérés par le système de reconfiguration et de maintenance doivent être validés par une personne ayant le niveau de compétence requis. La validation peut être réalisée directement dans l'aéronef ou à distance, par exemple depuis un centre de maintenance. Plusieurs implémentations sont envisagées selon, notamment, que l'aéronef est en vol ou au sol. La figure 2 illustre schématiquement les différents scénarii 200 envisagés pour les opérations de reconfiguration et de maintenance de l'avionique selon l'état de l'aéronef. Comme illustré, lorsqu'une phase de reconfiguration ou de maintenance 205 doit être mise en oeuvre, notamment suite à la détection d'une défaillance d'un élément de l'avionique, il est tout d'abord nécessaire de déterminer l'état de l'aéronef, par exemple au sol (référence 210-1) ou en vol (référence 210-2). Si l'aéronef est au sol, il est alors nécessaire de déterminer si la phase de reconfiguration ou de maintenance doit être effectuée selon un mode supervisé (référence 215-1) ou automatique (référence 215-2). Si le mode déterminé est le mode supervisé, il est enfin nécessaire de déterminer si la phase de reconfiguration ou de maintenance doit être définie selon un schéma statique prédéterminé (référence 220-1) ou de façon dynamique (référence 220-2). Selon le schéma statique, toutes les configurations acceptables sont prédéterminées, le système de reconfiguration et de maintenance se limitant à choisir une configuration particulière parmi l'ensemble de configurations prédéterminées selon des paramètres préalablement identifiés. Un tel schéma présente l'avantage de la simplicité et de la sécurité. En particulier, une certification peut être plus facilement obtenue pour un tel schéma déterministe. Cependant, il peut conduire à des situations pour lesquelles aucune configuration n'a été déterminée et, par conséquent, ne permettant pas une exploitation optimale de l'aéronef. Alternativement, selon le schéma dynamique, la configuration optimale est évaluée selon des paramètres pertinents en fonction de règles prédéterminées. Un tel schéma permet d'optimiser l'exploitation de l'avionique et de répondre, en particulier, aux problèmes de défaillances en cascade. Cependant, la mise en oeuvre d'un tell schéma peut conduire à des difficultés de certification. Si le mode déterminé est le mode automatique, il est alors nécessaire de déterminer si la phase de reconfiguration ou de maintenance doit être définie selon un schéma statique prédéterminé (référence 225-1) ou de façon dynamique (référence 225-2). De même, si l'aéronef est en vol, il est nécessaire de déterminer si la phase de reconfiguration ou de maintenance doit être effectuée selon un mode supervisé (référence 230-1) ou automatique (référence 230-2), selon un schéma statique prédéterminé (références 235-1 et 240-1) ou de façon dynamique (références 235-2 et 240-2). Il convient de remarquer ici que, comme indiqué sur la figure, la complexité du système de reconfiguration et de maintenance croît, en particulier, avec l'automatisation et la gestion dynamique. De plus, pour des raisons de sécurité, la mise en oeuvre d'opérations de reconfiguration et de maintenance est plus complexe et plus critique en vol qu'au sol. Le scénario de reconfiguration et de maintenance peut être prédéterminé, c'est-à-dire qu'un seul mode parmi les modes 220-1, 220-2, 225-1 et 225-2 et/ou 235-1, 235-2, 240-1 et 240-2 est mis en oeuvre. Alternativement, plusieurs ou tous les scénarii peuvent être implémentés, le choix du scénario devant être utilisé étant déterminé par une personne qualifiée selon certaines conditions. Naturellement, d'autres scénarii peuvent être envisagés. En particulier, lorsque l'aéronef est au sol, il est possible de distinguer les phases de roulage, les phases de chargement/déchargement et les phases de maintenance. A titre d'illustration, les trois scénarii suivants peuvent être utilisés, - scénario 1 (au sol) : il n'y a pas de contrainte de sécurité particulière à l'exception de certaines opérations de maintenance ne pouvant être réalisées dans des configurations particulières telles que le remplissage des réservoirs de carburant. La reconfiguration peut ainsi être automatique et basée, par exemple, sur des configurations prédéterminées et certifiées. La reconfiguration peut également être supervisée et utiliser une interface homme-machine de l'aéronef pour valider la configuration choisie ; et, - scénario 2 (en vol) : il existe, en vol, des contraintes de sécurité forte. La reconfiguration est également basée, par exemple, sur des configurations prédéterminées et certifiées. Pour les applications ayant un impact sur la sécurité de l'aéronef, la reconfiguration est avantageusement supervisée. Cependant, pour des applications de confort, la reconfiguration est, de préférence, automatique pour ne pas perturber l'équipage durant la mission. La figure 3 représente schématiquement un exemple d'architecture de cabinet, appelée DME (sigle de Distributed Modular Electronics en terminologie anglo-saxonne), basée sur une architecture IMA, permettant la reconfiguration de l'avionique conformément à l'invention. Une telle architecture a notamment pour objet la mutualisation de certaines ressources telles que les liens de communication et l'alimentation électrique. Le cabinet 300 comprend ici les baies 305-1 à 305-n adaptées à recevoir des cartes, par exemple des cartes de type PCB, ainsi que, dans sa partie arrière, des connecteurs pour relier les cartes insérées dans les baies 305-1 à 305-n les unes aux autres, via un bus de communication interne, et pour connecter ces cartes aux composants de l'aéronef via un réseau de communication tel que le réseau AFDX (sigle d'Avionics Full DupleX en terminologie anglo-saxonne). A titre d'illustration, le cabinet 300 comprend ici deux cartes redondantes d'alimentation électrique, référencées 310-1 et 310-2, deux cartes redondantes de type réseau, référencées 315-1 et 315-2, ainsi que des calculateurs, aussi appelés CPM (sigle de Core Processing Module en terminologie anglo-saxonne), référencées 320, adaptées à exécuter des applications logicielles. Les CPM 320 partagent notamment les ressources mises à leur disposition par les cartes d'alimentation électrique 310-1 et 310-2 ainsi que par les cartes 315-1 et 315-2 de type réseau. D'autres types de ressources telles qu'une mémoire de masse peuvent être partagés de façon similaire. La modularité du cabinet 300 permet d'améliorer ses caractéristiques, notamment en termes de masse et de volume, mais également d'optimiser les coûts de maintenance liés au remplacement de cartes défaillantes. Il convient également de remarquer qu'une telle architecture permet d'adapter facilement les ressources de calcul aux besoins des applications. La figure 4 représente schématiquement un exemple d'architecture selon l'invention, basée sur l'architecture DME illustrée sur la figure 3, permettant la reconfiguration de l'avionique. Le coffret électrique 400, correspondant par exemple au cabinet 300 illustré sur la figure 3, comprend les calculateurs génériques sur lesquels sont exécutées les applications logicielles offrant les fonctions d'avioniques. Comme indiqué précédemment, les calculateurs sont reliés entre eux, aux ressources partagées ainsi qu'à divers dispositifs de l'aéronef. Bien que les applications logicielles soient chargées dans les calculateurs, une copie de celles-ci est, de préférence, mémorisée dans une base de données 405, appelée DLCS (sigle de Data Loading Configuration System en terminologie anglo-saxonne). Ces copies permettent notamment de configurer chacun des calculateurs lorsqu'ils sont changés pour garantir la bonne version de l'application logicielle. L'exécution des applications par les calculateurs génériques est ici contrôlée par une application spécifique 410, appelée cabinet manager en terminologie anglo-saxonne. Le cabinet manager peut être exécuté dans un système spécifique ou dans un calculateur générique. Selon un mode de réalisation particulier, il est exécuté dans un module spécifique du cabinet, par exemple le système d'alimentation électrique. Le cabinet manager utilise une base de données 415 permettant notamment de mémoriser la configuration du cabinet ainsi que l'état opérationnel de chaque carte. De façon générale, le cabinet manager a pour objet la gestion de chaque élément du cabinet, considéré indépendamment des autres, par exemple, la mise en route et l'arrêt, ainsi que celle des ressources partagées. Le cabinet manager possède la capacité de dialoguer avec chacune des cartes afin de vérifier notamment leur état fonctionnel, leur configuration matérielle et logicielle, en particulier les références appelées Part Number et Serial Number en terminologie anglo-saxonne, et, pour certaines cartes dépourvues de calculateur, de programmer une mémoire non volatile (appelée Non Volatile Memory en terminologie anglo-saxonne) qui permet de connaître les circonstances de la défaillance à l'atelier de maintenance. Par ailleurs, un système de supervision 420, appelé RS (sigle de Reconfiguration Supervisor en terminologie anglo-saxonne), est utilisé, en particulier, pour établir un diagnostic de l'avionique via un système de diagnostic 425, appelé CMS (sigle de Centralized Maintenance System en terminologie anglo-saxonne), et pour déterminer et appliquer une nouvelle configuration de celle-ci lorsqu'une défaillance est détectée. Le RS est donc alerté par le CMS de toutes les anomalies concernant les équipements avioniques, détectées lors des auto-tests de ces modules ou lors de l'opération des équipements, en vol ou au sol. Le CMS est de préférence relié à chaque équipement de l'aéronef, plus particulièrement à la fonction BITE (sigle de Built ln Test Equipment en terminologie anglo-saxonne) ou plus généralement à la fonction appelée Health Monitoring (HMon) en terminologie anglo-saxonne de chacun de ces équipements. Les fonctions BITE ou HMon comprennent une logique permettant de détecter une défaillance de l'équipement surveillé selon des critères prédéterminés et de transmettre un message d'alerte, sous forme de message BITE ou HMon, au CMS. Ce dernier alerte l'équipage si nécessaire et mémorise les informations reçues pour faciliter les opérations de maintenance. Chaque équipement du coffret électrique 400, c'est-à-dire ici chaque calculateur générique, système d'alimentation et carte réseau, est ainsi équipé d'une fonction BITE ou HMon qui est reliée au CMS 425 comme illustré. Le système de supervision 420 est également relié à un module 430 utilisé pour obtenir des paramètres de l'aéronef tels que son état au sol ou en vol. L'architecture illustrée sur la figure 4 permet de reconfigurer l'avionique, notamment de gérer les calculateurs utilisés et la répartition des applications d'avionique sur ces derniers. Ainsi, de façon générale, lorsqu'une défaillance est détectée dans le calculateur du cabinet 400, celui-ci transmet un message BITE au CMS 425 qui alerte le superviseur 420. Ce dernier, après avoir vérifié l'état de l'aéronef à l'aide du module 430 pour vérifier qu'une reconfiguration peut et doit être effectuée, transmet ses instructions au cabinet manager 410 pour modifier les calculateurs actifs. Simultanément, ou de façon séquentielle, le superviseur transmet des instructions au DLCS 405 pour recharger les applications devant être exécutées dans les calculateurs nouvellement désignés à cet effet ainsi que les tables de routage du réseau AFDX, afin de permettre un déroutement automatique des données échangées par les fonctions reconfigurées. Ceci permet d'assurer une totale transparence de la reconfiguration d'un équipement, aucune modification des équipements dialoguant avec un équipement reconfiguré n'étant nécessaire. Il convient de noter ici que deux verrous de sécurité supplémentaires sont de préférence apportés par le cabinet manager et par les calculateurs eux-mêmes afin d'éviter toute reconfiguration erronée ou indésirable : - le cabinet manager a connaissance des paramètres de l'aéronef ainsi que de la criticité des applications qui sont exécutées par chacun des calculateurs afin de pouvoir refuser une reconfiguration erronée en vol d'une application critique pour le vol telle que la gestion des commandes de vol électriques, le système électrique ou la gestion du carburant ; et, - chaque calculateur peut avantageusement refuser le chargement d'une nouvelle application logicielle, notamment lorsque ce chargement est initié pendant le fonctionnement opérationnel du calculateur s'il est contradictoire avec la mission de ce calculateur. La figure 5 illustre schématiquement certaines étapes d'un exemple d'algorithme permettant de déterminer une nouvelle configuration du cabinet. Après avoir reçu des informations du CMS, relatives à l'état du cabinet (étape 500), ces informations sont analysées pour déterminer si un élément de celui-ci est défaillant (étape 505). Des tests de l'équipement défaillant sont de préférence effectués afin de confirmer le diagnostic émis par le CMS. Il convient de noter ici que les informations reçues permettent d'identifier des défaillances mais également de déterminer les ressources disponibles. Si aucune indication de défaillance n'est détectée dans le cabinet, l'algorithme retourne à l'étape précédente. Dans le cas contraire, si une défaillance est confirmée dans le cabinet, et après réception d'informations relatives à l'état de l'aéronef (étape 510), par exemple s'il est au sol ou en vol, une nouvelle configuration est déterminée (étape 515). Chaque nouvelle configuration est déterminée selon les paramètres de défaillance reçus du CMS et visant le cabinet ainsi que selon les informations relatives à l'état de l'aéronef. Comme indiqué précédemment, une nouvelle configuration peut être déterminée dynamiquement en fonction de règles prédéterminées ou, alternativement, selon un arbre de décision prédéterminé. Le choix lui-même entre la détermination dynamique ou statique peut être prédéterminé ou résulter de l'application de règles prédéterminées. Les configurations prédéterminées, de préférence certifiées, peuvent être mémorisées sous forme de tables comprenant par exemple la liste des calculateurs et, pour chacun d'eux, la liste des applications dont ils sont chargés de l'exécution. De telles tables peuvent également comprendre d'autres informations telles que le niveau de priorité de chaque application. Ces tables contiennent, pour chaque configuration valide de l'aéronef, l'ensemble des reconfigurations possibles et l'identification des équipements à activer ainsi que des applications à déplacer, incluant les tables de configuration et de routage pour mettre en oeuvre ces reconfigurations. Par ailleurs, un graphe de décision peut être mémorisé pour relier les configurations les unes aux autres selon des paramètres prédéterminés. Ainsi, à titre d'illustration, le graphe de décision peut être utilisé pour indiquer que, si l'avionique d'un aéronef est dans une configuration A et qu'une défaillance est détectée dans le calculateur X, le système doit être reconfiguré selon la configuration B. Lorsqu'une configuration est déterminée, celle-ci est analysée (étape 520) pour être validée (étape 525). Comme indiqué précédemment, la validation peut être automatique et réalisée selon des règles prédéterminées ou soumise à l'approbation d'une personne compétente. Dans ce dernier cas, la validation peut être réalisée à distance en mettant en oeuvre des moyens de validation et de communication standard. Si la configuration n'est pas valide, les quatre étapes précédentes (étapes 510 à 525) sont répétées pour identifier une autre configuration. Si, au contraire, la configuration est valide, le cabinet est reconfiguré selon cette dernière (étape 530). L'étape de reconfiguration est décrite plus en détails en référence à la figure 6. L'algorithme retourne alors à l'étape 500 pour être en mesure de détecter de nouvelles défaillances. L'algorithme illustré sur la figure 5 est, de préférence, mis en oeuvre dans un module de supervision tel que le superviseur 420 illustré sur la figure 4. Cependant, cet algorithme peut également être implémenté, au moins partiellement, dans le cabinet manager référencé 410 sur la figure 4. La figure 6 illustre schématiquement certaines étapes d'un exemple d'algorithme de reconfiguration conforme à l'invention. Après avoir désactivé le calculateur défaillant (étape 600) et, si besoin, activé un calculateur disponible (étape 605), de façon séquentielle ou parallèle, une requête est transmise au DLCS pour charger l'application ou les applications qui étaient exécutées par le calculateur défaillant sur le calculateur désigné (étape 610). Il convient de remarquer ici que l'étape d'activation d'un calculateur disponible n'est pas systématiquement mise en oeuvre, en particulier lorsque le cabinet ne comprend pas de calculateur disponible ou s'il est décidé d'exécuter l'application ou les applications précédemment exécutées sur le calculateur défaillant sur un ou plusieurs calculateurs partiellement utilisés. De même, il peut être décidé de libérer des ressources d'un ou de plusieurs calculateurs en fonction, par exemple, d'un niveau de priorité associé aux applications exécutées pour permettre l'exécution de nouvelles applications sur ceux-ci. Les tables de routage du cabinet sont mises à jour pour permettre aux nouvelles applications installées de communiquer avec les dispositifs associés à celles-ci (étape 615). Ces tables de routage sont nécessaires au fonctionnement des équipements en charge du réseau de communication AFDX appelés commutateurs ou switches AFDX. Les applications peuvent alors être activées (étape 620). Il convient de remarquer ici que des partitions ou des machines virtuelles peuvent être mises en oeuvre dans les calculateurs. Dans ce cas, une étape standard d'activation des partitions ou des machines virtuelles est mise en oeuvre. La configuration est alors validée (étape 625) en comparant la configuration réelle du cabinet avec la configuration déterminée pour pallier à la défaillance d'un calculateur (étape 515 de la figure 5). Si une différence est détectée, une alerte est générée. L'algorithme illustré sur la figure 6 est, de préférence, mis en oeuvre dans le cabinet manager (référence 410 de la figure 4). Néanmoins, au moins une partie de celui-ci peut également être mis en oeuvre dans le superviseur (référence 420 de la figure 4). La figure 7, comprenant les figures 7a, 7b et 7c, illustre un exemple de reconfiguration d'un système avionique, conformément à l'invention, suite à la détection successive de deux défaillances de calculateurs. La figure 7a représente la configuration d'un cabinet à un instant donné. Comme illustré, le cabinet comprend ici cinq calculateurs CPM1 à CPM5 ayant chacun son système d'exploitation, aussi appelé OS (sigle d'Operating System en terminologie anglo-saxonne). Le calculateur CPM1 exécute l'application F1, le calculateur CMP2 exécute les applications F2 et F3, le calculateur CPM3 exécute l'application F4 et le calculateur CPM4 exécute l'application F5. Le calculateur CPM5 est ici inactif. A titre d'illustration, il est admis ici que le niveau de priorité de l'application F2 est inférieur à celui de l'application F3 qui est lui-même inférieur à celui des applications F1, F4 et F5. Lorsqu'une défaillance est détectée dans le calculateur CPM3, une nouvelle configuration est déterminée. Celle-ci consiste, par exemple, à déplacer l'application F4 qui était précédemment exécutée par le calculateur CPM3 vers le calculateur CPM5 qui était inutilisé. Comme illustré sur la figure 7b, le calculateur CPM3 est alors désactivé tandis que le calculateur CPM5 est activé. L'application F4 est ensuite chargée dans le calculateur CPM5 et les tables de routage sont mises à jour pour permettre à l'application F4 d'échanger des données avec les dispositifs de l'aéronef (pouvant inclure d'autres applications logicielles) auxquels elle est associée. Si, par la suite, une défaillance survient dans le calculateur CPM4, une nouvelle configuration est déterminée. Aucun calculateur n'étant disponible, celle-ci consiste ici à arrêter certaines applications afin de récupérer les ressources nécessaires pour permettre l'exécution des applications dont le niveau de priorité est le plus élevé. Ainsi, comme illustré sur la figure 7c, l'application F2 est arrêtée et l'application F3 est déplacée vers le calculateur CPM1 afin de libérer le calculateur CPM2 qui est alors disponible pour exécuter l'application F5. La figure 8 illustre un exemple d'architecture matérielle adaptée à mettre en oeuvre l'invention, notamment au moins certaines parties des algorithmes représentés sur les figures 5 et 6. Le dispositif 800 comporte ici un bus de communication 805 auquel sont reliés : - une unité centrale de traitement ou microprocesseur 810 (CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ; - une mémoire morte 815 (ROM, acronyme de Read Only Memory en terminologie anglo-saxonne) pouvant comporter les programmes nécessaires à la mise en oeuvre de l'invention ; - une mémoire vive ou mémoire cache 820 (RAM, acronyme de Random Access Memory en terminologie anglo-saxonne) comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution des programmes précités ; et - une interface de communication 850 adaptée à transmettre et à recevoir des données, notamment vers et depuis les dispositifs commandés de l'aéronef pour les contrôler et connaître leur état. Le dispositif 800 dispose également, de préférence, des éléments suivants : - un écran 825 permettant de visualiser des données telles que des représentations des commandes et pouvant servir d'interface graphique avec l'utilisateur qui pourra interagir avec les programmes selon l'invention, à l'aide d'un clavier et d'une souris 830 ou d'un autre dispositif de pointage tel qu'un écran tactile ou une télécommande ; - d'un disque dur 835 pouvant comporter les programmes précités et des données traitées ou à traiter selon l'invention ; et - d'un lecteur de cartes mémoires 840 adapté à recevoir une carte mémoire 845 et à y lire ou à y écrire des données traitées ou à traiter selon l'invention. Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le dispositif 800 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 800 directement ou par l'intermédiaire d'un autre élément du dispositif 800. Le code exécutable de chaque programme permettant au dispositif programmable de mettre en oeuvre les processus selon l'invention, peut être stocké, par exemple, dans le disque dur 835 ou en mémoire morte 815. Selon une variante, la carte mémoire 845 peut contenir des données, notamment une table de correspondance entre les événements détectés et les commandes pouvant être sollicitées, ainsi que le code exécutable des programmes précités qui, une fois lu par le dispositif 800, est stocké dans le disque dur 835. Selon une autre variante, le code exécutable des programmes pourra être reçu, au moins partiellement, par l'intermédiaire de l'interface 850, 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 chargés dans un des moyens de stockage du dispositif 800 avant d'être exécutés. L'unité centrale 810 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 835 ou dans la mémoire morte 815 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 835 ou la mémoire morte 815, sont transférés dans la mémoire vive 820 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. REVENDICATIONS1. Procédé de reconfiguration d'un système d'avionique comprenant au moins deux calculateurs et au moins une application logicielle, dans un aéronef comprenant ledit système, chacun desdits au moins deux calculateurs étant adapté à exécuter ladite au moins une application logicielle, ledit aéronef comprenant en outre un module de détection de défaillance d'au moins l'un desdits au moins deux calculateurs ainsi qu'un module de chargement d'applications permettant de charger ladite au moins une application logicielle dans chacun desdits au moins deux calculateurs, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes, - réception (500), dudit module de détection, d'au moins une information relative à l'état d'au moins l'un desdits au moins deux calculateurs ; - détection (505) d'au moins une défaillance d'au moins un desdits au moins deux calculateurs selon ladite au moins une information ; - détermination (515) d'une configuration selon laquelle au moins une application exécutée par ledit au moins un calculateur défaillant est exécutée par un autre desdits au moins deux calculateurs ; - reconfiguration (530) dudit système selon ladite configuration, ladite étape de reconfiguration comprenant une étape de transmission d'une requête audit module de chargement pour charger ladite au moins une application exécutée par ledit au moins un calculateur défaillant dans ledit un autre desdits calculateurs. 2. Procédé selon la revendication précédente comprenant en outre une étape de réception (510) d'au moins une information relative à l'état dudit aéronef, lesdites étapes de détection, détermination et reconfiguration étant exécutée selon ladite au moins une information relative à l'état dudit aéronef. 3. Procédé selon la revendication 1 ou la revendication 2 comprenant en outre une étape de validation (525) de ladite configuration. 4. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de désactivation (600) dudit au moins un calculateur défaillant. 5. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape d'activation (605) d'un calculateur non utilisé parmi lesdits au moins deux calculateurs, ladite au moins une application exécutée par ledit au moins un calculateur défaillant étant chargée dans ledit calculateur non utilisé. 6. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de transfert d'une application exécutée dans un premier calculateur desdits au moins deux calculateurs vers un second calculateur desdits au moins deux calculateurs, ladite au moins une application exécutée par ledit au moins un calculateur défaillant étant chargée dans ledit second calculateur. 7. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de mise à jour (615) d'au moins une table de routage, ladite au moins une table de routage permettant à au moins un calculateur desdits au moins deux calculateurs d'échanger des données avec un dispositif dudit aéronef. 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 précédentes lorsque ledit programme est exécuté sur un ordinateur. 9. Dispositif comprenant des moyens adaptés à la mise en oeuvre 25 de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 7. 10. Aéronef comprenant le dispositif selon la revendication précédente.