Brevet FR2990531A1 — publié le 20131115

MÉTHODE DE MISE À JOUR D'UN LOGICIEL EMBARQUÉ À BORD D'UN AÉRONEF DESCRIPTION DOMAINE TECHNIQUE La présente invention concerne de manière générale le domaine de la maintenance des logiciels embarqués à bord d'un aéronef. ÉTAT DE LA TECHNIQUE ANTÉRIEURE Les aéronefs actuels comprennent de nombreux équipements embarqués généralement pilotés à l'aide de logiciels stockés dans leur mémoire interne. Ces équipements sont des éléments modulaires, encore dénommés LRUs (Line Replaceable Units) pouvant faire l'objet d'un remplacement ou plus fréquemment d'une mise à jour de leurs logiciels par les équipes de maintenance. A titre d'exemples de tels équipements, on peut mentionner des calculateurs de la baie avionique tel que le FMC (Flight Management Computer) ou des organes de contrôle d'actionneurs situés à l'extérieur de cette baie. Les opérations de mise à jour des logiciels précités sont souvent complexes et contribuent largement au temps d'immobilisation des aéronefs. En effet, le ou les équipement(s) concerné(s) par la mise à jour doivent être préalablement identifiés, les nouveaux logiciels doivent être préparés au sol, transportés à bord grâce à des moyens de stockage informatique avant d'être lus par un lecteur embarqué. Le personnel de maintenance doit ensuite sélectionner les équipements visés par la mise à jour, s'assurer que le chargement est effectué avec succès et que les nouvelles configurations des équipements sont bien conformes aux consignes de maintenance. Dans les aéronefs de conception récente, on doit en outre procéder à bord de l'aéronef à la vérification de l'authenticité et l'intégrité des logiciels avant leur téléchargement dans les différents équipements. Ces opérations sont répétées fréquemment et concernent généralement l'ensemble des aéronefs d'un même type au sein d'une flotte. Il est donc indispensable de les rendre les plus simples et les plus brèves possibles. A cette fin, il a été proposé de « pré-importer » automatiquement les nouveaux logiciels dès lors que l'aéronef se trouve au sol. Plus précisément, les logiciels à télécharger dans les équipements sont transmis en mode « push » sous forme de paquets IP, via une liaison sans fil, dans la zone de stockage d'un dispositif de chargement (encore dénommé communément dataloader) embarqué. Plus précisément, le serveur de maintenance détecte automatiquement la présence de l'aéronef et transmet directement au dispositif de chargement le ou les logiciel(s) concerné(s). Ce téléchargement automatique permet de raccourcir sensiblement les opérations de mise à jour puisqu'une partie importante du transfert des fichiers est réalisée avant même que le personnel de maintenance n'accède à l'aéronef. Le but de la présente invention est de permettre de raccourcir et d'automatiser les opérations de mise à jour des logiciels embarqués à bord d'un aéronef. EXPOSÉ DE L'INVENTION La présente invention est définie comme une méthode de mise à jour d'un logiciel stocké dans un équipement embarqué à bord d'un aéronef, comprenant : - un téléchargement de fichiers de mise à jour du dit logiciel, d'un serveur de maintenance au sol à un système de téléchargement embarqué, lesdits fichiers de mise à jour comprenant une nouvelle version du logiciel ; - une première vérification de l'intégrité et de l'authenticité de la nouvelle version du logiciel par ledit système de téléchargement embarqué, ladite méthode étant caractérisée en ce qu'elle comprend en outre : - une transmission de la nouvelle version 20 du logiciel par le système de téléchargement embarqué à l'équipement embarqué, lorsque ladite vérification est positive ; - un stockage de la nouvelle version du logiciel dans une zone mémoire de réserve de 25 l'équipement embarqué, ce dernier étant piloté par une version antérieure du dit logiciel stockée dans une zone mémoire active de l'équipement embarqué, distincte de la zone mémoire de réserve ; - une commutation de la zone mémoire de 30 réserve et de la zone mémoire active de l'équipement embarqué, ce dernier étant piloté, après commutation, par la nouvelle version du logiciel stockée dans la zone mémoire active. Avantageusement, après le stockage dans sa zone mémoire de réserve, l'équipement procède à une seconde vérification de l'intégrité de la nouvelle version du logiciel, la commutation des zones mémoire active et de réserve n'étant effectuée que si cette seconde vérification est positive. Typiquement, la nouvelle version de logiciel est transmise à l'équipement embarqué sous forme d'une suite de fichiers de logiciels, chaque fichier de logiciel étant stocké dans la zone mémoire de réserve et son intégrité étant ensuite vérifiée. Après l'étape de stockage dans sa zone mémoire de réserve, l'équipement peut procéder à une troisième vérification de la compatibilité de la nouvelle version de logiciel avec la configuration matérielle et/ou logicielle existante de l'équipement, la commutation des zones mémoire active et de réserve n'étant effectuée que si cette troisième vérification est positive. Dans tous les cas, la commutation de la zone mémoire de réserve et la zone mémoire active de l'équipement peut être déterminée par ledit équipement lui-même. Alternativement, la commutation de la zone mémoire de réserve et de la zone mémoire active de l'équipement peut être déterminée par le système de téléchargement embarqué. La commutation de la zone mémoire de réserve et de la zone mémoire active peut être déterminée en fonction de la phase de vol de l'aéronef. La commutation de la zone mémoire de réserve et de la zone mémoire active de l'équipement peut aussi être commandée par un ordre du serveur de maintenance, ledit ordre étant relayé à l'équipement embarqué par le système de téléchargement. Avantageusement, le système de téléchargement envoie une requête d'information de configuration à l'équipement embarqué et celui-ci renvoie une réponse contenant au moins un identifiant de la version de logiciel stockée dans la zone mémoire active. Alternativement, l'équipement transmet à intervalles réguliers au système de téléchargement un message de configuration contenant au moins un identifiant de la version de logiciel stockée dans la zone mémoire active. Si l'on détecte un défaut de fonctionnement après la commutation de la zone mémoire de réserve et de la zone mémoire active, on effectue alors la commutation inverse. De préférence, le téléchargement des fichiers de mise à jour entre le serveur de maintenance et le 25 système de téléchargement est réalisé au moyen d'une liaison sans fil. BRÈVE DESCRIPTION DES DESSINS D'autres caractéristiques et avantages de 30 l'invention apparaîtront à la lecture de modes de réalisation de l'invention décrits ci-après en relation avec la figure unique. La figure unique illustre de manière schématique un ordinogramme de la méthode de mise à jour d'un 5 logiciel embarqué, selon un mode de réalisation de l'invention. EXPOSÉ DÉTAILLÉ DE MODES DE RÉALISATION PARTICULIERS L'idée de base de l'invention est de prévoir dans 10 chaque équipement une première zone de mémoire, dite zone mémoire de réserve (ou zone mémoire « standby ») et une seconde zone de mémoire dite zone mémoire active. Lorsqu'une nouvelle version de logiciel est téléchargée par le dispositif de chargement dans 15 l'équipement en question, celle-ci est stockée dans la zone mémoire de réserve, l'ancienne version stockée dans la zone mémoire active continuant à piloter l'équipement. Lorsque que la nouvelle version est entièrement chargée dans la zone mémoire de réserve et 20 que les contrôles d'intégrité ont été effectués, les rôles respectifs de la zone mémoire de réserve et de la zone mémoire active sont intervertis. Autrement dit, la nouvelle version du logiciel résidant dans la zone mémoire active pilote l'équipement alors que la zone de 25 réserve contient l'ancienne version du logiciel. On considérera dans la suite un aéronef comportant une pluralité d'équipements embarqués, tels que des calculateurs avioniques, des systèmes d'information avionique, des systèmes d'information et de 30 divertissement des passagers. Chacun de ces équipements contient un logiciel susceptible d'être mis à jour au cours d'une opération de maintenance. Les équipements sont reliés à un système de téléchargement, via un réseau, tel que, par exemple, un réseau AFDX (Avionics Full-Duplex Switched Ethernet) conforme au protocole Arinc 664 ou bien un réseau à bus de données conforme au protocole Arinc 429. Le système de téléchargement peut être réalisé sous forme centralisée ou distribuée. Sous la forme distribuée, le système de téléchargement peut comprendre une pluralité de dispositifs de téléchargement élémentaires respectivement dédiés à des domaines distincts tels que le domaine de commande de l'aéronef ou ACD (Aircraft Control Domain), le domaine des services d'information de la compagnie aérienne ou AISD (Airline Information Service Domain), le domaine des services d'information et de divertissement des passagers ou PIESD (Passenger Information and Entertainment Services Domain), tels que définis dans la norme Arinc 811. Alternativement, le système de téléchargement pourra comprendre un premier dispositif de téléchargement dédié au domaine sécurisé de l'aéronef et un second dispositif de téléchargement dédié au domaine ouvert de l'aéronef. Par exemple, le domaine ACD fait partie du domaine sécurisé de l'aéronef, alors que les domaines AISD et PIESD font partie du domaine ouvert de celui-ci. Le système de téléchargement peut être résident sur l'aéronef. Le serveur de maintenance, situé au sol, lui transmets alors les fichiers de mise à jour soit par voie filaire, électrique ou optique, (réseau Ethernet par exemple, la connexion avec le réseau étant établie par exemple lorsque l'aéronef est stationné à la porte d'embarquement) ou par le moyen d'une liaison sans fil, par exemple une liaison Wi-Fi, une liaison WiMAX ou similaire. Selon une variante, le système de téléchargement est constitué d'une plateforme embarquée. Dans ce cas, lors d'une opération de maintenance, un terminal portable de téléchargement peut être connecté à la plateforme au moyen d'une liaison filaire, par exemple un câble RJ45 ou un câble USB. Les fichiers de mise à jour sont alors transférés du terminal à la plateforme via la liaison filaire. La Fig. 1 illustre de manière schématique un 15 ordinogramme de la méthode de mise à jour d'un logiciel embarqué, selon un mode de réalisation de l'invention. A l'étape 110, une nouvelle version d'un logiciel destiné à un équipement de l'aéronef, est téléchargée sous forme d'une série de fichiers de mise à jour, par 20 liaison filaire ou sans fil, au système de téléchargement embarqué. La série de fichiers de mise à jour comprend outre les fichiers de logiciel proprement dits, au moins un fichier auxiliaire contenant d'une part des 25 informations permettant de vérifier l'authenticité et l'intégrité de chacun et/ou de l'ensemble des fichiers de logiciel auxquels il est rattaché. Il pourra notamment s'agir de certificats numériques au format X.509, de jetons d'horodatage, de signatures 30 numériques, etc. Le fichier auxiliaire comprend avantageusement des indications permettant notamment au système de téléchargement embarqué de déterminer le ou les équipements destinataires desdits fichiers de logiciel. Ladite série de fichiers peut également comprendre des fichiers d'aide fournissant des informations complémentaires de mise à jour à destination du système de téléchargement et/ou des équipements concernés. A titre d'exemple, lorsque la série de fichiers de mise à jour est conforme à la norme Arinc 665, celle-ci se présente sous la forme d'un Field Loadable Software comprenant un fichier d'entête (extension de fichier .1uh) fournissant la destination et les informations d'authenticité/ d'intégrité de chacun des fichiers suivants, un ou plusieurs fichiers de logiciel proprement dits, dénommés Data Files, et un ou plusieurs fichiers d'aide à la mise à jour, dénommés Support Files, fournissant des indications de mise à jour au système de téléchargement et/ou aux équipements concernés. A l'étape 120, une fois que la série de fichiers de mise à jour a été entièrement téléchargée dans le buffer du système de téléchargement, celui-ci procède à la vérification de l'authenticité et de l'intégrité des fichiers de logiciel et le cas échéant des fichiers d'aide. On rappelle que par authenticité, on entend que les fichiers sont bien issus d'une source connue du système de téléchargement. Par intégrité, on entend que les fichiers n'ont pas subi l'altération volontaire ou accidentelle lors de leur transmission ou de leur stockage. Si la vérification est négative, la procédure de mise à jour est avortée et se termine en 190. En revanche, si la vérification est positive, les fichiers de logiciel ainsi qu'une partie au moins du fichier auxiliaire et des fichiers d'aide sont transmis en 130 par le système de téléchargement embarqué aux équipements concernés par la mise à jour. Pour ce faire, le système de téléchargement détermine, à partir des indications contenues dans le fichier auxiliaire les équipements destinataires du ou des fichiers de logiciel. Différentes implémentations de l'étape 130 sont envisageables en fonction du type de réseau reliant les équipements destinataires au système de téléchargement. Ainsi on pourra mettre en oeuvre, de manière connue en soi, un mode de téléchargement selon la norme Arinc 615 pour un réseau de type Arinc 429, un mode de téléchargement selon la norme Arinc 615A pour un réseau AFDX et un mode de téléchargement selon la norme Arinc 825/826 pour un bus CAN. A l'étape 140, chaque équipement stocke dans sa zone mémoire de réserve le ou les fichiers de logiciel qui lui ont été transmis par le système de téléchargement à l'étape 130. Selon une première variante, l'équipement contrôle l'intégrité de chaque fichier logiciel à l'aide des informations d'intégrité (par exemple CRC) figurant dans le fichier auxiliaire. Selon une seconde variante, l'équipement stocke les fichiers de logiciel au fur et à mesure dans sa zone mémoire de réserve. Lorsque le dernier fichier de 30 logiciel a été reçu et stocké, l'équipement effectue alors un contrôle d'intégrité de l'ensemble des fichiers de logiciel à partir de l'information d'intégrité présente dans le fichier auxiliaire. Si le contrôle de l'intégrité est négatif, la méthode de mise à jour s'achève en 190. Le cas échéant, l'équipement peut effectuer une série de tests visant à vérifier la compatibilité du nouveau logiciel avec le hardware de l'équipement et/ou le software déjà présent(s), autrement avec la configuration matérielle et/ou logicielle existante. Là encore, si le diagnostic de compatibilité s'avère négatif, la méthode de mise à jour s'achève en 190. Il est important de noter que, pendant les étapes de transmission, de stockage, de vérification d'intégrité et de compatibilité, l'équipement continue de fonctionner à l'aide de la version de logiciel stocké dans la zone de mémoire active. A l'étape 150, on effectue une commutation entre la zone mémoire active et la zone mémoire de réserve. Cette commutation peut être effectuée de manière autonome par l'équipement ou bien de manière centralisée par le système de téléchargement, comme décrit plus loin. Une fois la commutation effectuée, la mise à jour se termine à l'étape 190. Il convient de noter qu'au cas où l'équipement diagnostiquerait une erreur de fonctionnement après la commutation, il pourrait toujours rebasculer sur la version antérieure du logiciel en effectuant la commutation inverse, c'est-à-dire, en commutant à nouveau la zone mémoire active et la zone mémoire de réserve. En effet, la version antérieure du logiciel présent dans la zone mémoire de réserve ne sera écrasée qu'en cas de nouveau téléchargement. Le système de téléchargement peut connaître à tout 5 moment la version du logiciel active sur un équipement donné. Pour ce faire, le système de téléchargement transmet une requête d'information de configuration à l'équipement (par exemple requête d'information selon le protocole Arinc 615). L'équipement répond à l'aide 10 d'un rapport de configuration spécifiant le numéro de version de logiciel stocké dans la zone mémoire active. Alternativement, le rapport de configuration de l'équipement peut spécifier les numéros de version de logiciel respectivement stockés dans la zone mémoire 15 active et la zone mémoire de réserve. Si le protocole Arinc 615 est adopté, le rapport de configuration de l'équipement peut se présenter sous la forme d'une trame individuelle identifiable par un champ FIN (Function Indication Number) spécifique, cette trame 20 fournissant un identifiant PNR (Part NumbeR) du logiciel stocké dans la zone mémoire active (PNR active) et un identifiant PNR du logiciel stocké dans la zone mémoire de réserve. Alternativement, un équipement peut transmettre 25 systématiquement à intervalles réguliers, un message spécifiant sa configuration. Comme précédemment, le message pourra contenir l'identifiant de la version de logiciel stockée dans la zone mémoire active de l'équipement et, le cas échéant, celui de celle stockée 30 dans la zone mémoire de réserve. Selon une première variante de réalisation, la commutation entre la zone mémoire de réserve et la zone mémoire active est effectuée de manière autonome par l'équipement embarqué. Dans cette variante, l'équipement détermine d'abord s'il se trouve dans une phase de vol autorisant la maintenance. Cette phase de vol peut être déterminée à partir d'informations reçues de capteurs et/ou de systèmes avioniques. En règle générale, la maintenance d'un équipement n'est possible que lorsque l'aéronef est immobilisé au sol. Dans ce cas, l'équipement doit préalablement vérifier si les conditions d'immobilisation au sol sont bien remplies : train d'atterrissage compressé, moteurs éteints, frein de parc serré, etc. Dans d'autres cas, la maintenance d'un équipement pourra se faire en vol, dans la mesure où elle n'est pas préjudiciable à la sécurité de l'appareil. Après avoir vérifié qu'il se trouvait bien dans une phase de maintenance, l'équipement peut commuter ses zones mémoire active et de réserve. Dans certains, il vérifiera en outre, préalablement à la commutation, que la version de logiciel stockée dans la zone mémoire de réserve est plus récente que celle stockée dans la zone mémoire active. Selon une seconde variante de réalisation, la commutation entre la zone mémoire de réserve et la zone mémoire active des équipements est effectuée de manière centralisée par le système de téléchargement. Le système de téléchargement détermine d'abord s'il se trouve bien dans une phase de vol autorisant la maintenance des équipements concernés. Si c'est effectivement le cas, il envoie une requête de commutation zone mémoire active/zone mémoire de réserve à ces équipements. Ceux-ci peuvent transmettre un message d'acquittement après avoir exécuté la commutation en question. Alternativement, comme décrit précédemment, le système de téléchargement peut interroger les différents équipements, afin de connaître la version de logiciel active, et donc vérifier que la commutation a bien été effectuée. Alternativement encore, si les équipements transmettent à intervalles réguliers des messages spécifiant leurs configurations, le système de téléchargement pourra également vérifier que la commutation a bien été effectuée. Quel que soit le mode de vérification envisagé, si la commutation a échoué, le système de téléchargement peut en avertir le système de maintenance centralisé de l'avion et/ou le serveur de maintenance au sol. En revanche, si le système de téléchargement détecte que la commutation a bien été effectuée par tous les équipements concernés par l'opération de maintenance, il peut valider celle-ci et en avertir le serveur de maintenance au sol. Il peut aussi effacer dans ce cas la copie locale de la série de fichiers utilisés pour la mise à jour. Selon une troisième variante de réalisation, la commutation des zones mémoire est déclenchée par le serveur de maintenance au sol. Dans ce cas, l'ordre de commutation est simplement relayé par le système de téléchargement aux équipements visés par l'opération de maintenance. Par exemple, le serveur de maintenance d'une compagnie aérienne pourra déclencher une opération de maintenance donnée pour tous les appareils d'un type donné de sa flotte. Cette variante permet de synchroniser au mieux les opérations de maintenance. L'homme du métier comprendra que différentes combinaisons des variantes décrites ci-dessus sont également envisageables sans sortir pour autant du cadre de l'invention. Ainsi, certains équipements pourront effectuer la commutation de zones mémoire de manière autonome alors que d'autres seront assujettis à un contrôle centralisé du système de téléchargement. La troisième variante de réalisation peut aussi coexister avec les première et seconde variantes au sens où un ordre de commutation du serveur de maintenance de la compagnie aura priorité sur les autres modes de commutation.20 REVENDICATIONS1. Méthode de mise à jour d'un logiciel stocké dans un équipement embarqué à bord d'un aéronef, comprenant : - un téléchargement (110) de fichiers de mise à jour du dit logiciel, d'un serveur de maintenance au sol à un système de téléchargement embarqué, lesdits fichiers de mise à jour comprenant une nouvelle version du logiciel ; - une première vérification (120) de l'intégrité et de l'authenticité de la nouvelle version du logiciel par ledit système de téléchargement embarqué, ladite méthode étant caractérisée en ce qu'elle comprend en outre : - une transmission (130) de la nouvelle version du logiciel par le système de téléchargement embarqué à l'équipement embarqué, lorsque ladite vérification est positive ; - un stockage (140) de la nouvelle version du logiciel dans une zone mémoire de réserve de l'équipement embarqué, ce dernier étant piloté par une version antérieure du dit logiciel stockée dans une zone mémoire active de l'équipement embarqué, distincte de la zone mémoire de réserve ; - une commutation (150) de la zone mémoire de réserve et de la zone mémoire active de l'équipement embarqué, ce dernier étant piloté, après commutation, par la nouvelle version du logiciel stockée dans la zone mémoire active. 2. Méthode de mise à jour d'un logiciel selon la revendication 1, caractérisée en ce qu'après le stockage dans sa zone mémoire de réserve, l'équipement procède à une seconde vérification de l'intégrité de la nouvelle version du logiciel, la commutation des zones mémoire active et de réserve n'étant effectuée que si cette seconde vérification est positive. 3. Méthode de mise à jour d'un logiciel selon la revendication 2, caractérisée en ce que la nouvelle version de logiciel est transmise à l'équipement embarqué sous forme d'une suite de fichiers de logiciels, chaque fichier de logiciel étant stocké dans la zone mémoire de réserve et son intégrité étant ensuite vérifiée. 4. Méthode de mise à jour d'un logiciel selon la revendication 2 ou 3, caractérisée en ce qu'après l'étape de stockage dans sa zone mémoire de réserve, l'équipement procède à une troisième vérification de la compatibilité de la nouvelle version de logiciel avec la configuration matérielle et/ou logicielle existante de l'équipement, la commutation des zones mémoire active et de réserve n'étant effectuée que si cette troisième vérification est positive. 5. Méthode de mise à jour d'un logiciel 30 selon l'une des revendications précédentes, caractérisée en ce que la commutation de la zonemémoire de réserve et la zone mémoire active de l'équipement est déterminée par ledit équipement lui-même. 6. Méthode de mise à jour d'un logiciel selon l'une des revendications 1 à 4, caractérisée en ce que la commutation de la zone mémoire de réserve et de la zone mémoire active de l'équipement est déterminée par le système de téléchargement embarqué. 7. Méthode de mise à jour d'un logiciel selon la revendication 5 ou 6, caractérisée en ce que la commutation de la zone mémoire de réserve et de la zone mémoire active est déterminée en fonction de la phase de vol de l'aéronef. 8. Méthode de mise à jour d'un logiciel selon l'une des revendications 1 à 5, caractérisée en ce que la commutation de la zone mémoire de réserve et de la zone mémoire active de l'équipement est commandée par un ordre du serveur de maintenance, ledit ordre étant relayé à l'équipement embarqué par le système de téléchargement. 9. Méthode de mise à jour d'un logiciel selon l'une des revendications précédentes, caractérisée en ce que le système de téléchargement envoie une requête d'information de configuration à l'équipement embarqué et que celui-ci renvoie une réponse contenant au moins un identifiant de la version de logiciel stockée dans la zone mémoire active. 10. Méthode de mise à jour d'un logiciel selon l'une des revendications 1 à 8, caractérisée en ce que l'équipement transmet à intervalles réguliers au système de téléchargement un message de configuration contenant au moins un identifiant de la version de logiciel stockée dans la zone mémoire active. 11. Méthode de mise à jour d'un logiciel selon l'une des revendications précédentes, caractérisée en ce que si l'on détecte un défaut de fonctionnement après la commutation de la zone mémoire de réserve et de la zone mémoire active, on effectue la commutation inverse. 12. Méthode de mise à jour d'un logiciel selon l'une des revendications précédentes, caractérisée en ce que le téléchargement des fichiers de mise à jour entre le serveur de maintenance et le système de téléchargement est réalisé au moyen d'une liaison sans fil.