FR2987145A1 - Procede et dispositif d'optimisation de mises a jour de donnees dans des applications logicielles operationnellement approuvees d'aeronefs - Google Patents

Abstract

L'invention a notamment pour objet l'optimisation de la mise à jour de données dans une application logicielle opérationnellement approuvée d'un aéronef, comprenant un premier élément logiciel (235) exploitant un second élément logiciel. Suite à la réception (S250) d'un composant logiciel comprenant une mise à jour dudit second élément logiciel, une analyse dudit composant logiciel reçu est effectuée et une classe d'appartenance de la mise à jour dudit second élément logiciel est déterminée. Selon ladite classe d'appartenance, la mise à jour dudit second élément logiciel est transmise (S255, S255') audit premier élément logiciel et/ou à un système centralisé de téléchargement. Si la mise à jour dudit second élément logiciel est transmise audit premier élément logiciel, ledit second élément logiciel est mis à jour et un rapport de configuration indiquant ladite mise à jour est créé.

Description

La présente invention concerne la mise à jour d'éléments logiciels dans des systèmes informatiques et plus particulièrement un procédé et un dispositif d'optimisation de mises à jour de données dans des applications logicielles opérationnellement approuvées d'aéronefs comme défini dans le standard ARINC 667.

Afin de simplifier les opérations de maintenance des aéronefs et faciliter le déploiement d'améliorations et/ou de corrections de certains éléments d'aéronefs, typiquement des éléments logiciels de calculateurs, l'utilisation d'applications logicielles téléchargeables se généralise sur les dernières générations d'aéronefs.

Ces derniers comprennent ainsi des mécanismes de téléchargements qui permettent de mettre à jour certains éléments logiciels de calculateurs. A ces fins, de nouvelles versions d'applications logicielles, appelées logiciels, ou de composants de ces applications, appelés éléments logiciels, sont apportées dans les aéronefs concernés, sur des supports de stockage physique ou via des moyens de communications informatiques, filaires ou non. Des opérations de mises à jour des calculateurs, appelées ci-après téléchargements, sont alors exécutées et un rapport de configuration est généré. Lorsqu'un téléchargement est effectué, un opérateur consulte le rapport de configuration généré pour vérifier que l'opération correspondante s'est bien effectuée. Un niveau de criticité est généralement associé aux mises à jour effectuées, en fonction des éléments visés par celles-ci. Chaque niveau de criticité exige typiquement des opérations et des qualifications particulières des opérateurs effectuant les mises à jour. Ainsi, il existe différentes réglementations qui s'appliquent aux opérations et mécanismes de mise à jour des logiciels embarqués. Afin d'homogénéifier et clarifier les différents types de logiciels, la société ARINC (acronyme d'Aeronautical Radio, Incorporated en terminologie anglo-saxonne) a fait paraître la norme ARINC 667 qui classifie les logiciels en fonction de leur réglementation applicable. Lorsqu'un opérateur effectue une opération d'installation ou de mise à jour d'un logiciel, il doit attester qu'il a bien installé la bonne version du bon logiciel sur le bon équipement, comme requis, en suivant la bonne procédure. A ces fins, les mécanismes de téléchargement permettent généralement de rendre compte, via des rapports de configuration, de la version des logiciels installés ainsi que de leur emplacement fonctionnel, appelé ci-après FIN (acronyme de Functional Item Number en terminologie anglo-saxonne), et des 10 équipements concernés. Ces rapports de configuration tendent à regrouper les configurations de grands nombres de logiciels installés sur différents équipements afin d'éviter à l'opérateur de devoir traiter un rapport de configuration pour chaque élément logiciel ou chaque équipement. Ces rapports de configuration contiennent ainsi la liste des logiciels 15 installés sur les différents équipements téléchargeables et leur version. Typiquement, ils contiennent en outre des informations supplémentaires liées aux logiciels faisant l'objet de réglementations particulières et à ces dernières. Lorsque ces rapports de configuration contiennent des informations selon lesquelles la configuration d'équipements a des impacts potentiellement 20 importants pour la sécurité ou la sûreté de l'aéronef, leur consultation n'est généralement possible qu'à bord de l'aéronef sur des équipements qualifiés et utilisables à des fins d'attestation. Il est donc nécessaire, lors de l'utilisation de certains mécanismes de mise à jour de logiciel, de demander à du personnel de maintenance qualifié de se rendre dans l'aéronef pour y effectuer les 25 opérations. Par ailleurs, il est observé qu'un certain nombre de logiciels nécessitent le transfert d'importante quantité de données vers l'aéronef lors de mises à jour fréquentes. Ainsi, en d'autres termes, la mise à jour d'éléments logiciels se 30 déroule généralement en trois étapes : importation de données depuis un support ou via un réseau de communication ; installation de l'élément logiciel importé (téléchargement) sur l'équipement concerné par un opérateur ; et - génération d'un rapport de configuration décrivant le contenu installé.

Le rapport de configuration comprend une liste des éléments logiciels installés dans les différents équipements et, pour chaque élément logiciel, sa version. Il y a donc une cardinalité de un pour un entre une version d'un élément logiciel et l'identifiant fonctionnel auquel il se rattache. Il est donc nécessaire, lors d'une mise à jour d'un élément logiciel, d'importer et d'installer l'intégralité de l'élément logiciel même si seulement une partie de celui-ci a été modifié. Pour améliorer la mise à jour de logiciels dans les aéronefs, il est possible d'effectuer un découpage plus fin des éléments logiciels en sous-éléments logiciels. Cela permet de mettre à jour uniquement les sous-éléments logiciels qui ont évolué. Une autre amélioration consiste à créer plusieurs identifiants fonctionnels pour un élément logiciel susceptible d'être complété ultérieurement par d'autres éléments logiciels, de façon incrémentale, et créer une liste de ces identifiants fonctionnels pouvant accueillir des incréments.

Cependant, ces solutions ne sont pas optimales. Tout d'abord, le découpage initial doit prendre en compte la structure du logiciel ainsi que les futures évolutions, ce qui est souvent irréaliste et induit un manque de clarté sur le découpage fonctionnel qui devient un découpage technique, plus difficile à appréhender pour un opérateur. En outre, le nombre d'éléments logiciels 25 augmentant, la complexité de gestion de la configuration augmente également. Par ailleurs, pour des raisons de performances et mettre une limite au nombre de sous-éléments constitutifs d'un élément logiciel, il est nécessaire d'installer régulièrement une nouvelle version complète de l'élément logiciel. En outre, afin d'assurer que la nouvelle configuration soit toujours une image fidèle 30 de l'état de l'aéronef, il est nécessaire de désinstaller une partie des incréments précédemment installés, créant une procédure particulière ayant un impact pour les opérateurs.

Enfin, du fait de ces améliorations, les éléments logiciels installés deviennent plus complexes. Par conséquent, il peut être difficile de respecter les contraintes sur l'intégration des éléments logiciels dans les calculateurs. En effet, il peut devenir difficile, voire impossible, de gérer les incréments nécessairement installés dans des emplacements qui sont, par nature, différents les uns des autres et différents de la version complète précédente du logiciel correspondant. Il existe donc un besoin pour améliorer les systèmes de mises à jour de logiciels dans les aéronefs, limitant les temps d'intervention des opérateurs 10 et leurs déplacements dans les aéronefs. L'invention a ainsi pour objet un procédé de mise à jour d'au moins un élément logiciel appartenant à au moins une application logicielle opérationnellement approuvée mise en oeuvre dans un système informatique d'un aéronef, ladite au moins une application logicielle opérationnellement 15 approuvée comprenant au moins un premier élément logiciel exploitant au moins un second élément logiciel, le procédé comprenant les étapes suivantes, - réception, par le système informatique de l'aéronef, d'un composant logiciel comprenant au moins une mise à jour dudit au moins un second élément logiciel ; 20 - analyse, par le système informatique de l'aéronef, dudit au moins un composant logiciel reçu et détermination d'une classe d'appartenance de ladite au moins une mise à jour dudit au moins un second élément logiciel en réponse à ladite étape d'analyse ; - selon ladite classe d'appartenance, transmission, par le système 25 informatique de l'aéronef, de ladite au moins une mise à jour dudit au moins un second élément logiciel à au moins ledit au moins un premier élément logiciel et/ou à un système centralisé de téléchargement ; - si ladite au moins une mise à jour dudit au moins un second élément logiciel est transmise à au moins ledit au moins un premier élément 30 logiciel, mise à jour dudit au moins un second élément logiciel par le système informatique de l'aéronef ; et, - création d'un rapport de configuration indiquant ladite mise à jour.

Le procédé selon l'invention permet ainsi d'améliorer la mise à jour d'éléments logiciels d'applications opérationnellement approuvées, en particulier comme défini dans le standard ARINC 667, mises en oeuvre dans un système informatique d'un aéronef, limitant notamment les temps d'intervention d'opérateurs et leurs déplacements dans l'aéronef. Le procédé selon l'invention est compatible avec les opérations actuelles de maintenance et n'engendre pas de nouvelles opérations pour les opérateurs de l'aéronef ni d'opérations particulières préalables telles que des opérations de désinstallation et de reconfiguration. En outre, des caractéristiques de chacun des logiciels apparaissent dans un rapport de configuration unifié, évitant à un opérateur de multiples consultations. Par ailleurs, le format de données des mises à jour peut être celui couramment utilisé, typiquement des loads formatés suivant la norme ARINC 665. Le ou les rapports de configuration générés lorsque le procédé selon l'invention est mis en oeuvre reflètent l'état de l'aéronef. Cela signifie notamment que l'installation de l'ensemble des logiciels présents dans le rapport de configuration assure que l'aéronef est dans l'état attendu. Il existe ainsi une bijection entre le contenu d'un rapport de configuration et un état de l'aéronef.

De façon avantageuse, le procédé comprend en outre une étape de validation dudit composant logiciel reçu permettant notamment de vérifier que des données reçues correspondent à des données attendues. Selon un mode de réalisation particulier, le procédé comprend en outre une étape de validation de ladite au moins une mise à jour dudit au moins un second élément logiciel. Une telle validation peut, par exemple, consister à vérifier la compatibilité des données reçues avec des données préalablement reçues. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape d'interrogation dudit au moins un premier élément logiciel pour obtenir des informations de configuration dudit au moins un premier élément logiciel relativement audit au moins un second élément logiciel. Ledit au moins un premier élément logiciel est ainsi capable de rendre compte de sa configuration, dont il peut être responsable. Cette décentralisation de la gestion de la configuration des données permet notamment d'éviter l'asservissement à des règles limitant le nombre de solutions techniques. De façon avantageuse, le procédé comprend en outre une étape d'intégration desdites informations de configuration obtenues à un rapport de configuration généré par ledit système centralisé de téléchargement. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de réception d'une requête d'activation de ladite mise à jour dudit au moins un second élément logiciel, ladite étape de mise à jour dudit au moins un second élément logiciel étant effectuée en réponse à la réception de ladite requête d'activation. Le procédé permet ainsi de montrer la cohérence de données de mise à jour, relativement à l'approbation, en anticipant la mise à jour effective. De façon avantageuse, lesdites informations de configuration comprennent une indication d'activation ou de non activation de ladite mise à jour dudit au moins un second élément logiciel permettant d'identifier un état de mise à jour. Selon un mode de réalisation particulier, le procédé comprend en outre une étape de génération de ladite requête d'activation permettant une mise à jour effective. L'invention a également pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé décrit précédemment lorsque ledit programme est exécuté sur un ordinateur ainsi qu'un dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes de ce procédé. Les avantages procurés par ce programme d'ordinateur et ce dispositif sont similaires à ceux évoqués précédemment. D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, 30 au regard des dessins annexés dans lesquels : - la figure 1 représente un arbre de décomposition des logiciels téléchargeables dans un aéronef selon la réglementation ARINC 667 ; - la figure 2 illustre un exemple de mise en oeuvre de l'invention pour mettre à jour des éléments logiciels de type DAFA dans un aéronef ; - la figure 3 illustre un exemple de structure d'un rapport de configuration sous forme de tableau, créé dans un système mettant en oeuvre l'invention ; et - la figure 4 illustre un exemple de dispositif de traitement d'informations adapté à mettre en oeuvre l'invention ou une partie de l'invention. Il est tout d'abord observé que les applications logicielles (ou logiciels) mises en oeuvre dans un aéronef sont liées à des réglementations différentes et que, par conséquent, la gestion de leur configuration peut être différente. Comme illustré sur la figure 1 représentant un arbre de décomposition des logiciels téléchargeables dans un aéronef selon la réglementation ARINC 667, les applications logicielles mises en oeuvre dans un aéronef capable de recevoir de telles applications aussi appelées ACLSP (sigle d'Aircraft Controlled Loadable Software Part en terminologie anglo-saxonne) peuvent être regroupées en quatre catégories selon le standard ARINC 667 : - les applications logicielles certifiées dans le cadre de la conception de l'aéronef, généralement appelées LSAP (acronyme de Loadable Software Aircraft Part en terminologie anglo-saxonne) ; - les applications logicielles de calculs devant être opérationnellement approuvées par des autorités locales de l'opérateur de l'aéronef, généralement appelées OAB (sigle de Operationnaly Approved Binaries en terminologie anglo-saxonne), comprenant des MOS (sigle de Maintenance Operations Software en terminologie anglo-saxonne), c'est-à-dire des logiciels utilisés pour les opérations de maintenance de l'aéronef, et une partie des FOS (sigle de Flight Operations Software en terminologie anglo-saxonne), c'est-à-dire des logiciels utilisés pour des opérations liées à la conduite du vol de l'aéronef ; - les éléments logiciels constitués de données, typiquement sous forme de tables, utilisées par des applications approuvées, généralement appelés DAFA (sigle de Data for Approved Applications en terminologie anglo- saxonne), comprenant des données appelées techpub et une partie des FOS ; et - les éléments logiciels mis à jour à chaque mission, appelés mission data en terminologie anglo-saxonne et mémorisés dans des bases de 5 données appelées ADB (sigle d'Aeronautical DataBases en terminologie anglo-saxonne). Les applications logicielles de type LSAP doivent nécessairement suivre la règle selon laquelle il y a une seule version de logiciel par emplacement logique afin de pouvoir répondre à la certification de l'aéronef. 10 Les applications logicielles de type OAB peuvent déroger à une telle règle de configuration nécessaire à la certification de l'aéronef. Cependant, au vu de leur similitude informatique avec les applications logicielles de type LSAP et étant donné que les opérateurs doivent justifier leur configuration auprès d'une autorité de tutelle, il est préférable de les gérer selon la règle de 15 configuration selon laquelle il y a une seule version de logiciel par élément logiciel. En d'autres termes, il y a un seul identifiant unique de version de logiciel, appelé PNR (sigle de Part NumbeR en terminologie anglo-saxonne) par FIN. Il a été observé que les éléments logiciels de type DAFA sont 20 généralement souvent mis à jour et ont souvent une taille très importante. Il est donc souhaitable d'alléger les règles de configuration liées à ces éléments logiciels. L'invention vise ainsi notamment à fournir directement les éléments logiciels de type DAFA aux éléments logiciels qui les exploitent sans avoir 25 recours à un système d'installation centralisé. C'est à l'élément logiciel recevant ces données de gérer leur configuration. Grâce à l'invention, un opérateur au sol peut effectuer une mise à jour d'éléments logiciels de type DAFA et suivre cette mise à jour sans se déplacer dans l'aéronef. Selon l'invention, c'est, de préférence, aux éléments logiciels 30 exploitant des éléments logiciels de type DAFA de rapporter la configuration de ces derniers, dans un rapport de configuration centralisé, sous forme d'identifiants correspondant aux versions installées (PNR) afin, notamment, de permettre à un opérateur d'attester la mise à jour d'éléments logiciels de type DAFA. En outre, les éléments logiciels exploitant des éléments logiciels de type DAFA rapportent, de préférence, des éléments synthétiques résultant de la compilation des éléments logiciels de type DAFA dans le rapport de configuration centralisé pour faciliter la gestion des données sous forme synthétique par un opérateur. Avantageusement, il est possible de n'envoyer à bord de l'aéronef que les données ayant changé, c'est-à-dire des incréments, pour diminuer les coûts de transmission et améliorer la rapidité de mise à jour.

A ces fins, l'invention repose sur un mécanisme comprenant ici les fonctions suivantes : - une fonction d'importation et de routage capable d'orienter des ACLSPs reçus vers un service d'installation centralisé ou directement vers une ou plusieurs applications logicielles exploitant des éléments logiciels de type 15 DAFA ; - une fonction de suivi d'importation et de traitement des éléments logiciels de type DAFA par les éléments logiciels qui les exploitent ; - une fonction de collecte de configurations, centralisée, configurée pour interroger les éléments logiciels exploitant des éléments logiciels de type 20 DAFA afin d'inclure dans le rapport de configuration des informations de configuration et/ou des données de synthèse liées aux éléments logiciels de type DAFA ; et - une fonction permettant, si nécessaire, d'effectuer un traitement de données de logiciels de bord, par exemple activer des données installées mais 25 pas rendu disponibles pour une utilisation à bord de l'aéronef. La figure 2 illustre un exemple de mise en oeuvre de l'invention pour mettre à jour des éléments logiciels de type DAFA dans un aéronef. Comme illustré, l'environnement 200 de mise à jour comprend ici un système informatique au sol référencé 205 et un système informatique de 30 l'aéronef, référencé 210. Le système informatique au sol 205 comprend un réseau de communication 215 auquel sont reliés un serveur de transmission 220 et un terminal 225 d'un opérateur, par exemple un ordinateur de type PC (sigle de Personal Computer en terminologie anglo-saxonne). Le système informatique de l'aéronef comprend ici un module de réception et de routage 230 configuré pour adresser des éléments logiciels reçus à une ou plusieurs applications consommatrices de données 235, c'est-à-dire ici des applications logicielles exploitant des éléments logiciels de type DAFA, et/ou à un système centralisé de téléchargement 240. Pour mettre à jour un élément logiciel d'un système informatique 210 d'un aéronef donné, un opérateur utilise ici un terminal 225 pour initier un transfert d'au moins un élément logiciel au système informatique 210. Cet élément logiciel est typiquement transmis sous forme de FLS (sigle de Field Loadable Software en terminologie anglo-saxonne) avec les instructions et/ou paramètres associés sous forme de composant logiciel appelé Joad, par exemple un Joad conforme au standard ARINC 665, au cours d'une étape S250. De tels paramètres comprennent notamment des informations de classification du FLS conformes au standard ARINC 667. Ainsi, lorsque le module de réception et de routage 230 reçoit un Joad, il analyse ce dernier pour en extraire une information de classification afin de transmettre ce Joad reçu à un ou plusieurs applications logicielles exploitant des éléments logiciels de type DAFA (applications consommatrices de données) ou au système centralisé de téléchargement. S'il s'agit d'un élément logiciel de type DAFA, il est transmis à l'application correspondante, ou aux applications correspondantes, de l'OAB dans une étape référencée S255. Alternativement ou de façon complémentaire, il est transmis au système centralisé de téléchargement dans une étape référencée S255'. La transmission de loads à des applications peut être effectuée de façon multicast, c'est-à-dire du module de réception et de routage vers plusieurs applications, ou de façon unicast, c'est-à-dire du module de réception et de routage vers une seule application. La transmission unicast est généralement plus performante en ce qu'une seule application est notifiée. Il est observé ici que les éléments logiciels de type DAFA (ou données des DAFA) étant mis à jour fréquemment et de façon automatisée, il est possible que des erreurs aient eu lieu dans la sélection de loads DAFA (i.e. comprenant des éléments logiciels de type DAFA) à transmettre. Pour traiter de telles erreurs potentielles, un système de notification et de transmission de loads placé entre le module de réception et de routage et les éléments logiciels exploitant des éléments logiciels de type DAFA permet à ces derniers de valider les loads DAFA reçus, c'est-à-dire de les accepter ou les refuser. Cette acceptation ou ce refus sont de préférence transmis au terminal de l'opérateur à l'origine de l'action. La décision d'acceptation ou de refus est typiquement basée sur la comparaison d'informations transmises dans le Joad avec des informations prédéterminées, pour vérifier, par exemple, que les données reçues correspondent à des données attendues. Au cours d'une étape suivante, référencée S260, les données des DAFA reçues sont traitées par le système informatique 210 pour être prises en compte par les applications visées. Le traitement de données des DAFA consiste notamment à vérifier que le DAFA peut effectivement être pris en compte par l'application visée. Cela permet, en particulier, de donner un retour rapide à l'opérateur ayant initié l'action. Ainsi, par exemple, lorsqu'un Joad comprenant des données des DAFA contient une évolution incrémentale de données (pour une ou des applications particulières), la ou les applications visées sont alors en mesure de vérifier que ces données sont compatibles avec les données dont elles disposaient précédemment. Si les données des DAFA reçues sont acceptées, la ou les applications visées peuvent les utiliser directement ou, alternativement, les stocker pour une activation ultérieure, afin de différer l'impact de la mise à jour. Un tel mode de réalisation peut notamment être nécessaire lorsqu'une application visée par les données reçues est utilisée par l'opérateur. Lorsqu'une application accepte des données des DAFA reçues, elle est ici capable de rendre compte de sa nouvelle configuration. Le mécanisme mis en oeuvre à ces fins peut être propre à chaque application afin de leur offrir un choix de mise en oeuvre des mécanismes de mise à jour des données. Chaque application est ainsi responsable de sa configuration. Cette décentralisation de la gestion de configuration des données permet notamment d'éviter l'asservissement à des règles qui forcent à avoir une et une seule solution technique par identifiant fonctionnel. Une application peut ainsi déclarer que sa configuration résulte de l'empilement de plusieurs modifications pour une même fonction, chaque modification étant contributrice de la définition finale. Pour ne pas multiplier les rapports de configuration et afin de mutualiser les moyens de transmissions entre les systèmes informatiques de l'aéronef et au sol, les rapports de configuration liés aux données des DAFA reçues, générés par les applications visées, sont avantageusement inclus dans le rapport de configuration centralisé de l'aéronef. A ces fins et comme illustré par la référence S265, le système centralisé de téléchargement 240 fait une demande correspondante à chaque élément logiciel exploitant des éléments logiciels de type DAFA (c'est-à-dire à 15 chaque application cliente de DAFA). Les applications y répondent en fournissant un ensemble d'éléments de configuration étendu via une liste d'attributs positionnés par l'application cliente des DAFA. Ces attributs supplémentaires sont, par exemple, des informations de date, de validité et de dénomination élargie. 20 Comme décrit en référence à la figure 3, les FIN correspondant à des applications ne recevant pas de DAFA ont un seul PNR tandis que pour les applications clientes de loads DAFA, plusieurs PNRs peuvent simultanément exister, ce qui permet notamment des mises à jour incrémentales. Les PNRs reportés dans le rapport de configuration permettent à un 25 opérateur d'attester qu'une opération de mise à jour a été correctement effectuée. Les informations complémentaires permettent quant à elles aux gestionnaires des données de connaitre précisément l'effectivité des données à bord de l'aéronef, au-delà d'une seule liste de PNR. Dans le cas où les données installées ne sont pas rendues effectives automatiquement, l'état de 30 ces données fait avantageusement partie du rapport de configuration fourni par l'application.

Pour des raisons de certification, les opérateurs d'aéronefs doivent montrer que les données à bord des aéronefs sous leur contrôle sont cohérentes. Les données des DAFA évoluant fréquemment, le mécanisme décrit précédemment permet de préparer l'aéronef, de façon anticipée, en y installant un ensemble de données qui sont alors dites « latentes ». Ces données latentes sont prêtes à être activées mais ne sont pas utilisées de façon effective par les applications visées. Sur requête de l'opérateur, via une requête à bord ou depuis le sol, les données latentes sont basculées pour remplacer ou compléter les données précédemment utilisées par les applications visées. La requête, référencée S280 sur la figure 2, peut notamment être déclenchée de manière automatique, par exemple à une date fixée ou lors d'un événement, ou manuellement depuis le sol ou depuis le bord. Sur réception d'une telle requête, l'application visée effectue le basculement et met à jour son rapport de configuration. Ainsi, l'opérateur au sol connait la configuration exacte des données installées et effectivement utilisées à bord. La figure 3 illustre un exemple de structure d'un rapport de configuration 300 sous forme de tableau, créé dans un système mettant en oeuvre l'invention. Le rapport de configuration comprend ici un ensemble de lignes génériquement référencées 305 et un ensemble de colonnes génériquement référencées 310. Il comprend deux parties, l'une formée par les colonnes 3101 et 310-2 et l'autre formée par les colonnes 310-3 à 310-6.

Les colonnes 310-1 à 310-6 visent ici respectivement des emplacements fonctionnels, des premiers identifiants uniques de version de logiciel, des descriptions de données, des dates de validité, des informations complémentaires et des seconds identifiants uniques de version de logiciel. La première partie correspond à un rapport de configuration standard. Elle est ici remplie par le système centralisé de configuration. Dans cette première partie, chaque ligne correspond à un emplacement fonctionnel. Ainsi, par exemple, la ligne 305-3 correspond à l'emplacement fonctionnel FIN C, ici un élément logiciel d'une application de type LSAP, et la ligne 305-4 correspond à l'emplacement fonctionnel FIN D, ici un élément logiciel d'une application de type OAB. A chaque emplacement fonctionnel est associé un identifiant unique de version de logiciel. A titre d'illustration, les identifiants uniques de version de logiciel PNR3 et PNR4 sont associés aux emplacements fonctionnels FIN C et FIN D, respectivement. La seconde partie du rapport de configuration est relative à des informations propres à des données de type DAFA. Ces informations étant associées à une ou plusieurs applications, elles sont dépendantes d'emplacements fonctionnels d'éléments logiciels d'applications de type OAB. Cette seconde partie est remplie par des éléments logiciels exploitant des éléments logiciels de type DAFA. A titre d'illustration, les lignes 310-4-1 et 3104-2, visant deux éléments logiciels de type DAFA, sont associées à l'élément logiciel de l'emplacement fonctionnel FIN D. En d'autres termes, l'élément logiciel de l'emplacement fonctionnel FIN D correspond à une application utilisant des données décrites dans les lignes 310-4-1 et 310-4-2. Il est rappelé ici que si un identifiant unique de version de logiciel est associé à chaque emplacement fonctionnel d'éléments logiciels d'applications de type LSAP ou OAB, plusieurs identifiants uniques de version de logiciel 20 peuvent être associés à chaque élément logiciel de type DAFA permettant une mise à jour incrémentale par sous-élément. Ainsi, par exemple, les identifiants uniques de version de logiciel PNR4xx, PNR4xy et PNR4xz sont associés à un élément logiciel relatif à des données identifiées dans la ligne 305-4-1, qui est lui-même associé à l'emplacement fonctionnel d'un élément logiciel 25 d'application de type OAB référencé FIN D. La figure 4 illustre un exemple de dispositif de traitement d'informations pouvant être utilisé pour mettre en oeuvre, au moins partiellement, l'invention, notamment les étapes décrites en référence à la figure 2. Le dispositif 400 est par exemple un calculateur tel qu'un calculateur 30 de type IMA (sigle &Integrated Moduler Avionics en terminologie anglo-saxonne) ou un ordinateur.

Le dispositif 400 comporte de préférence un bus de communication 402 auquel sont reliés : - une unité centrale de traitement ou microprocesseur 404 (CPU, Central Processing Unit) ; - une mémoire morte 406 (ROM, Read Only Memory) pouvant comporter le système d'exploitation et des programmes tels que "Prog" ; et - une mémoire vive ou mémoire cache 408 (RAM, Random Access Memory) 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 426 reliée à un réseau de communication distribué 428, par exemple le réseau AFDX (sigle d'Avionics Full DupleX en terminologie anglo-saxonne), l'interface étant apte à transmettre et à recevoir des données, notamment des données de mise à jour d'éléments logiciels. Optionnellement, le dispositif 400 peut également disposer des éléments suivants : - une carte graphique 414 reliée à un écran 416 ; - un disque dur 420 pouvant comporter les programmes "Prog" précités et des données traitées ou à traiter selon l'invention ; - un clavier 422 et une souris 424 ou tout autre dispositif de pointage comme un crayon optique, un écran tactile ou une télécommande permettant à l'utilisateur d'interagir avec les programmes selon l'invention ; et - un lecteur de cartes mémoires (non représenté) adapté à y lire ou à y écrire des données traitées ou à traiter selon l'invention. Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le dispositif 400 ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément du dispositif 400 directement ou par l'intermédiaire d'un autre élément du dispositif 400.

Le code exécutable de chaque programme permettant à l'appareil programmable de mettre en oeuvre les processus selon l'invention, peut être stocké, par exemple, dans le disque dur 420 ou en mémoire morte 406. Selon une variante, le code exécutable des programmes pourra être reçu par l'intermédiaire du réseau de communication 428, via l'interface 426, pour être stocké de façon identique à celle décrite précédemment. De manière plus générale, le ou les programmes pourront être chargés dans un des moyens de stockage du dispositif 400 avant d'être exécutés.

L'unité centrale 404 va commander et diriger l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur 420 ou dans la mémoire morte 406 ou bien dans les autres éléments de stockage précités. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 420 ou la mémoire morte 406, sont transférés dans la mémoire vive 408 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention.

Il convient de noter que 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 (ASIC). Naturellement, pour satisfaire des besoins spécifiques, une personne 25 compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente.

Claims (10)

1. REVENDICATIONS1. Procédé de mise à jour d'au moins un élément logiciel appartenant à au moins une application logicielle opérationnellement approuvée mise en oeuvre dans un système informatique (210) d'un aéronef, ce procédé étant caractérisé en ce que ladite au moins une application logicielle opérationnellement approuvée comprend au moins un premier élément logiciel (235) exploitant au moins un second élément logiciel et en ce qu'il comprend les étapes suivantes, - réception (S250), par le système informatique (210) de l'aéronef, d'un composant logiciel comprenant au moins une mise à jour dudit au moins un second élément logiciel ; - analyse, par le système informatique (210) de l'aéronef, dudit au 15 moins un composant logiciel reçu et détermination d'une classe d'appartenance de ladite au moins une mise à jour dudit au moins un second élément logiciel en réponse à ladite étape d'analyse ; - selon ladite classe d'appartenance, transmission (S255, S255'), par le système informatique (210) de l'aéronef, de ladite au moins une mise à 20 jour dudit au moins un second élément logiciel à au moins ledit au moins un premier élément logiciel et/ou à un système centralisé de téléchargement ; - si ladite au moins une mise à jour dudit au moins un second élément logiciel est transmise à au moins ledit au moins un premier élément logiciel, mise à jour dudit au moins un second élément logiciel par le système 25 informatique (210) de l'aéronef ; et, - création d'un rapport de configuration indiquant ladite mise à jour.
2. 2. Procédé selon la revendication 1 comprenant en outre une étape de validation dudit composant logiciel reçu.
3. 3. Procédé selon la revendication 1 ou la revendication 2 30 comprenant en outre une étape de validation de ladite au moins une mise à jour dudit au moins un second élément logiciel.
4. 4. Procédé selon l'une quelconque des revendications 1 à 3 comprenant en outre une étape d'interrogation dudit au moins un premier élément logiciel pour obtenir des informations de configuration dudit au moins un premier élément logiciel relativement audit au moins un second élément logiciel.
5. 5. Procédé selon la revendication 4 comprenant en outre une étape d'intégration desdites informations de configuration obtenues à un rapport de configuration généré par ledit système centralisé de téléchargement.
6. 6. Procédé selon l'une quelconque des revendications 1 à 5 10 comprenant en outre une étape de réception d'une requête d'activation de ladite mise à jour dudit au moins un second élément logiciel, ladite étape de mise à jour dudit au moins un second élément logiciel étant effectuée en réponse à la réception de ladite requête d'activation.
7. 7. Procédé selon la revendication 6 dépendante de la revendication 15 5 ou de la revendication 4 selon lequel lesdites informations de configuration comprennent une indication d'activation ou de non activation de ladite mise à jour dudit au moins un second élément logiciel.
8. 8. Procédé selon la revendication 6 ou la revendication 7 comprenant en outre une étape de génération de ladite requête d'activation. 20
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 1 à 8 lorsque ledit programme est exécuté sur un ordinateur.
10. 10. Dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications 25 1 à8.