FR 3003365 A1 20140919 FR 1352194 A 20130312 La présente invention concerne la mise à jour d'applications logicielles et plus particulièrement un procédé et un dispositif de gestion de mises à jour logicielles d'un ensemble d'équipements d'un système tel qu'un système d'un aéronef permettant notamment un rechargement automatique d'une configuration initiale suite à une erreur de mise à jour d'un ou plusieurs des appareils. De façon générale, chaque aéronef fabriqué est livré à une compagnie aérienne dans une configuration particulière. Cependant, une solution technique pouvant évoluer dans le temps, les constructeurs d'aéronefs mettent généralement en oeuvre des processus d'amélioration selon lesquels des éléments matériels et/ou logiciels sont remplacés par d'autres. Chaque pièce d'aéronef, mécanique, électronique ou logiciel, est identifiée par un code invariant, appelé FIN (sigle de Functional Item Number en terminologie anglo-saxonne), désignant la fonction de la pièce et son emplacement. Par ailleurs, chacune de ces pièces comprend un numéro d'identification, appelé PNR (sigle de Part Number Reference en terminologie anglo-saxonne), qui identifie la solution technique appliquée à la pièce mécanique, électronique ou logicielle concernée pour accomplir la fonction à laquelle elle est destinée. Un PNR peut également être associé à un groupe de pièces formant un ensemble fonctionnel aussi appelé Constituant Assembly en terminologie anglo-saxonne, tel qu'un train d'atterrissage. Un PNR est un identifiant variable dans le temps selon le fabricant et la version. Ainsi, au cours de la vie d'un aéronef un élément ayant la référence PNRi peut être remplacé par un élément ayant la référence PNR2, ces éléments ayant le même code FIN. Le remplacement d'un élément ayant un code PNRi par un autre ayant un code PNR2 se fait à travers un processus de gestion de configuration dont l'élément unitaire d'évolution est appelé modification (MOD). Les caractéristiques techniques de l'évolution sont décrites dans une feuille de répercussion technique appelée Technical Repercussion Sheet en terminologie anglo-saxonne. Les constructeurs proposent généralement aux compagnies aériennes de bénéficier d'améliorations pour les aéronefs qui leur ont été livrés. L'application de MOD à des aéronefs déjà livrés s'effectue alors en suivant les indications d'un bulletin de service, appelé SB (sigle de Service Bulletin en terminologie anglo-saxonne). Ces bulletins sont des documents officiels utilisés pour notifier à une compagnie aérienne des modifications à effectuer sur un ou plusieurs aéronefs qu'elle exploite. Ils sont généralement produits par les constructeurs. Cependant, ils peuvent également être émis par leurs fournisseurs. Dans ce cas, le constructeur doit les valider. Un SB décrit, comme la MOD, l'état avant application du SB, par exemple l'utilisation de l'élément ayant pour code PNRi, et celui après application, par exemple l'utilisation de l'élément ayant pour code PNR2, les améliorations techniques apportées par les nouveaux éléments ainsi qu'une description du travail à effectuer pour le remplacement des éléments visés, par exemple la durée, le nombre et la qualification des personnels nécessaires à l'application du SB et les procédures à appliquer. Selon un mode de mise en oeuvre particulier, décrit notamment dans la demande de brevet FR 2 943 152, le SB est livré sous forme électronique (appelé eSB). Il permet d'automatiser certaines tâches de mises à jour logicielles d'équipements, sans changement matériel. De tels équipements sont généralement mis à jour à l'aide d'un système central de gestion de configuration, appelés DLCS (sigle de Data Loading and Configuration System en terminologie anglo-saxonne), qui permettent un téléchargement directement depuis un aéronef. Une caractéristique importante un eSB exécuté par un DLCS est la reproduction automatique d'opérations effectuées par un opérateur de maintenance. Ces opérations sont, par exemple, les suivantes : - la vérification de la configuration initiale des équipements (typiquement des calculateurs avioniques) faisant l'objet du eSB, appelée PRE- MOD, et, le cas échéant, vérification de la configuration d'autres équipements pour vérifier des contraintes de compatibilité (vérification de la mixabilité) ; - la sélection des éléments logiciels à charger en fonction de la configuration PRE-MOD des équipements ; - la vérification de la complétude des éléments logiciels à charger (typiquement l'ensemble comprenant les nouveaux éléments logiciels et les éléments logiciels à recharger) ; - le lancement du chargement des éléments logiciels, pouvant nécessiter le respect d'un ordre de chargement pour un équipement cible donné et pour des équipements cibles eux-mêmes (ainsi, par exemple, des commutateurs AFDX, sigle d' Avionic Full DupleX en terminologie anglo-saxonne, doivent généralement être chargés dans un ordre particulier pour éviter de perdre le réseau AFDX pendant le chargement) ; - la vérification de la configuration des équipements après la fin du 15 chargement, appelée POST-MOD ; et - l'affichage de messages explicatifs à un opérateur de maintenance donnant les résultats de type « OK » et « KO » pour chaque étape, des consignes et des informations d'aide. Cependant, si une telle solution se révèle souvent efficace, elle peut 20 être améliorée. En effet, lorsqu'une ou plusieurs mises à jour d'équipements échouent, l'intervention d'un opérateur de maintenance est nécessaire pour déterminer si la mise à jour doit être retentée ou non et, le cas échéant, reconfigurer le système dans son état initial (PRE-MOD). Ainsi, à titre d'illustration, en considérant trois calculateurs C1, C2, C3 25 et C4 comprenant chacun les éléments logiciels L1, L2, L3 et L4 dans leur version n et devant être migrés vers une version n+1, il est supposé que la mise à jour des calculateurs C1 et C2 se passe correctement ainsi que celle de l'élément logiciel L1 sur le calculateur C3 mais qu'une erreur apparait lors de la mise à jour de l'élément logiciel L2 sur le calculateur C3. 30 Dans ce cas, l'opérateur de maintenance reprend le contrôle du procédé de mise à jour et retente la mise à jour de l'élément logiciel L2 sur le calculateur C3. Après plusieurs tentatives infructueuses, l'opérateur décide de reconfigurer le système dans sa version initiale (n) pour ne pas immobiliser l'aéronef trop longtemps. A ces fins, il doit recharger les éléments logiciels L1, L2, L3 et L4, dans leur version n, dans les calculateurs C1 et C2 et recharger les éléments logiciels L1 et L2, dans leur version n, dans le calculateur C3. De telles procédures sont consommatrices de temps et ont un impact non négligeable sur la disponibilité des aéronefs. Il est observé ici que la perte de temps et les possibilités d'erreur de manipulations sont amplifiées, en particulier, par le nombre d'éléments logiciels à charger, le nombre d'équipements cibles concernés et le moment où se produit l'erreur (si la mise à jour échoue sur la mise à jour du premier élément logiciel du premier équipement cible, il y a moins d'effort à restaurer la configuration de départ que si elle se produit sur le dernier élément logiciel du dernier équipement cible). Il est également observé que si le type d'équipement sur lequel une mise à jour échoue n'a, jusqu'à présent, pas fait l'objet de difficulté de mise à jour particulière, l'opérateur de maintenance aura tendance à retenter le chargement de l'élément logiciel quel que soit le type d'erreur rencontré. Si, au contraire, le type d'équipement sur lequel une mise à jour échoue fait régulièrement l'objet de difficulté de mise à jour, l'opérateur, du fait de son expérience, n'aura pas tendance à vérifier les messages d'erreurs générés par le protocole de chargement et risque de décider directement un retour à la configuration initiale, se privant peut-être d'une installation réussie s'il avait retenté la mise à jour. L'invention permet de résoudre au moins un des problèmes exposés 25 précédemment. L'invention a ainsi pour objet un procédé pour ordinateur de gestion de mises à jour logicielles d'un ensemble d'équipements d'un système à partir d'indications d'un bulletin de service, les indications dudit bulletin de service étant accessibles sous forme de commandes, le procédé comprenant les 30 étapes suivantes, - sélection et exécution d'une commande visant au moins une indication dudit bulletin de service, ladite commande sélectionnée visant la modification de la configuration d'un équipement dudit système ; - si le résultat d'exécution de ladite commande sélectionnée est conforme à un résultat attendu, génération, selon le type de ladite commande exécutée, d'au moins une commande de restauration, ladite au moins une commande de restauration permettant la reconfiguration dudit équipement dans sa configuration précédent l'exécution de ladite commande sélectionnée ; et - si le résultat d'exécution de ladite commande sélectionnée n'est pas conforme à un résultat attendu, exécution d'au moins une commande de restauration préalablement générée. Le procédé selon l'invention permet ainsi d'éviter une perte de l'automatisation de l'exécution du chargement d'éléments logiciels sur plusieurs équipements cibles suite à un premier échec de chargement d'un élément logiciel sur un équipement cible. Il permet la restauration automatique de la configuration initiale en cas d'échec, notamment d'échecs répétés, du chargement d'un élément logiciel sur un équipement cible. Le procédé selon l'invention peut être utilisé avec des bulletins de service demandant un changement d'un élément matériel, c'est-à-dire une intervention d'un opérateur, et avec des bulletins de service liés à des calculateurs dépourvus de moyens permettant leur redémarrage après une mise à jour logicielle et/ou pourvus de fonctions de sécurité complexes pour passer dans un mode de téléchargement. Le procédé selon l'invention offre des fonctions d'interactivité et de synchronisation qui permettent d'optimiser des automatismes et opérations à distance d'un système de téléchargement embarqué. Selon un mode de réalisation particulier, le procédé comprend en outre une étape d'exécution d'une commande de test de configuration dudit équipement, ladite commande de test de configuration étant exécutée avant celle de ladite commande sélectionnée, au moins un paramètre de ladite commande de restauration générée correspondant à un résultat d'exécution de ladite commande de test de configuration. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de génération d'une commande de restauration de test de configuration dudit équipement, au moins un paramètre de ladite commande de restauration de test de configuration générée correspondant à un résultat d'exécution de ladite commande de test de configuration. Selon un mode de réalisation particulier, ladite commande de test de configuration dudit équipement vise au moins une indication dudit bulletin de service. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de concaténation de commandes de restauration préalablement générées, lesdites commandes de restauration préalablement générées étant concaténées selon un ordre défini par un numéro de séquence associé auxdites commandes de restauration préalablement générées. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de génération d'une commande de restauration d'affichage d'un message à destination d'un opérateur. Ladite commande de restauration d'affichage d'un message est par exemple générée lorsque ladite commande sélectionnée vise la configuration d'un équipement nouveau. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape d'évaluation d'un critère de sélection en cas d'échec d'exécution de ladite commande sélectionnée, ladite étape d'exécution de ladite commande sélectionnée étant répétée si ledit critère de sélection est vérifié. Le procédé selon l'invention permet ainsi, notamment, en fonction de la fiabilité de chargement d'un équipement donné, de déterminer si une nouvelle tentative de mise à jour doit être effectuée ou s'il convient de retourner à la configuration initiale. Selon un mode de réalisation particulier, ledit critère de sélection est basé sur un nombre d'éléments logiciels chargés avec succès dans ledit équipement, un nombre d'éléments logiciels à charger dans ledit équipement, un nombre d'équipements dont la configuration doit être modifiée, et/ou un code d'erreur d'exécution de ladite commande sélectionnée. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de comptage du nombre d'exécutions de ladite commande sélectionnée, ladite commande sélectionnée ne pouvant être exécutée qu'un nombre de fois limité déterminé par un seuil prédéterminé. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de génération d'une commande de restauration de synchronisation pour l'exécution de commandes de restauration. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de génération d'une commande de restauration 10 de réception d'au moins une donnée pour l'exécution de commandes de restauration. 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é 15 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 ce dispositif. Les avantages procurés par ce programme d'ordinateur, ce dispositif et cet aéronef sont similaires à ceux évoqués précédemment. 20 D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, au regard des dessins annexés dans lesquels : - la figure 1 illustre schématiquement certaines étapes d'un algorithme permettant de relancer le chargement d'un élément logiciel dans un 25 équipement et/ou réinitialiser des équipements suite à la détection d'une erreur de chargement d'un élément logiciel ; - la figure 2 illustre un exemple de mise en oeuvre d'une interface homme-machine permettant, à partir de commandes eSB, l'affichage d'informations ; 30 - la figure 3 illustre un exemple de mise en oeuvre d'une interface permettant, à partir de commandes eSB, de modifier le mode de configuration d'un équipement pour permettre sa mise à jour ; et - la figure 4 illustre schématiquement un dispositif adapté à mettre en oeuvre certains modes de réalisation, au moins partiellement, en particulier l'algorithme décrit en référence à la figure 1. De façon générale, l'invention permet, selon un mode de réalisation particulier, la gestion automatique de points de restauration en cas d'échec de chargement pendant l'exécution d'un eSB, incluant la prise de décision et l'exécution automatique de nouveaux essais de chargement jusqu'à l'obtention d'un chargement correct et/ou la restauration de la configuration initiale en cas d'échec répété. La prise de décision est avantageusement basée sur l'affectation de critères de « fiabilité du chargement » d'un équipement donné et sur l'affectation de critères de « récupérabilité » des erreurs rencontrées. Toujours selon un mode de réalisation particulier, la constitution d'un point de restauration est principalement basée sur l'identification d'une configuration « PRE-MOD » de chaque équipement impliqué par un eSB et sur la construction automatique et dynamique (i.e. au fur et à mesure de l'avancement de l'exécution de l'eSB), par le système de chargement, d'un « script de restauration » utilisant la même syntaxe et la même organisation qu'un eSB. Un tel script de restauration, appelé par la suite eSB de restauration, peut ainsi être exécuté comme un eSB standard. Lorsqu'une erreur de chargement est détectée, ou plus généralement lorsqu'une erreur d'exécution d'une commande d'un eSB est détectée, un critère de sélection est évalué pour déterminer s'il convient de réessayer le chargement ou l'exécution de la commande ou, au contraire, si le système doit être reconfiguré dans sa configuration initiale (PRE-MOD). Un tel critère de sélection peut être codé dans un eSB lui-même, permettant ainsi d'utiliser des critères différents selon les équipements visés, par exemple en fonction d'un historique connu de la susceptibilité d'un calculateur à avoir des pannes de chargement, ou configuré à l'aide de données de configuration externes pouvant être déterminées, par exemple, par compagnie aérienne. A titre d'illustration, un tel critère de sélection peut représenter le ratio du nombre d'équipements ayant correctement terminé le chargement de tous les éléments logiciels à charger dans ces derniers par rapport au nombre d'équipements devant charger un ou plusieurs éléments logiciels. Si la valeur de ce ratio est supérieure à un seuil prédéterminé (ou déterminé dynamiquement), le système central de gestion de configuration (aussi appelé dataloader en terminologie anglo-saxonne) relance le chargement de l'élément logiciel ayant conduit à l'erreur détectée. Ce critère de sélection est, de préférence, associé à un nombre maximum d'essais pour éviter de conduire à un blocage du système. Le nombre de tentatives de chargement d'un élément logiciel dans un équipement peut ainsi être limité à trois. Cette valeur peut être paramétrée avec le critère de sélection. Toujours à titre d'illustration, ce critère de sélection peut représenter le ratio du nombre d'éléments logiciels correctement chargés dans un équipement (e.g. l'équipement ayant provoqué l'erreur considérée ou un équipement en cours de chargement d'éléments logiciels) par rapport au nombre d'éléments logiciels devant être chargés dans cet équipement. Si la valeur de ce ratio est supérieure à un seuil prédéterminé ou déterminé dynamiquement, le système central de gestion de configuration relance le chargement de l'élément logiciel ayant conduit à l'erreur détectée. A nouveau, un nombre maximum d'essais est, de préférence, associé au critère de sélection. A titre d'illustration encore, ce critère de sélection peut représenter un indicateur de gravité de l'erreur de chargement. Un tel indicateur peut notamment être basé sur un code d'erreurs, par exemple un code d'erreurs défini dans une norme de chargement telle que les normes A615A (bus AFDX/Ethernet), A615-3 (bus A429) et A826 (bus CAN, acronyme de Controller Area Network en terminologie anglo-saxonne) ou tout autre norme. A partir d'un code d'erreur, le système central de gestion de configuration détermine un indicateur de gravité de l'erreur de chargement à l'aide d'un algorithme spécifique ou d'une table de correspondance pouvant, par exemple, être préchargée lors de la configuration du système central de gestion de configuration. Si la valeur de cet indicateur est supérieure à un seuil prédéterminé ou déterminé dynamiquement, le système central de gestion de configuration relance le chargement de l'élément logiciel ayant conduit à l'erreur détectée. A nouveau, un nombre maximum d'essais est, de préférence, associé au critère de sélection. Le critère de sélection peut également correspondre à une combinaison de ces critères. Selon la configuration du système central de gestion de configuration, il est possible d'appeler automatiquement une commande de réinitialisation (reset) ou de déclenchement / enclenchement d'alimentation électrique, avant de relancer le chargement de l'élément logiciel ayant conduit à l'erreur détectée (suite à l'estimation du critère de sélection et au résultat de sa comparaison avec un seuil). De même, une interface comprenant notamment une interface homme-machine peut être appelée automatiquement avant de relancer le chargement de l'élément logiciel ayant conduit à l'erreur détectée (suite à l'estimation du critère de sélection et au résultat de sa comparaison avec un seuil) pour requérir des décisions ou confirmations d'un opérateur. Une telle interface peut également permettre l'échange de données avec d'autres systèmes. Les commandes pouvant être utilisées dans les eSB peuvent généralement être chaînées les unes aux autres, en fonction de leur résultat (e.g. « OK» ou « KO ») ou non, pour contrôler des séquences de commandes exécutées de façon conditionnelle ou non. Il existe, en particulier, des commandes de type CheckConf pour obtenir la configuration logicielle d'éléments d'un équipement et des commandes de type UpLoad pour charger un élément logiciel dans un équipement. Une commande de type UpLoad peut ainsi être exécutée automatiquement après une commande de type CheckConf sous réserve que cette dernière retourne un résultat de type « OK ». Il est ainsi possible d'obtenir un état de configuration initiale d'équipements (PRE-MOD) avant chargement d'éléments logiciels. Cet état peut être utilisé pour réinitialiser la configuration d'un système lors d'une erreur persistante de chargement. Selon un mode de réalisation particulier, le système central de gestion de configuration détermine, lors de l'exécution des commandes d'un eSB, la configuration des équipements dans lesquels des éléments logiciels sont chargés. Plus précisément, le système central de gestion de configuration détermine le couple (FIN, PNR) des éléments logiciels faisant l'objet d'un chargement avant que ce dernier n'ait lieu, permettant ainsi la reconfiguration des équipements dans leur configuration initiale (PRE-MOD) si un problème de chargement est détecté. Ces couples sont mémorisés avec un numéro de séquence. De même, des informations relatives aux opérations de remplacement d'équipements et de chargements d'éléments logiciels dans ces équipements sont déterminées et mémorisées pour permettre un retour à la configuration initiale si une erreur de chargement est détectée. A ces fins, chaque commande de type CheckConf de l'eSB visant à déterminer une configuration initiale est analysée, lorsque son résultat est de type « OK », pour identifier le couple (FIN, PNR_init). En outre, une commande de restauration est générée pour vérifier une configuration finale après reconfiguration, c'est-à-dire vérifier que le numéro d'identification PNR_init est associé au code FIN après reconfiguration. Cette commande est mémorisée dans un jeu de commandes de restauration, par exemple un fichier. Les commandes de restauration ne sont utilisées que lorsqu'il est nécessaire de reconfigurer des équipements dans une configuration initiale (PRE-MOD). De même, chaque commande de type CheckConf de l'eSB visant un code FIN d'un équipement associé à un nouveau numéro d'identification est analysée afin, notamment, de générer une commande de restauration ayant pour objet de demander, par exemple à l'aide d'une fenêtre d'affichage de type pop-up, la réinstallation de l'équipement précédent pour le code FIN considéré. Comme décrit ci-après une telle commande peut être combinée avec une commande de synchronisation, de réinitialisation (reset) ou de déclenchement / enclenchement d'alimentation électrique afin d'attendre que l'équipement soit opérationnel, après reconfiguration, pour tester sa configuration. En outre, une seconde commande de restauration est générée pour vérifier une configuration finale après reconfiguration, c'est-à-dire vérifier que le numéro d'identification PNR_init (correspondant à l'équipement précédent pour le code FIN considéré) est associé au code FIN après reconfiguration. Ces commandes sont mémorisées dans un jeu de commandes de restauration, par exemple un fichier. Par ailleurs, chaque commande de type UpLoad de l'eSB visant le chargement d'un élément logiciel ayant le numéro d'identification PNR_new, associé au code FIN, est, en cas de succès (e.g. résultat de type « OK »), analysée afin, notamment, de générer une commande de restauration de type UpLoad visant le chargement d'un élément logiciel ayant le numéro d'identification PNR_init, associé au code FIN. Cette commande est mémorisée dans un jeu de commandes de restauration, par exemple un fichier, avec un numéro de séquence qui est ensuite incrémenté. Lors de l'exécution de commandes de type UpLoad de l'eSB, en cas d'échec (e.g. le résultat est « KO ») et si, selon le critère de sélection, des équipements doivent être reconfigurés dans un état initial (avec ou sans confirmation d'un opérateur de maintenance), les commandes de restauration préalablement générées sont concaténées dans un eSB spécifique permettant la reconfiguration des équipements selon un schéma d'exécution classique d'eSB. Un tel eSB peut être généré et exécuté automatiquement, avec ou sans confirmation d'un opérateur de maintenance. La figure 1 illustre schématiquement certaines étapes d'un algorithme permettant de relancer le chargement d'un élément logiciel dans un équipement et/ou réinitialiser des équipements suite à la détection d'une erreur de chargement d'un élément logiciel. Comme illustré, une première étape (étape 100) a ici pour objet d'initialiser les variables i et step aux valeurs zéro et un, respectivement, i représentant un index sur des commandes d'un eSB et step représentant un index sur des commandes de restauration de configuration générées en vue de la création d'un eSB de restauration. Dans des étapes suivantes, la commande de l'eSB en cours de traitement, ayant l'index i, appelée inst(i), est sélectionnée (étape 105) puis exécutée (étape 110). Un test est ensuite effectué pour déterminer si l'exécution de l'instruction sélectionnée s'est déroulée normalement ou non (étape 115), c'est-à-dire, par exemple, si son résultat a la valeur « OK» ou la valeur « KO ». Si l'exécution de la commande sélectionnée s'est passée normalement, un test est effectué pour déterminer le type de la commande sélectionnée (étape 120). S'il s'agit d'une commande de type CheckConfiglnit, c'est-à-dire une commande de type CheckConfig ayant pour objet de déterminer la configuration d'un élément logiciel d'un équipement avant de la modifier, le couple formé du code FIN et du numéro d'identification PNR init associés est déterminé (étape 125). Ces valeurs sont typiquement obtenues de la commande sélectionnée. Une commande de restauration de type CheckConf, dont les paramètres correspondent au couple (FIN, PNR init), est ensuite générée et mémorisée temporairement (étape 130). La valeur de l'index i est alors incrémentée de un et, si elle existe, la commande suivante de l'eSB est sélectionnée (étape 105) pour être traitée à son tour. Si la commande sélectionnée est une commande de type CheckConfigHW, c'est-à-dire une commande de type CheckConfig visant un changement d'équipement (code FIN affecté par un nouveau numéro d'identification PNR new), une commande de restauration ayant pour objet de demander, par exemple à l'aide d'une fenêtre d'affichage de type pop-up, la réinstallation de l'équipement précédent dont le numéro d'identification est PNR HWp, pour le code FIN considéré, est générée (étape 135). Comme indiqué précédemment, une telle commande peut être combinée avec une commande de synchronisation, de réinitialisation (reset) ou de déclenchement / enclenchement d'alimentation électrique afin d'attendre que l'équipement soit opérationnel, après reconfiguration, pour tester sa configuration. Le numéro d'identification PNR HWp correspondant à l'équipement précédent pour le code FIN considéré est alors déterminé (étape 140) et une seconde commande de restauration est générée pour vérifier une configuration finale après reconfiguration (étape 145), c'est-à-dire vérifier que le numéro d'identification PNR init (correspond au numéro d'identification PNR HWp) est associé au code FIN après reconfiguration. Ces commandes de restauration sont mémorisées temporairement. La valeur de l'index i est alors incrémentée de un et, si elle existe, la commande suivante de l'eSB est sélectionnée (étape 105) pour être traitée à son tour. Si la commande sélectionnée est une commande de type UpLoad (dont l'objet est le chargement d'un élément logiciel), une commande de restauration de type UpLoad est générée (étape 150) avec, comme paramètres, le couple (FIN, PNR init) tel que défini par l'exécution précédente d'une commande précédente de type CheckConfiglnit. Cette commande est mémorisée temporairement avec un numéro de séquence dont la valeur est égale à celle de la variable step qui est ensuite incrémentée de un (étape 155). La valeur de l'index /est alors incrémentée de un et, si elle existe, la commande suivante de l'eSB est sélectionnée (étape 105) pour être traitée à son tour. S'il s'agit d'une commande d'un autre type, un traitement approprié peut, le cas échéant, être effectué (étape 160). Si l'exécution de la commande sélectionnée ne s'est pas passée 20 normalement (étape 115), un critère de sélection tel que celui décrit précédemment est évalué (étape 165). Si le critère de sélection est satisfait, l'algorithme retourne à l'étape 110 et la commande sélectionnée est exécutée à nouveau. Dans le cas contraire, si le critère de sélection n'est pas satisfait et, le cas échéant, après 25 confirmation d'un opérateur, les équipements dont la configuration a été modifiée par l'eSB en cours d'exécution sont reconfigurés selon la configuration initiale. A ces fins, les commandes mémorisées temporairement sont concaténées dans un eSB de restauration (étape 170) en tenant compte des 30 numéros de séquence. L'eSB de restauration est ensuite exécuté (étape 175), de façon classique, pour permettre la reconfiguration d'équipements selon les commandes mémorisées temporairement, dans l'ordre des numéros de séquence. Comme décrit précédemment, une interface peut être mise en oeuvre lors de l'exécution d'eSB, et donc d'eSB de restauration, pour ajouter une interactivité à l'exécution d'eSB. Cette interactivité peut, par exemple, permettre à un opérateur de saisir ou confirmer une commande et d'être informé de l'évolution de l'exécution d'un eSB. Elle peut également permettre l'échange de données avec d'autres systèmes et autoriser, par exemple, la mise en oeuvre de fonction de synchronisation, de réinitialisation (reset), de déclenchement / enclenchement d'alimentation électrique d'un équipement, de mise en mode opérationnel d'un équipement, etc.. Il est ainsi possible, à partir de la configuration du système central de gestion de configuration, de générer des commandes de restauration utilisant une telle interactivité avec un opérateur de maintenance et/ou un autre système. La transmission d'informations à un opérateur peut être réalisée par affichage, par exemple par la génération de fenêtres de type pop-up, sur un écran d'un aéronef ou sur un écran d'un système au sol en fonction de paramètres prédéterminés. La figure 2 illustre un exemple de mise en oeuvre d'une interface homme-machine permettant, à partir de commandes eSB, l'affichage d'informations. Un eSB 200 est ici traité par un système central de gestion de configuration 205. L'eSB 200 comprend, par exemple, la commande suivante : Lors du traitement de cette commande, le système central de gestion de configuration 205 fait ici appel à une interface de communication 210 pour adresser le message au système sur lequel il doit être affiché (ici, à titre d'exemple, la configuration du système central de gestion de configuration désigne un système au sol). L'interface de communication 210 de l'aéronef transmet alors le message à une interface de communication 215 d'un système au sol (dont une adresse est donnée par configuration). Le système au sol est ici un centre de contrôle de maintenance (MCC, sigle de Maintenance Control Center en terminologie anglo-saxonne). A sa réception, le message est ensuite transmis à une interface 220 de type IHM permettant l'affichage de données sur un écran 225 et la saisie de données par un opérateur 230. Le message « Entrer votre identifiant et votre mot de passe » apparaît alors sur l'écran 225. Une telle interface permet d'afficher de simples messages et d'afficher des messages demandant une confirmation ou la saisie de données telles qu'un identifiant et un mot de passe, un numéro d'identification, etc.. L'interface mise en oeuvre permet également, de préférence, d'échanger des données avec d'autres systèmes via, par exemple, un système 10 de gestion des ressources (system manager). L'interface permet ainsi, notamment, de transmettre des commandes et des requêtes pour déverrouiller un équipement et permettre sa mise à jour (e.g. passage en mode chargement d'un LRU concerné par un eSB en cours d'exécution) et réinitialiser (reset) un équipement suite à un chargement lorsque ce dernier n'offre pas de fonction de 15 réinitialisation automatique. La transmission de ces commandes et requêtes est avantageusement complétée de la gestion de la relance automatique d'exécution d'une commande en fonction d'un critère de sélection, par exemple l'exécution répétée d'une commande jusqu'à l'obtention d'un message de 20 réussite ou durant un temps prédéterminé (permettant le traitement de fonction ne pouvant être interrompue pour des raisons de sécurité). La figure 3 illustre un exemple de mise en oeuvre d'une interface permettant, à partir de commandes eSB, de modifier le mode de configuration d'un équipement pour permettre sa mise à jour. 25 Un eSB 200 est ici traité par un système central de gestion de configuration 205 (étape 0). L'eSB 200 comprend, par exemple, la commande suivante : Lors du traitement de cette commande, le système central de gestion 30 de configuration 205 fait appel au système de gestion des ressources 300 (étape 0) pour lui demander le déverrouillage de l'équipement visé (ici l'équipement 305 ayant le code FIN 10E1). Si l'équipement 305 peut être déverrouillé, le système de gestion des ressources 300 adresse une requête de déverrouillage à cet équipement (étape 0) et en informe le système central de gestion de configuration (étape 0) par un message de type « unlock OK'>. Dans le cas contraire, si l'équipement 305 ne peut être déverrouillé, le système de gestion des ressources 300 en informe le système central de gestion de configuration par un message de type « unlock KO » ou « Call-back in x minutes ». Si l'équipement 305 peut être déverrouillé, la commande suivante de l'eSB, visant typiquement le chargement d'un élément logiciel dans l'équipement 305 (e.g. « UpLoad FIN « 10E1SW1 » with « PNR xx » »), est exécutée (étape 0). L'interface permet en outre, de préférence, de transmettre des requêtes d'obtention d'information de configuration d'équipements particuliers. De telles requêtes, adressées à ces équipements ou à des systèmes de gestion centralisée d'informations de configuration, permettent, en particulier, d'obtenir des informations de configuration concernant des équipements ne disposant pas de fonction d'émission périodique de leur configuration. L'interface permet également, de préférence, de transmettre des commandes et requêtes de déclenchement / enclenchement d'alimentation électrique d'équipements permettant, en particulier, à un opérateur de changer un équipement avant le chargement d'un élément logiciel. Enfin, toujours selon un mode de réalisation particulier, l'interface permet de transmettre des commandes et requêtes de test d'équipements afin de tester leur fonctionnement. Comme décrit précédemment, les commandes de restauration peuvent utiliser des commandes de synchronisation permettant par exemple à certaines tâches de chargement ou de redémarrage, en utilisant des temporisations d'une durée prédéterminée ou l'attente d'événements donnés, de s'exécuter automatiquement, par exemple lorsque la remise en route d'un équipement, après mise à jour, n'est pas immédiate ou implique le rétablissement de liens de communications. De telles commandes sont, de préférence, générées automatiquement à partir de commandes de l'eSB traité, à partir de la configuration du système central de gestion de configuration. La figure 4 illustre schématiquement un dispositif adapté à mettre en oeuvre certains modes de réalisation, au moins partiellement, en particulier l'algorithme décrit en référence à la figure 1. Le dispositif représenté est de préférence un dispositif standard, par exemple un ordinateur, un calculateur ou un serveur. Le dispositif 400 comporte ici un bus interne de communication 405 auquel sont reliés : - une unité centrale de traitement ou microprocesseur 410 (CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ; - une mémoire morte 415 (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 420 (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 440 adaptée à transmettre et à recevoir des données vers et depuis un réseau de communication, filaire ou non. Le dispositif 400 dispose également, de préférence, des éléments suivants : - un disque dur 425 pouvant comporter les programmes précités et des données traitées ou à traiter selon l'invention ; et - un lecteur de cartes mémoires 430 adapté à recevoir une carte 25 mémoire 435, ou tout autre système de stockage externe de données, et à y lire ou à y écrire des données traitées ou à traiter selon l'invention. Le bus interne de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le dispositif 400 ou reliés à lui. La représentation du bus interne n'est pas limitative et, notamment, 30 le microprocesseur 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. 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 425 ou en mémoire morte 415. Selon une variante, la carte mémoire 435 peut contenir des données, 5 notamment un eSB ou eSB de restauration et/ou des éléments logiciels à charger, ainsi que le code exécutable des programmes précités qui, une fois lu par le dispositif 400, est stocké dans le disque dur 425. Selon une autre variante, le code exécutable des programmes pourra être reçu, au moins partiellement, par l'intermédiaire de l'interface de 10 communication 440, 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 400 avant d'être exécutés. 15 Le microprocesseur 410 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 425 ou dans la mémoire morte 415 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 20 mémoire non volatile, par exemple le disque dur 425 ou la mémoire morte 415, sont transférés dans la mémoire vive 420 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. 25 L'appareil de communication comportant le dispositif selon l'invention peut également être un appareil programmé. Cet appareil contient alors le code du ou des programmes informatiques par exemple figé dans un circuit intégré à application spécifique, aussi appelé ASIC (acronyme d'Application-Specific Integrated Circuit en terminologie anglo-saxonne). 30 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 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. En particulier, il est observé que la combinaison et l'enchaînement astucieux de commandes d'interface (avec des systèmes) et de synchronisation avec des commandes de type CheckConf permettent de réaliser des fiches d'intervention pour des opérateurs de maintenance adaptés, notamment, au remplacement de pièces mécaniques. 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 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. REVENDICATIONS1. Procédé pour ordinateur de gestion de mises à jour logicielles d'un ensemble d'équipements d'un système à partir d'indications d'un bulletin de service, ce procédé étant caractérisé en ce que les indications dudit bulletin de service sont accessibles sous forme de commandes et en ce qu'il comprend les étapes suivantes, - sélection (105) et exécution (110) d'une commande visant au moins une indication dudit bulletin de service, ladite commande sélectionnée visant la modification de la configuration d'un équipement dudit système ; - si le résultat d'exécution de ladite commande sélectionnée est conforme à un résultat attendu, génération (150), selon le type de ladite commande exécutée, d'au moins une commande de restauration, ladite au moins une commande de restauration permettant la reconfiguration dudit équipement dans sa configuration précédent l'exécution de ladite commande sélectionnée ; et - si le résultat d'exécution de ladite commande sélectionnée n'est pas conforme à un résultat attendu, exécution (175) d'au moins une commande de restauration préalablement générée. 2. Procédé selon la revendication 1 comprenant en outre une étape d'exécution d'une commande de test de configuration dudit équipement, ladite commande de test de configuration étant exécutée avant celle de ladite commande sélectionnée, au moins un paramètre de ladite commande de restauration générée correspondant à un résultat d'exécution de ladite commande de test de configuration. 3. Procédé selon la revendication 2 comprenant en outre une étape de génération (130) d'une commande de restauration de test de configuration dudit équipement, au moins un paramètre de ladite commande de restauration de test de configuration générée correspondant à un résultat d'exécution de ladite commande de test de configuration. 4. Procédé selon la revendication 2 ou la revendication 3 selon lequel ladite commande de test de configuration dudit équipement vise au moins une indication dudit bulletin de service. 5. Procédé selon l'une quelconques des revendications 1 à 4 comprenant en outre une étape de concaténation (170) de commandes de restauration préalablement générées, lesdites commandes de restauration préalablement générées étant concaténées selon un ordre défini par un numéro de séquence associé auxdites commandes de restauration préalablement générées. 6. Procédé selon l'une quelconque des revendications 1 à 5 comprenant en outre une étape de génération (135) d'une commande de restauration d'affichage d'un message à destination d'un opérateur. 7. Procédé selon la revendication 6 selon lequel ladite commande de restauration d'affichage d'un message est générée lorsque ladite commande sélectionnée vise la configuration d'un équipement nouveau. 8. Procédé selon l'une quelconque des revendications 1 à 7 comprenant en outre une étape d'évaluation (165) d'un critère de sélection en cas d'échec d'exécution de ladite commande sélectionnée, ladite étape d'exécution de ladite commande sélectionnée étant répétée si ledit critère de sélection est vérifié. 9. Procédé selon la revendication 8 selon lequel ledit critère de sélection est basé sur un nombre d'éléments logiciels chargés avec succès dans ledit équipement, un nombre d'éléments logiciels à charger dans ledit équipement, un nombre d'équipements dont la configuration doit être modifiée, et/ou un code d'erreur d'exécution de ladite commande sélectionnée. 10. Procédé selon la revendication 8 ou la revendication 9 comprenant en outre une étape de comptage du nombre d'exécutions de ladite commande sélectionnée, ladite commande sélectionnée ne pouvant être exécutée qu'un nombre de fois limité déterminé par un seuil prédéterminé. 11. Procédé selon l'une quelconque des revendications 1 à 10 comprenant en outre une étape de génération d'une commande de restauration de synchronisation pour l'exécution de commandes de restauration. 12. Procédé selon l'une quelconque des revendications 1 à 11 comprenant en outre une étape de génération d'une commande de restauration de réception d'au moins une donnée pour l'exécution de commandes de restauration. 13. 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 à 12 lorsque ledit programme est exécuté sur un ordinateur. 14. Dispositif comprenant des moyens adaptés à la mise en oeuvre 10 de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 12. 15. Aéronef comprenant le dispositif selon la revendication 14.