FR2943152A1 - Procedes et dispositifs de telechargement automatise de logiciels, dans un appareil tel qu'un aeronef, comprenant la mise a jour de la documentation associee - Google Patents

Abstract

L'invention a notamment pour objet des procédés et des dispositifs de téléchargement automatisé de logiciels, dans un appareil tel qu'un aéronef, comprenant la mise à jour de la documentation associée. Après avoir reçu (125) une indication relative à une modification d'une application logicielle, une commande permettant d'effectuer automatiquement la mise à jour requise est transmise (160) à un appareil comprenant cette application logicielle. En réponse, une indication relative à l'exécution de la commande est reçue (165) et un rapport d'exécution de la commande est transmis au constructeur pour lui permettre de mettre à jour la documentation de l'appareil en conséquence.

Description

La présente invention concerne la gestion des applications logicielles embarquées dans des appareils tels que des aéronefs et plus particulièrement des procédés et des dispositifs de téléchargement automatisé de logiciels, dans un appareil spécifique, comprenant la mise à jour de la documentation associée selon les modifications effectives apportées.

De façon générale, chaque aéronef fabriqué est livré à une compagnie aérienne dans une configuration certifiée. Cette dernière est alors décrite dans un document fourni à la compagnie aérienne pour lui permettre de gérer la configuration de ces aéronefs, c'est-à-dire, en particulier, pour identifier chacun des éléments majeurs des aéronefs.

Le premier document de configuration fourni avec les aéronefs est appelé AIR (sigle d'Aircraft Inspection Report en terminologie anglo-saxonne). Ils constituent une sorte de photographie de la configuration des aéronefs lors de leur livraison. L'AIR contient la liste des codes appelés P/N (sigle de part number en terminologie anglo-saxonne) de tous les équipements dont le DAL (sigle de Design Assurance Level en terminologie anglo-saxonne) est supérieur à D, c'est-à-dire dont les conséquences en cas de panne affectant ces équipements sont strictement supérieures au seuil appelé MINOR. L'AIR contient également la liste de tous les PIN des composants logiciels embarqués, quel que soit leur niveau de DAL.

Le P/N identifie la solution technique appliquée à l'élément mécanique, électronique ou logiciel concerné pour accomplir la fonction à laquelle elle est destinée. Un P/N 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 P/N est un identifiant variable dans le temps selon le fabricant et la version. Par ailleurs, une 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. 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 sont remplacés par d'autres. Par exemple, élément ayant un code PIN [A] peut être remplacé par un autre ayant un code PIN [B] offrant certains avantages. Le remplacement d'un élément ayant un code PIN [A] par un autre ayant un code PIN [B] 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. Ainsi, la configuration d'un aéronef sortant d'une chaîne de 15 fabrication peut être déterminée par un AIR et un ensemble de MOD résultant d'une évolution du modèle de l'aéronef. Cependant, s'il semble évident qu'un aéronef sortant d'une chaîne de production bénéficie des toutes dernières améliorations apportées par les plus récentes MOD, les constructeurs proposent généralement aux compagnies 20 aériennes de bénéficier de ces mêmes 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 à 25 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 PIN [A], et celui après 30 application, par exemple l'utilisation de l'élément ayant pour code PIN [B], 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. Il existe plusieurs types de SB : - les SB dont l'application est obligatoire pour des raisons de sécurité, appelés SB Mandatory en terminologie anglo-saxonne. Ce type de SB est souvent gratuit pour les compagnies aériennes. Le constructeur est systématiquement informé de l'application de ce type de SB, - les SB dont l'application est fortement conseillée par le constructeur à ses compagnies aériennes clientes, et, - les SB optionnels pour lesquels la décision d'application est entièrement laissée au choix des compagnies aériennes. Les deux derniers types de SB sont généralement payants pour les compagnies aériennes. Les constructeurs ne sont pas systématiquement informés par les compagnies aériennes de leur application (aéronefs concernés, date d'application). Ainsi, en raison de cet éventuel manque d'information, il peut être difficile, voir impossible, pour le constructeur, de fournir la documentation correspondant à la nouvelle configuration. Cependant, les compagnies aériennes étant garante devant leur autorité de tutelle, qu'elles maîtrisent la configuration des aéronefs qu'elles exploitent, elles doivent, après avoir appliqué un SB, mettre à jour le dossier décrivant la configuration de l'aéronef. Lors de leur livraison, les aéronefs sont pourvus d'une documentation destinée aux pilotes, comprenant notamment le manuel de vol (AFM), la description des procédures opérationnelles (FCOM) et un manuel (WBM) d'équilibrage et de gestion des charges, d'une documentation de maintenance, comprenant en particulier un manuel de maintenance (AMM) contenant différentes procédures de maintenance de l'aéronef, un manuel d'analyse des conditions de pannes (TSM) et un document (IPC) décrivant les caractéristiques physiques extérieures de tous les équipements démontables de l'aéronef ainsi que tous les P/N autorisés à être montés sur celui-ci, ainsi que la documentation destinée aux équipages de cabine, constituée notamment du document décrivant les procédures opérationnelles à l'usage des personnels de cabine (CCOM). Les constructeurs mettent à jour et gèrent de façon centralisée une documentation enveloppe couvrant toutes les flottes et tous les aéronefs livrés pour une même famille d'aéronefs. Une documentation adaptée est ensuite mise à la disposition des compagnies aériennes, selon la configuration connue par le constructeur de l'empilement des MODISB appliqués par les compagnies aériennes. Le fonctionnement des systèmes décrits dans les différents manuels, leur mode d'opération ainsi que les procédures d'utilisation et autres informations similaires peuvent être amenés à évoluer en fonction des améliorations apportées. La documentation mise à disposition par les constructeurs doit donc mise à jour en fonction des MODISB appliquées sur chaque aéronef.

Ainsi, il se pose un problème de gestion de la configuration des aéronefs et de mise à jour de leur documentation lié aux facteurs suivants, - configuration personnalisée par les compagnies aériennes en fonction des options sélectionnées, - nombre de compagnies aériennes clientes des constructeurs pour une famille d'aéronef donnée, - différentes solutions techniques autorisées pour chaque équipement d'un aéronef, et, - sélection dans le temps de la version de chaque élément, selon l'application des MODISB, de chaque aéronef de la flotte de chacune des 25 compagnies aérienne. Ainsi, outre la difficulté de gestion de la documentation, un constructeur peut, lorsqu'une compagnie aérienne ne transmet pas, ou transmet tardivement, l'application de MODISB sur un ou plusieurs de ses aéronefs, livrer une documentation qui n'est pas en conformité avec la 30 configuration réelle de l'aéronef concerné. 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 de mise à jour automatisée d'au moins une application logicielle, dans un appareil, comprenant la mise à jour d'une documentation associée audit appareil, ladite mise à jour de ladite au moins une application logicielle étant effectuée par l'exploitant dudit appareil en fonction d'au moins une indication relative à une modification de ladite au moins une application logicielle, reçue dudit constructeur, ladite documentation étant mise à jour par le constructeur dudit appareil en fonction de la mise à jour de ladite au moins une application logicielle effectuée dans ledit appareil, ce procédé comprenant les étapes suivantes, - réception de ladite au moins une indication relative à ladite modification de ladite au moins une application logicielle ; - transmission audit appareil d'au moins une commande permettant d'effectuer automatiquement ladite mise à jour de ladite au moins une application logicielle ; - réception dudit appareil d'au moins une indication relative à l'exécution de ladite au moins une commande ; et, - transmission d'un rapport d'exécution de ladite au moins une commande audit constructeur, ledit rapport d'exécution permettant audit constructeur de mettre à jour ladite documentation dudit appareil en réponse à ladite mise à jour de ladite au moins une application logicielle réellement effectuée dans ledit appareil. Le procédé selon l'invention permet ainsi à l'exploitant de l'appareil de contrôler facilement et économiquement les mises à jour logicielles.

Concernant les aéronefs, le procédé selon l'invention permet de réduire le temps d'immobilisation d'un aéronef. Le procédé selon l'invention offre en outre au constructeur des moyens pour maintenir à jour une documentation cohérente selon les mises à jour effectives apportées aux applications logicielles.

Selon un mode de réalisation particulier, le procédé comprend en outre les étapes suivantes, - transmission d'une requête comprenant une référence à ladite au moins indication relative à ladite modification de ladite au moins une application logicielle pour obtenir une description de ladite au moins une commande ; et, - réception de ladite description de ladite au moins une commande.

Le procédé selon l'invention offre ainsi une solution de mise à jour logiciel facile à mettre en oeuvre et ne nécessitant aucun développement ou aucune connaissance particulier pour l'exploitant. De façon avantageuse, le procédé comprend en outre une étape de réception de ladite documentation mise à jour.

L'invention a également pour objet un procédé pour ordinateur de mise à jour automatisée d'au moins une application logicielle, dans un appareil, comprenant la mise à jour d'une documentation associée audit appareil, ladite mise à jour de ladite au moins une application logicielle étant effectuée par l'exploitant dudit appareil en fonction d'au moins une indication relative à une modification de ladite au moins une application logicielle, reçue dudit constructeur, ladite documentation étant mise à jour par le constructeur dudit appareil en fonction de la mise à jour de ladite au moins une application logicielle effectuée dans ledit appareil, ce procédé comprenant les étapes suivantes, - réception d'au moins une commande permettant d'effectuer automatiquement ladite mise à jour de ladite au moins une application logicielle ; - exécution de ladite au moins une commande ; - production d'un rapport d'exécution de ladite au moins une 25 commande ; et, - transmission dudit rapport d'exécution audit constructeur, ledit rapport d'exécution permettant audit constructeur de mettre à jour ladite documentation dudit appareil en réponse à une mise à jour de ladite au moins une application logicielle réellement effectuée dans ledit appareil. 30 Le procédé selon l'invention permet ainsi à l'exploitant de l'appareil de contrôler facilement et économiquement les mises à jour logicielles. Concernant les aéronefs, le procédé selon l'invention permet de réduire le temps d'immobilisation d'un aéronef. Le procédé selon l'invention offre en outre au constructeur des moyens pour maintenir à jour une documentation cohérente selon les mises à jour effectives apportées aux applications logicielles.

Selon un mode de réalisation particulier, ledit rapport d'exécution est transmis audit constructeur via un système dudit exploitant. Ainsi, il n'est pas nécessaire d'utiliser des moyens de communication particuliers entre l'appareil et le constructeur. Avantageusement, ladite au moins une commande comprend une 10 commande de téléchargement d'au moins un composant logiciel pour optimiser la mise à jour logicielle. Selon un mode de réalisation particulier, le procédé comprend en outre une étape de validation de ladite mise à jour de ladite au moins une application logicielle pour améliorer la fiabilité de la mise à jour logicielle. 15 Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de mise à jour d'une copie de ladite documentation mémorisée dans ledit appareil de telle sorte que la documentation mémorisée corresponde à la configuration réelle de l'appareil. L'invention a aussi pour objet un programme d'ordinateur 20 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. L'invention a également pour objet un aéronef comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé décrit 25 précédemment, ledit appareil correspondant audit aéronef. 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 le système de mise à jour de 30 la documentation d'un aéronef suite à la transmission d'un bulletin de service (SB) par un constructeur, ou un de ses fournisseurs, à une compagnie aérienne ; - la figure 2 illustre schématiquement un exemple d'algorithme mis en oeuvre dans un système informatique d'un constructeur pour mettre à jour sa documentation relative à un aéronef particulier exploité par une compagnie aérienne suite à la modification de la configuration de cet aéronef ; - la figure 3 illustre schématiquement un exemple d'algorithme mis en oeuvre dans un système informatique d'une compagnie aérienne pour modifier automatiquement, de préférence après acceptation, la configuration d'un aéronef qu'elle exploite et permettre au constructeur de mettre à jour sa documentation relative à cet aéronef en conséquence ; - la figure 4 illustre schématiquement un exemple d'algorithme mis en oeuvre dans un système informatique d'un aéronef pour modifier automatiquement sa configuration et permettre au constructeur de mettre à jour sa documentation relative à cet aéronef en conséquence ; et, - la figure 5 illustre schématiquement un dispositif adapté à mettre en oeuvre chacun des algorithmes illustrés sur les figures 2 à 4. Conformément à l'invention, les dispositifs et procédés de téléchargement automatisé des composants logiciels dans des équipements d'aéronefs comprennent des mécanismes pour mettre à jour la documentation électronique associée à chaque aéronef. En vérifiant l'application effective des MOD, les documents électroniques représentent ainsi les configurations exactes des aéronefs. En d'autres termes et de façon simplifié, en téléchargeant un composant logiciel dans un équipement d'un aéronef, une information selon laquelle ce composant logiciel a été installé est transmise au constructeur pour lui permettre de mettre à jour la documentation. Celle-ci est alors transmises à l'aéronef après mise à jour. Il convient tout d'abord de rappeler que les constructeurs d'aéronef ainsi que leurs fournisseurs ont constaté que les évolutions de leurs équipements étaient essentiellement liées à l'évolution rapide et fréquente des composants logiciels installés dans la mémoire de ces équipements.

Ce constat a conduit au développement d'équipements dont les composants logiciels sont téléchargeables permettant ainsi l'évolution des équipements sans changement matériel. Certains équipements sont mis à jour à l'aide de systèmes, 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. D'autres équipements sont mis à jour à l'aide de dispositifs portables, appelés PDL (sigle de Portable Data Loader en terminologie anglo-saxonne). D'autres équipements encore sont mis à jour dans des ateliers après avoir été démontés. Pour permettre de déterminer la configuration de chaque aéronef, les éléments matériels des équipements ainsi que leurs composants logiciels sont, de préférence, chacun identifié par des FIN, P/N et MSN (sigle de Manufacturer Serial Number en terminologie anglo- saxonne, désigne le numéro de série d'un aéronef). Par ailleurs, la généralisation des outils informatiques permet d'utiliser une documentation électronique au sol ou à bord des aéronefs. La documentation précédemment livrée sous forme papier existe donc maintenant sous forme électronique. Un navigateur documentaire, appelé browser en terminologie anglo-saxonne, permet de passer efficacement d'une page à une autre et d'un manuel à l'autre. L'ensemble de la documentation d'un aéronef peut ainsi être contenu dans des CDs (sigle de Compact Disc en terminologie anglo-saxonne) ou des DVDs (sigle de Digital Versatile Disc en terminologie anglo-saxonne) aisément manipulables.

Ainsi, de façon générale, l'invention vise à combiner des fonctions de téléchargement d'applications logicielles avec l'utilisation d'une documentation électronique avec pour maintenir à jour la documentation de chaque aéronef. La figure 1 illustre schématiquement le système de mise à jour de la documentation d'un aéronef 100 suite à la transmission d'un SB par un constructeur 105 ou un de ses fournisseurs 110 à une compagnie aérienne 115. La référence 100 désigne le système avionique d'un aéronef, ou une partie de celui-ci, comprenant un ou plusieurs calculateurs appartenant à un ou plusieurs domaines tels que le domaine sécurisé de type ACD (sigle d'Aircraft Control Domain en terminologie anglo-saxonne) et le domaine moins sécurisé de type AISD (sigle d'Aircraft Information System Domain en terminologie anglo-saxonne). Ce système permet notamment de communiquer avec un système externe à l'aéronef, de recevoir et d'installer des composants logiciels, de produire un rapport d'exécution ainsi qu'un rapport sur la configuration de l'aéronef et de communiquer ces rapports à un système externe. De la même façon, les références 105, 110 et 115 désignent des systèmes informatiques, comprenant par exemple un ou plusieurs serveurs ou ordinateurs, d'un constructeur, de ses fournisseurs et d'une compagnie aérienne, respectivement. Le système du constructeur 105 comprend ou est associé à une base de données 120 dans laquelle sont mémorisés les documents électroniques devant être mis à jour selon l'application des MOD.

Ces systèmes informatiques permettent de recevoir et transmettre des données. De façon générale, ils permettent également d'exécuter des applications pour traiter des données. Après avoir identifié une modification à effectuer sur un aéronef 100, le constructeur 105 créé un SB, sous forme électronique, et le transmet à la compagnie aérienne 115 (étape 125). Comme décrit précédemment, le SB est un document utilisé pour notifier officiellement un changement technique à une compagnie aérienne. Le SB est ici notifié à la compagnie aérienne 115, de préférence à son centre de maintenance, par exemple par courrier électronique. Lorsqu'un constructeur décide de l'application d'un MOD, il développe un objet électronique appelé eSB, tel qu'un fichier, qui contient des commandes pouvant être interprétées à bord d'un aéronef par un dispositif de type DLCS, par exemple pour télécharger automatiquement un composant logiciel dans un calculateur déterminé. L'eSB est de préférence sécurisé, par exemple chiffré à l'aide d'un 25 algorithme de chiffrement asymétrique de type RSA. De façon similaire, un SB peut être émis par un fournisseur 110 du constructeur 105. A nouveau, le SB est accompagné du développement d'un eSB. Cependant, pour des raisons de sécurité, le SB est, de préférence, transmis au constructeur 105 (étape 130) qui le vérifie et le transmet à la 30 compagnie aérienne 115 comme décrit précédemment (étape 125). L'eSB peut également être transmis au constructeur.

Selon la nature du SB et la stratégie de la compagnie aérienne, cette dernière peut décider d'appliquer ou non la modification liée au SB reçu. Dans l'affirmative, elle transmet une requête au constructeur 105 (étape 140) pour recevoir l'objet du SB tel que la mise à jour d'un composant logiciel. Cette requête peut être une réponse, sous forme de courrier électronique, à la notification du SB. En réponse à cette requête, le constructeur 105 transmet à la compagnie aérienne 115 l'eSB ainsi que la mise à jour correspondante d'un composant logiciel (étape 145). Alternativement, le constructeur 105 donne accès à ces éléments dans l'un de ses serveurs. Les adresses à partir desquelles peuvent être accédés ces éléments sont, de préférence, mémorisées dans l'aéronef. Elles peuvent également être précisées dans l'eSB. Si le SB est issu d'un fournisseur, l'eSB ainsi que la mise à jour correspondante d'un composant logiciel peuvent être transférés via le constructeur (étapes 150 et 145) ou directement (étape 155). Le fournisseur peut également donner un accès direct à ces éléments sur l'un de ses serveurs. Après avoir reçu l'eSB ainsi qu'éventuellement les mises à jour correspondantes d'un composant logiciel, la compagnie aérienne 115 vérifie les éléments reçus, notamment leur provenance et leur pertinence avant de les transférer à l'aéronef 100 via des moyens de communication bord-sol ou via des moyens portables (étape 160) et lancer l'exécution de l'eSB. Les moyens de communication bord-sol sont ici des moyens de communication standard tels que ceux définis, par exemple, par l'un des standards ARINC.

Après l'exécution de l'eSB, le téléchargement et l'installation des composants logiciels concernés, le système de téléchargement vérifie la conformité de la configuration en fonction des indications reçues dans l'eSB et établit un rapport d'exécution. Ce rapport d'exécution est transmis à la compagnie aérienne 115 (étape 165) ainsi qu'au constructeur 105 (étape 170).

Cette transmission est, de préférence, effectuée à l'aide des moyens de communication bord-sol.

Un tel rapport d'exécution est ici un rapport électronique produit par des fonctions de maintenance embarquées à bord des aéronefs, appelées Data Loading & Configuration Reporting function en terminologie anglo-saxonne, en réponse à l'exécution d'un eSB, c'est-à-dire suite à la mise à jour de composants logiciels dans des équipements. Il contient au moins une référence à un bulletin de service (SB) ou à un eSB ainsi que les références des équipements concernés. Alternativement, notamment en cas de panne des moyens de communication, la transmission peut comprendre une étape intermédiaire selon laquelle le rapport est chargé dans un dispositif portable connecté temporairement à l'aéronef puis connecté à un système de la compagnie aérienne, du constructeur ou à un autre système à partir duquel il est transmis à la compagnie aérienne ainsi qu'au constructeur. Selon une autre alternative, le rapport est simplement transmis par l'aéronef à la compagnie aérienne qui le transmet elle-même au constructeur. Selon un mode de réalisation particulier, le rapport d'exécution doit être validée par la compagnie aérienne pour que les modifications effectuées dans l'aéronef soient effectives. Dans le cas contraire, elles sont annulées. Le rapport d'exécution n'est avantageusement transmis au constructeur qu'après validation. A la réception du rapport d'exécution, de préférence validé, le constructeur met à jour la documentation électronique dans la base de données 120 selon les informations contenues dans ce rapport et les indications du SB correspondant (étape 175). La documentation mise à jour est alors transmise à la compagnie aérienne (étape 180) qui peut elle-même la transmettre ou en transmettre une partie à l'aéronef (étape 185) pour pouvoir y être consultée. La documentation mise à jour peut également être transmise directement à l'aéronef par le constructeur (étape 190). Il convient de remarquer ici que l'algorithme général illustré sur la 30 figure 1 peut être mis en oeuvre pour chaque MOD/SB ou de façon régulière, par exemple tous les mois.

Selon un mode de réalisation particulier, la documentation d'un aéronef est installée à son bord. Elle peut être une documentation propre à l'aéronef ou une documentation complète couvrant toutes les options et les configurations proposées par un constructeur pour la famille d'aéronefs concernée. Dans ce dernier cas, l'application de navigation documentaire installée à bord de l'aéronef permet alors de n'afficher que les données relatives aux options et à la configuration propres à chaque aéronef. Ainsi, lorsqu'une option est installée, il suffit d'activer le module correspondant dans la documentation.

Après avoir reçu et exécuté un eSB, la documentation de l'aéronef est localement mise à jour automatiquement en attendant la livraison officielle de la documentation du constructeur, de manière à ce que la version de la documentation configurée automatiquement soit en accord avec la configuration réelle de l'aéronef.

A titre d'illustration, il peut être décrit dans le document IPC décrivant les caractéristiques physiques extérieures de tous les équipements démontables de l'aéronef ainsi que tous les PIN autorisés à être montés que les équipements référencés 120 à 130 sont des équipements correspondant au code P/N A et que les équipements référencés 131 à 140 sont des équipements correspondant au code P/N B. L'IPC indique ainsi les paramètres suivants, Pour MSN = 120 to 130: EQP = [P/N A] Pour MSN = 131 to 140: EQP = [P/N B] Lorsque la compagnie aérienne applique un eSB dont l'objet est de remplacer l'équipement référencé 133 correspondant au code P/N B par un équipement correspondant au P/N A, l'IPC est automatiquement configuré. Il affiche alors les paramètres suivants, Pour MSN = 120 to 130, 133: EQP = [P/N A] Pour MSN = 131-132, 134 to 140: EQP = [P/N B] Des procédures similaires peuvent être mise en oeuvre pour mettre à jour les autres manuels tels que l'AMM, le TSM et le FCOM.

Suivant la taille de l'eSB à exécuter et/ou la disponibilité ou la politique d'utilisation des moyens de communications mis en oeuvre par la compagnie aérienne, l'eSB peut être généré selon différentes formes. Par exemple, l'eSB peut être généré sous la forme d'une composante conforme au standard ARINC 665 sécurisée importée à bord de l'aéronef via un media portable tel qu'une clé USB (sigle d'Universal Serial Bus en terminologie anglo-saxonne) ou un moyen de communication connecté au monde AISD de l'aéronef. La commande d'exécution du eSB peut également être transmise, par exemple, sous la forme d'un message sécurisé envoyé au DLCS du domaine ACD de l'aéronef via AMEX (sigle d'Aircraft Messaging Exchange en terminologie anglo-saxonne) ou au DLCS du domaine AISD via les applications appelées Communication Server et Communication Manager hébergées dans ce domaine.

Il convient de remarquer ici que l'outil de création des eSB produits par le constructeur peut être mis à la disposition des compagnies aériennes pour leur permettre de générer l'équivalent d'un eSB pour exécuter le téléchargement automatique de bases de données aéronautiques (indépendantes du périmètre d'intervention du constructeur) ou le téléchargement des fichiers de personnalisation qu'elles peuvent générer elles- mêmes. Un exemple non limitatif de code d'eSB, de type XML (sigle d'Extended Markup Language en terminologie anglo-saxonne), est donné en annexe.

Une première balise, appelée DLCS AUTOMATIC BATCH JOB, est ici utilisée pour décrire l'eSB. Les références utilisées peuvent être normalisées ou déterminées par les compagnies aériennes. La seconde balise, appelée SELECT DOMAIN, est utilisée pour identifier le domaine de l'aéronef dans lequel doit être effectuée la mise à jour logicielle, c'est-à-dire le domaine dans lequel doit être transféré le composant logiciel reçu. Ce domaine est ici le domaine appelé ACD .

La balise suivante, appelée UPLOAD COMMAND LIST, marque le début des commandes devant être analysées et exécutées par le DLCS pour télécharger le ou les composants logiciels à télécharger et à installer. La balise suivante, appelée STEP, indique un premier numéro de séquence dans les étapes de téléchargement et d'installation de composants logiciels. L'utilisation de séquences ordonnées peut être particulièrement pertinente dans certains cas pour optimiser l'utilisation de la bande passante du système de transmission bord-sol, pour organiser les séquences de téléchargements afin d'éviter une erreur d'installation ou lorsqu'un ou plusieurs équipements requièrent un ordre d'installation de différents composants logiciels. Les deux balises suivantes, appelées COMMAND, correspondent à des instructions de téléchargements. La première séquence se termine avec la balise appelée 15 END OF STEP. Une deuxième séquence est ensuite décrite. Le code correspondant à l'eSB se termine ensuite par les balises notées END OF UPLOAD COMMAND LIST et END OF JOB FOR AUTOMATIC UPLOADING. La figure 2 illustre schématiquement un exemple d'algorithme mis en 20 oeuvre dans un système informatique d'un constructeur pour mettre à jour sa documentation relative à un aéronef particulier exploité par une compagnie aérienne suite à la modification de la configuration de cet aéronef. L'algorithme représenté sur la figure 2 est adapté à coopérer avec les algorithmes représentés sur les figures 3 et 4. 25 Lorsque le système de gestion des modifications du constructeur reçoit un ordre pour produire un SB (étape 200), par exemple d'un bureau d'étude, ou à intervalle de temps prédéterminé (étape 205), c'est-à-dire lorsque l'intervalle de temps 8t entre l'instant présent et l'instant correspondant à la dernière transmission d'un SB atteint un seuil prédéterminé A, un SB doit être 30 produit et transmis à une compagnie aérienne. Le SB, appelé ici SB(i), peut être créé à partir des informations reçues par le système de gestion des modifications du constructeur ou être reçu directement d'un fournisseur comme illustré par la flèche entrante en trait pointillé (étape 210). Dans ce dernier cas, le système de gestion des modifications du constructeur doit, de préférence, le valider. Le bulletin de service SB(i) est alors transmis à la compagnie 5 aérienne (étape 215), par exemple sous forme de courrier électronique, comme illustré par la flèche sortante. Comme décrit précédemment, le SB(i) contient des informations relatives aux modifications devant être effectuées, à l'aéronef concerné ainsi qu'une indication visant à préciser le niveau d'obligation d'application de ce 10 bulletin tel qu'obligatoire, conseillé ou optionnel. En réponse à la transmission du SB(i), le système de gestion des modifications du constructeur peut recevoir une requête dont l'objet est l'obtention de l'eSB(i) correspondant à SB(i). Si une telle requête est reçue (étape 220), le système de gestion des 15 modifications du constructeur produit l'eSB(i) ou la récupère auprès de fournisseur à l'origine de SB(i) comme représenté par la flèche entrante en trait pointillé (étape 225). L'eSB(i) est ensuite transmis à la compagnie aérienne comme illustré par la flèche sortante (étape 230). Il convient de remarquer ici que, dans une variante, la requête visant 20 l'obtention de eSB(i) peut être directement transmise à un fournisseur, selon les conventions entre le fournisseur et la compagnie aérienne. Dans ce cas, les étapes 220, 225 et 230 sont mises en oeuvre dans un système du fournisseur. En réponse à la transmission d'eSB(i), le système de gestion des modifications du constructeur reçoit un rapport validé d'exécution de l'eSB(i) 25 (étape 235), appelé ici RVeSB(i). Le rapport validé d'exécution RVeSB(i) peut être reçu directement de l'aéronef concerné via les moyens de communication de l'aéronef ou de la compagnie aérienne via un réseau de communication standard tel qu'Internet. Le rapport validé d'exécution RVeSB(i) est reçu après que la 30 modification correspondante ait été effectuée et validée dans l'aéronef concerné. La modification effectuée peut correspondre à la modification visée par SB(i) ou à une partie de celle-ci.

Le rapport validé d'exécution RVeSB(i) est ensuite analysé et la documentation liée à l'aéronef est modifiée en conséquence (étape 240). Comme représenté sur la figure 2, la documentation est ici mémorisée dans une base de données 245. Comme représenté par la flèche sortante, la documentation mise à jour est alors transmise à la compagnie aérienne (étape 250), par exemple sous forme électronique via un réseau de communication tel qu'Internet ou sur un support électronique tel qu'un CD ou un DVD. La documentation électronique peut également être transmise directement à l'aéronef concerné.

La figure 3 illustre schématiquement un exemple d'algorithme mis en oeuvre dans un système informatique d'une compagnie aérienne pour modifier automatiquement, de préférence après acceptation, la configuration d'un aéronef qu'elle exploite et permettre au constructeur de mettre à jour sa documentation relative à cet aéronef en conséquence.

L'algorithme représenté sur la figure 3 est adapté à coopérer avec les algorithmes représentés sur les figures 2 et 4. Après avoir reçu un bulletin de service SB(i) (étape 300), le système de gestion des modifications de la compagnie aérienne l'analyse pour déterminer si elle l'applique ou non (étape 305). Le choix d'application des modifications est notamment guidé par la nature des modifications et leur caractère obligatoire, conseillé ou optionnel. Si la compagnie aérienne décide d'appliquer SB(i), elle transmet une requête pour obtenir l'eSB(i) correspondant comme illustré par la flèche sortante (étape 310). La requête pour obtenir l'eSB(i) peut être transmise au constructeur ou à un de ses fournisseurs. Le SB(i) comprend, de préférence, l'adresse, par exemple une adresse de courrier électronique, à laquelle doit être adressée la requête pour obtenir l'eSB(i). Il peut s'agir, par exemple, de l'adresse de l'expéditeur du SB(i). Cette requête peut comprendre une acceptation des conditions du constructeur et/ou d'un fournisseur, notamment l'acceptation de payer le prix de la modification. En réponse à la requête d'obtention de l'eSB(i), le système de gestion des modifications de la compagnie aérienne reçoit l'eSB(i). A sa réception (étape 315), il est vérifié (étape 320). La vérification consiste, par exemple, à l'authentifier et à le déchiffrer. Il est ensuite transmis à l'aéronef concerné comme indiqué par la flèche sortante (étape 325). Selon la nature des moyens de communication utilisés entre le système de gestion des modifications de la compagnie aérienne et le DLCS de l'aéronef, l'eSB(i) peut être transmis sous forme chiffrée ou non. Le chiffrement peut être identique à celui utilisé entre les systèmes de gestion des modifications du constructeur et de la compagnie aérienne, similaire ou différent. Il est, de préférence, basé sur un algorithme de chiffrement standard.

En réponse à la transmission d'eSB(i), le système de gestion des modifications de la compagnie aérienne reçoit un rapport d'exécution de l'eSB(i) (étape 330), appelé ici ReSB(i). Le rapport d'exécution ReSB(i) est reçu directement de l'aéronef concerné via les moyens de communication de l'aéronef ou de la compagnie aérienne.

Le rapport d'exécution ReSB(i) est reçu après que la modification correspondante ait été effectuée dans l'aéronef concerné, qu'elle ait été partiellement effectuée ou qu'elle n'ait pas été effectuée, par exemple pour des raisons techniques. Le rapport d'exécution ReSB(i) est ensuite analysé (étape 335) et un message de validation, appelé VeSB(i), est transmis à l'aéronef comme illustré par la flèche sortante (étape 340). Le message de validation a notamment pour objet de confirmer ou d'annuler la modification en fonction des éléments du rapport d'exécution. En réponse à ce message de validation, le système de gestion des modifications de la compagnie aérienne reçoit le rapport validé d'exécution RVeSB(i). Il contient, de préférence, les mêmes indications que le rapport d'exécution avec une indication supplémentaire de validation. Le rapport validé d'exécution peut être transmis au système de gestion des modifications du constructeur comme représenté par la flèche sortante (étape 345) si celui-ci ne lui est pas transmis directement par l'aéronef.

Alternativement, le système de gestion des modifications de la compagnie aérienne ne reçoit qu'un simple accusé réception de l'aéronef à partir duquel il produit le rapport validé d'exécution qui est transmis au système de gestion des modifications du constructeur. Suite à la modification de la configuration de l'aéronef, une documentation mise à jour est reçue du système de gestion des modifications du constructeur. A sa réception (étape 350), cette documentation est mémorisée (étape 355), par exemple dans une base de données 360. Si la documentation mise à jour n'a pas été transmise à l'aéronef, elle peut alors l'être comme représenté par la flèche sortante (étape 365). La figure 4 illustre schématiquement un exemple d'algorithme mis en oeuvre dans un système informatique d'un aéronef pour modifier automatiquement sa configuration et permettre au constructeur de mettre à jour sa documentation relative à cet aéronef en conséquence. L'algorithme représenté sur la figure 4 est adapté à coopérer avec les algorithmes représentés sur les figures 2 et 3.

Lorsque le système informatique de l'aéronef, par exemple le DLCS, reçoit l'eSB(i) (étape 400), il analyse la configuration de l'aéronef afin de la vérifier (étape 405). L'eSB(i) est ensuite exécuté pour permettre le téléchargement et l'installation des composants logiciels spécifiés (étape 410). Comme décrit précédemment, l'adresse à partir de laquelle peuvent être téléchargés ces composants logiciels est de préférence mémorisée dans l'aéronef (alternativement, l'eSB(i) peut comprendre une indication de cette adresse). La configuration de l'aéronef est ensuite à nouveau vérifiée (étape 415) et un rapport d'exécution ReSB(i), comprenant de préférence les différences de configuration précédent et suivant l'exécution de l'eSB(i) est produit (étape 420). Le rapport d'exécution ReSB(i) est ensuite transmis au système de gestion des modifications de la compagnie aérienne comme illustré par la flèche sortante (étape 425). En réponse à la transmission de ce rapport d'exécution, un message de validation VeSB(i) est reçu. A la réception du message de validation VeSB(i) (étape 430), le système informatique de l'aéronef valide ou annule la nouvelle configuration (étape 435) selon le contenu de ce message. Si la configuration de l'aéronef a été modifiée, un rapport validé d'exécution est produit et transmis au système de gestion des modifications de la compagnie aérienne et, de préférence, à celui du constructeur, comme illustré par la flèche sortante (étape 440).

Alternativement, il ne transmet qu'un simple accusé réception au système de gestion des modifications de la compagnie aérienne qui produit elle-même le rapport validé d'exécution qui est transmis au système de gestion des modifications du constructeur. Après la modification de la configuration, l'aéronef peut recevoir la version mise à jour de la documentation (non représenté). Alternativement ou de façon complémentaire, le système de l'aéronef met lui-même à jour sa documentation, comme décrit précédemment, en attendant de recevoir celle émise par le constructeur. La figure 5 illustre schématiquement un dispositif adapté à mettre en oeuvre chacun des algorithmes illustrés sur les figures 2 à 4. Le dispositif représenté est de préférence un dispositif standard, par exemple un ordinateur un calculateur ou un serveur. Le dispositif 500 comporte ici un bus interne de communication 505 auquel sont reliés : - une unité centrale de traitement ou microprocesseur 510 (CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ; - une mémoire morte 515 (ROM, acronyme de Read Only Memory en terminologie anglo-saxonne) pouvant comporter les programmes nécessaires à la mise en oeuvre de l'invention ; - une mémoire vive ou mémoire cache 520 (RAM, acronyme de Random Access Memory en terminologie anglo-saxonne) comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution des programmes précités ; - une interface de communication 540 adaptée à transmettre et à 30 recevoir des données vers et depuis un réseau de communication, filaire ou non.

Le dispositif 500 dispose également, de préférence, des éléments suivants : - un disque dur 525 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 530 adapté à recevoir une carte mémoire 535, 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 500 ou reliés à lui. La représentation du bus interne n'est pas limitative et, notamment, le microprocesseur est susceptible de communiquer des instructions à tout élément du dispositif 500 directement ou par l'intermédiaire d'un autre élément du dispositif 500. Le code exécutable de chaque programme permettant au dispositif programmable de mettre en oeuvre les processus selon l'invention, peut être stocké, par exemple, dans le disque dur 525 ou en mémoire morte 515. Selon une variante, la carte mémoire 535 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 500, est stocké dans le disque dur 525. Selon une autre variante, le code exécutable des programmes pourra être reçu, au moins partiellement, par l'intermédiaire de la première interface de communication 540, 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 500 avant d'être exécutés. Le microprocesseur 510 va commander et diriger l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur 525 ou dans la mémoire morte 515 ou bien dans les autres éléments de stockage précités.

Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 525 ou la mémoire morte 515, sont transférés dans la mémoire vive 520 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention. 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). 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. En particulier, l'invention peut être mise en oeuvre pour mettre à jour la documentation relative à tout appareil exploité et maintenu par un tiers.

ANNEXE <DLCS_AUTOMATIC_BATCH_JOB ="MyAirlineUPLJobOfToday" DATE ="12-Dec-07" Reference ="MyRef' <SELECT_DOMAIN ="ACD"/> <U PLOAD COMMAND LIST> <STEP =1" /> <COMMAND ="UPLOAD" LOAD PART NUMBER="ABF55A8FSOL0101" SOURCE ="FLS REPOSITORY INBOX" TARGET FIN SW ="1TH1SW2" TARGET FIN SW ="1TH2SW2" TARGET FIN SW ="1TH3SW2" TARGET FIN SW ="1TH4SW2" TARGET FIN SW ="1TH5SW2" TARGET FIN SW ="1TH6SW2" TARGET FIN SW ="1TH7SW2" TARGET FIN SW ="1TH9SW2" <COMMAND ="UPLOAD" LOAD PART NUMBER="C0L368316565003 " SOURCE ="FLS REPOSITORY REFERENCE AREA" TARGET FIN SW ="1TH1SW1" TARGET FIN SW ="1TH2SW1" TARGET FIN SW ="1TH3SW1" TARGET FIN SW ="1TH4SW1" TARGET FIN SW ="1TH5SW1" TARGET FIN SW ="1TH6SW1" TARGET FIN SW ="1TH7SW1" TARGET FIN SW ="1TH9SW1"/> <END_OF_STEP =1" /> <STEP ="2" <COMMAND ="UPLOAD" LOAD PART NUMBER="ABF55A8FSOL0101" SOURCE 25 ="FLS REPOSITORY INBOX" TARGET FIN SW ="1TH11SW2" TARGET FIN SW ="1TH12SW2" TARGET FIN SW ="1TH13SW2" TARGET FIN SW ="1TH14SW2" TARGET FIN SW ="1TH15SW2" TARGET FIN SW ="1TH16SW2" TARGET FIN SW ="1TH17SW2" TARGET FIN SW ="1TH19SW2" 30 <END_OF_STEP ="2" <EN D OF UPLOAD COMMAND LIST> <END OF JOB FOR AUTOMATIC UPLOADING Exemple de code d'un eSB

Claims (10)

1. REVENDICATIONS1. Procédé pour ordinateur de mise à jour automatisée d'au moins une application logicielle, dans un appareil, comprenant la mise à jour d'une documentation associée audit appareil, ladite mise à jour de ladite au moins une application logicielle étant effectuée par l'exploitant dudit appareil en fonction d'au moins une indication relative à une modification de ladite au moins une application logicielle, reçue dudit constructeur, ladite documentation étant mise à jour par le constructeur dudit appareil en fonction de la mise à jour de ladite au moins une application logicielle effectuée dans ledit appareil, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes, - réception (300) de ladite au moins une indication relative à ladite modification de ladite au moins une application logicielle ; - transmission (325) audit appareil d'au moins une commande permettant d'effectuer automatiquement ladite mise à jour de ladite au moins une application logicielle ; - réception (330) dudit appareil d'au moins une indication relative à l'exécution de ladite au moins une commande ; et, - transmission (345) d'un rapport d'exécution de ladite au moins une commande audit constructeur, ledit rapport d'exécution permettant audit constructeur de mettre à jour ladite documentation dudit appareil en réponse à ladite mise à jour de ladite au moins une application logicielle réellement effectuée dans ledit appareil.
2. 2. Procédé selon la revendication précédente comprenant en outre les étapes suivantes, - transmission (310) d'une requête comprenant une référence à ladite au moins indication relative à ladite modification de ladite au moins une application logicielle pour obtenir une description de ladite au moins une commande ; et,- réception (315) de ladite description de ladite au moins une commande.
3. 3. Procédé selon la revendication 1 ou la revendication 2 comprenant en outre une étape de réception de ladite documentation mise à jour.
4. 4. Procédé pour ordinateur de mise à jour automatisée d'au moins une application logicielle, dans un appareil, comprenant la mise à jour d'une documentation associée audit appareil, ladite mise à jour de ladite au moins une application logicielle étant effectuée par l'exploitant dudit appareil en fonction d'au moins une indication relative à une modification de ladite au moins une application logicielle, reçue dudit constructeur, ladite documentation étant mise à jour par le constructeur dudit appareil en fonction de la mise à jour de ladite au moins une application logicielle effectuée dans ledit appareil, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes, - réception (400) d'au moins une commande permettant d'effectuer automatiquement ladite mise à jour de ladite au moins une application logicielle ; - exécution (410) de ladite au moins une commande ; - production (420) d'un rapport d'exécution de ladite au moins une 20 commande ; et, - transmission (440) dudit rapport d'exécution audit constructeur, ledit rapport d'exécution permettant audit constructeur de mettre à jour ladite documentation dudit appareil en réponse à une mise à jour de ladite au moins une application logicielle réellement effectuée dans ledit appareil. 25
5. 5. Procédé selon la revendication précédente selon lequel ledit rapport d'exécution est transmis (345) audit constructeur via un système dudit exploitant.
6. 6. Procédé selon la revendication 4 ou la revendication 5 selon lequel ladite au moins une commande comprend une commande de 30 téléchargement d'au moins un composant logiciel.
7. 7. Procédé selon l'une quelconque des revendications 4 à 6 comprenant en outre une étape de validation (435) de ladite mise à jour de ladite au moins une application logicielle.
8. 8. Procédé selon l'une quelconque des revendications 4 à 7 5 comprenant en outre une étape de mise à jour d'une copie de ladite documentation mémorisée dans ledit appareil.
9. 9. 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 10 ordinateur.
10. 10. Aéronef comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications 4 à 8, ledit appareil correspondant audit aéronef. 15