Brevet FR3140353A1 — publié le 20240405

Un aspect de l’invention concerne un dispositif embarqué dans un aéronef, l’aéronef comprenant une pluralité de systèmes produisant des données de vol (V) de l’aéronef et des données de maintenance (M) de l’aéronef, chaque système de la pluralité de systèmes de l’aéronef étant relié au dispositif par au moins un bus de données, le dispositif étant configuré pour collecter (51) simultanément les données de vol (V) de l’aéronef et les données de maintenance (M) de l’aéronef. Figure à publier avec l’abrégé : Figure 4 Dispositif de collecte et de traitement de données de vol et de maintenance dans un aéronef DOMAINE TECHNIQUE DE L’INVENTION Le domaine technique de l’invention est celui du traitement de données dans l’aéronautique. La présente invention concerne un dispositif de collecte et de traitement de données de vol et de données de maintenance dans un aéronef, et en particulier un dispositif dans lequel l’acquisition des données de vol et l’acquisition des messages de maintenance est synchronisée en étant réalisée simultanément par un même module, c’est-à-dire par le même dispositif. ARRIERE-PLAN TECHNOLOGIQUE DE L’INVENTION Dans la plupart des aéronefs ayant une fonction de maintenance centralisée, par exemple de maintenance préventive ou de maintenance prédictive, les systèmes d’acquisition et traitement de données de vol et les systèmes d’acquisition et traitement des messages de maintenance sont des systèmes distincts. Dans un exemple de l’architecture de l’avion Airbus A380 ® représenté à la , le CDAU 20 (de l’anglais « Centralized Data Acquisition Unit » pour « Unité d’Acquisition Centralisée de Données » en français) est configuré pour acquérir des données de vol V et réaliser des traitements de ces données V notamment pour calculer des rapports et construire des paquets à enregistrer en mémoire. Une donnée de vol V est une donnée représentative d’un état de l’aéronef lié au vol, par exemple la vitesse de l’aéronef, l’altitude de l’aéronef, la latitude de l’aéronef, le cap de l’aéronef, des données générées par des systèmes de l’aéronef, des données issues de capteurs de pression ou de température de l’aéronef ou de surfaces de contrôle de vol. Le SCI 10 (de l’anglais « Secure Communication Interface » pour « Interface de Communication sécurisée » en français) joue le rôle de passerelle sécurisée et véhicule notamment toutes les données de maintenance M générées par les systèmes de l’avion vers la fonction centralisée 33 hébergée sur les serveurs ANSUs 34 (de l’anglais « Aircraft Network Server Unit » pour « Unité de Serveur du Réseau de l’Aéronef » en français). Pour cela, le SCI 10 reçoit des messages de maintenance M à une étape 1 représentée à la et route les messages de maintenance vers la fonction de maintenance CMS 32 (de l’anglais « Centralized Maintenance System » pour « Système de Maintenance Centralisée » en français). Le flux de messages de maintenance M contient des messages de pannes P mais aussi des messages réguliers de « Bonne Santé » envoyés de manière récurrente par tous les systèmes dits « membres » connectés au SCI 10. Les messages de maintenance M sont par exemple implémentés selon le protocole « BITE » pour « Built-in Test Equipment », par exemple suivant le standard ARINC® 624. Par la suite, à l’étape 2, la fonction de maintenance CMS 32 identifie un message de panne P d’un système membre pour lequel des données de vol V permettraient de mieux appréhender le contexte de l’apparition de pannes. A l’étape 3, la fonction de maintenance CMS 32 réalise une demande à la fonction ACMS 33 (de l’anglais « Aircraft Condition Monitoring System » pour « Système de Surveillance de l’Etat de l’Aéronef » en français) pour acquérir un ensemble de données de vol V prédéfini. A l’étape 4, la fonction ACMS 33 réalise une demande de données de vol V au CDAU 20. A l’étape 5, le CDAU 20 traite cette demande, c’est-à-dire qu’il récupère les données de vol V demandées, par exemple appartenant à un sous-ensemble de systèmes membres sur une durée définie. A l’étape 6, ces données de vol V demandées sont transmises du CDAU 20 à la fonction ACMS 33. A l’étape 7, la fonction ACMS reçoit les données de vol V demandées et crée un fichier d’incident lié à la panne rapportée par le message de panne P. A l’étape 8, le fichier d’incident est stocké par le système de stockage 34. Ce procédé d’enregistrement de données en lien avec un incident pose notamment un problème pour remonter à la cause de l’incident, comme décrit ci-après. Comme représenté à la , les changements d’état des flux de données data1 et data2 représentent l’imminence d’une défaillance du système, aussi appelée « incident », par exemple d’un composant de l’infrastructure de l’avion dans lequel le système est embarqué. Chaque flux de données Data1 à Data5 représenté à la comprend des données de vol V. Le flux de données data1 change deux fois d’état avant l’apparition d’un message de panne P et le flux de données data2 change d’état une fois après le changement d’état de data1 puis une deuxième fois à l’apparition du message de panne P. Le fait que les deux systèmes d’acquisition CDAU 20 et SCI 10 soient distincts a pour conséquence qu’une demande S de traitement et d’enregistrement d’un instantané des données de vol V par la fonction de maintenance 33 arrivera trop tard pour capturer les changements de Data1 et de Data2, comme représenté à la , la fenêtre F n’englobant pas l’ensemble des changements d’états de Data1 et Data2 ayant mené à l’incident. Même si la fonction d’acquisition 20 de données de vol V était configurée pour enregistrer les données sur une fenêtre temporelle glissante, il n’y aurait pas garantie de capturer l’ensemble des données de vol V car faire une acquisition sur une fenêtre temporelle glissante demande beaucoup de ressources, lesdites ressources étant limitées dans un tel système. De plus, il n’y a alors aucune garantie à ce que la demande S de traitement et d’enregistrement arrive toujours dans le même intervalle de temps. Comme il n’y a aucune garantie sur l’arrivée de la demande S de traitement et d’enregistrement, la fenêtre temporelle F enregistrée représentée à la ne couvre pas l’ensemble des changements d’états des flux de données data1 et data2. Cette situation amène à tirer des conclusions erronées sur le type de précurseur à détecter par les outils de maintenance préventive et est donc plus critique comparée à la situation dans laquelle l’information d’incident n’est pas du tout remontée. Ainsi, dans l’état de l’art, lorsqu’un système avion génère un message de panne P, il est difficile d’identifier la cause racine de la panne. Ceci est dû à l’architecture du réseau avion qui est commuté et distribué, aux différentes fonctions portées par des applicatifs et à la complexité de certains systèmes. Il existe donc un besoin de pouvoir remonter à la cause d’un incident, dans un aéronef implémentant une fonction de détection d’incidents basée sur des messages de maintenance et des données de vol. L’invention offre une solution aux problèmes évoqués précédemment, en permettant de remonter à la cause des incidents détectés de manière plus simple et plus rapide que l’art antérieur. Un aspect de l’invention concerne ainsi un dispositif embarqué dans un aéronef, l’aéronef comprenant une pluralité de systèmes produisant des données de vol de l’aéronef et des données de maintenance de l’aéronef, chaque système de la pluralité de systèmes de l’aéronef étant relié au dispositif par au moins un bus de données, le dispositif étant configuré pour collecter simultanément les données de vol de l’aéronef et les données de maintenance de l’aéronef. La présente invention, par l’acquisition simultanée des données de vol et des données de maintenance par le même dispositif, permet de remonter à la cause des incidents détectés de manière simple et rapide. En effet, un même dispositif collecte simultanément les deux types de données, garantissant une synchronisation des données de maintenance, utilisées pour détecter un incident, et des données de vol, utilisées pour remonter à la cause de l’incident. Outre les caractéristiques qui viennent d’être évoquées dans le paragraphe précédent, le dispositif selon un aspect de l’invention peut présenter une ou plusieurs caractéristiques complémentaires parmi les suivantes, considérées individuellement ou selon toutes les combinaisons techniquement possibles : la collecte des données de vol de l’aéronef comprend l’acquisition d’un premier flux de données prédéfini pour chaque système de la pluralité de systèmes de l’aéronef sur une fenêtre temporelle glissante prédéfinie et la collecte des données de maintenance de l’aéronef comprend l’acquisition d’un deuxième flux de données prédéfini pour chaque système de la pluralité de systèmes de l’aéronef sur ladite fenêtre temporelle glissante prédéfinie, le dispositif est configuré en outre pour : Traiter les données de maintenance de l’aéronef collectées pour détecter un incident, Lorsqu’un incident est détecté, stocker les données de vol collectées correspondant à l’incident, le stockage des données de vol correspondant à l’incident comprend le stockage des données de vol de l’aéronef collectées pendant la fenêtre temporelle glissante prédéfinie couvrant un instant durant lequel l’incident détecté a eu lieu, le dispositif comprend un unique processeur configuré pour réaliser les étapes de collecte et de traitement et au moins une mémoire configuré pour mettre en œuvre l’étape de stockage. Un autre aspect de l’invention concerne un procédé d’acquisition et de traitement de données par le dispositif selon l’invention, le procédé comprenant au moins les étapes de : Collecte simultanée des données de vol de l’aéronef et des données de maintenance de l’aéronef, Traitement des données de maintenance de l’aéronef collectées pour détecter un incident, Lorsqu’un incident est détecté, stockage des données de vol collectées pendant la fenêtre temporelle glissante prédéfinie correspondant à l’incident détecté. Un autre aspect de l’invention concerne un aéronef embarquant le dispositif selon l’invention. Un autre aspect de l’invention concerne un produit programme d'ordinateur comprenant des instructions qui, lorsque le programme est exécuté par un ordinateur, conduisent celui-ci à mettre en œuvre le procédé selon l’invention. Un autre aspect de l’invention concerne un support d'enregistrement lisible par ordinateur comprenant des instructions qui, lorsqu'elles sont exécutées par un ordinateur, conduisent celui-ci à mettre en œuvre le procédé selon l’invention. L’invention et ses différentes applications seront mieux comprises à la lecture de la description qui suit et à l’examen des figures qui l’accompagnent. BREVE DESCRIPTION DES FIGURES Les figures sont présentées à titre indicatif et nullement limitatif de l’invention. La montre une représentation schématique d’un système d’acquisition et de traitement de données d’un aéronef selon l’art antérieur, La montre une représentation schématique de flux de données d’un aéronef et d’une détection de panne selon l’art antérieur, La montre une représentation schématique de flux de données d’un aéronef, d’une détection de panne et d’une action liée à la panne détectée selon l’art antérieur, La montre une représentation schématique d’un dispositif d’acquisition et de traitement de données d’un aéronef selon l’invention, La montre une représentation schématique de flux de données d’un aéronef, d’une détection de panne et d’une action liée à la panne détectée selon l’invention, La montre une représentation schématique d’un procédé de détection d’incident selon l’invention. DESCRIPTION DETAILLEE Sauf précision contraire, un même élément apparaissant sur des figures différentes présente une référence unique. La montre une représentation schématique d’un dispositif selon l’invention. Le dispositif selon l’invention comprend un module de collecte 41 de données de vol V et de données de maintenance M, un module 42 de traitement de données de maintenance M, et un module de stockage 34. Le dispositif 40 selon l’invention est embarqué dans un aéronef (non représenté), c’est-à-dire qu’il est compris dans un aéronef. Le dispositif selon l’invention comprend au moins un processeur et une mémoire, la mémoire stockant des instructions qui, lorsqu’elles sont exécutées par le processeur, conduisent le processeur à mettre en œuvre les étapes attribuées au dispositif et/ou à implémenter les modules logiciels compris dans le dispositif. On entend par « module » un module logiciel ou un module physique. Un module logiciel est une succession d’étapes conduisant à la réalisation de la fonction associée au module logiciel. La montre une représentation schématique d’un procédé de collecte et de traitement de données selon l’invention. Le procédé 50 comprend trois étapes 51 à 53. Le procédé 50 est mis en œuvre par le dispositif 40. Dans une première étape 51, le module de collecte 41 du dispositif 40 collecte simultanément les données de vol V et les données de maintenance M de l’aéronef. L’aéronef comprend une pluralité de systèmes, par exemple des sondes de métriques physiques telles que la température ou la pression, des systèmes de commande de vol, des surfaces de contrôle de vol etc. Ces systèmes sont reliés au dispositif 40 via des bus. Chaque système est relié au dispositif 40 via au moins un bus qui lui est dédié, ou qui est partagé avec un autre système. Dans le cas d’un bus partagé, les données qui transitent sur le bus sont identifiées par un identifiant qu’elles comprennent, par exemple un en-tête. Un système peut être relié au dispositif 40 par plusieurs bus, par exemple par un premier bus faisant transiter des données de maintenance M et par un deuxième bus faisant transiter des données de vol V. Une donnée de vol V est une donnée représentative d’un état de l’aéronef lié au vol V, par exemple la vitesse de l’aéronef, l’altitude de l’aéronef, la latitude de l’aéronef, le cap de l’aéronef, des données générées par des systèmes de l’aéronef, des données issues de capteurs de pression ou de température de l’aéronef ou de surfaces de contrôle de vol. Une donnée de maintenance M contient des messages de panne P ou d’incident, émis par un système en panne ou ayant détecté un incident ou un fonctionnement s’écartant de son fonctionnement normal, mais aussi des messages réguliers de « Bonne Santé » envoyés de manière récurrente par tous les systèmes reliés au dispositif 40. Les données de vol V et de maintenance M sont reçues par le dispositif 40 sur chacun des bus de données reliés aux systèmes de l’aéronef. Le dispositif 40 collecte ainsi simultanément à l’étape 51 les données des deux types, c’est-à-dire les données de vol V et les données de maintenance M. Par « simultanément » on entend en même temps, c’est-à-dire que le dispositif 40 lit à un même instant temporel, sur chaque bus le reliant à un système de l’aéronef, des flux de données provenant des systèmes de l’aéronef, les flux de données comprenant des flux de données de maintenance M et des flux de données de vol V. On entend par « collecter une donnée » le fait de lire la donnée sur un bus d’entrée du dispositif 40, donc de recevoir la donnée. Préférentiellement, le dispositif 40 comprend un processeur quadricœurs QorIQ® T1042 de NXP® implémentant les modules logiciels de collecte 41 et de traitement 42. En effet, il a été montré que ce processeur a la capacité de réaliser une acquisition massive de données de vol V et de données de maintenance M. Une acquisition massive correspond à une acquisition de données se présentant sur chaque bus relié au dispositif 40 à chaque instant, les données comprenant entre 300 000 et 500 000 paramètres par seconde. Un paramètre peut être un booléen comme un message de 32 bits, les données entrée représentant donc au plus 16 mégabits par seconde. Ce processeur a la capacité de stocker les données en entrée dans un buffer, puis de les mettre à disposition d’applications mises en œuvre par le processeur. Ce processeur est aussi capable de traiter des données d’entrée ayant un taux de rafraichissement de 64 Hz, et de traiter les données d’entrée les plus véloces, c’est-à-dire les données d’entrées ayant un taux de rafraichissement situé entre 100 et 200 Hz. Le dispositif 40 peut comprendre tout processeur implémentant les modules logiciels de collecte 41 et de traitement 42 et capable de stocker les données en entrée, c’est-à-dire les données de vol V et les données de maintenance M, dans un buffer (aussi appelé « mémoire tampon »), pour ensuite les mettre à disposition d’applications mises en œuvre par le processeur. De manière générale, un tel processeur doit être capable de traiter des données d’entrée ayant un taux de rafraichissement de 64 Hz, ou être capable de traiter les données d’entrée les plus véloces, c’est-à-dire les données d’entrées ayant un taux de rafraichissement situé entre 100 et 200 Hz. Le dispositif 40 distingue les données de vol V des données de maintenance M par configuration, c’est-à-dire que le dispositif 40 a accès à un fichier de configuration lui indiquant sur quel(s) bus d’entrée se situent les données de maintenance M et sur quel(s) autre(s) bus d’entrée se situent les données de vol V. Ainsi, le dispositif 40 est capable de collecter simultanément des données de deux types différents et de les distinguer. La collecte de données comprend ainsi l’acquisition d’un premier flux de données de vol V et l’acquisition d’un deuxième flux de données de maintenance M. Le dispositif 40 est configuré pour collecter les données sur une fenêtre de temps glissante prédéfinie F. Les données sont mises en mémoire tampon (ou « bufferisées »), la mémoire tampon correspondant à la durée de la fenêtre temporelle glissante prédéfinie F. Cette fenêtre glissante prédéfinie F est « prédéfinie » en ce qu’elle a une durée prédéfinie par configuration, par exemple dans un fichier de configuration accessible au dispositif 40. La durée prédéfinie de cette fenêtre temporelle est par exemple comprise entre 1 minute et 15 minutes, préférentiellement de 5 minutes. Avantageusement, l’emploi d’un fenêtre glissante temporelle prédéfinie permet d’adapter la détection d’incidents aux causes d’incidents recherchées, par exemple en prédéfinissant une fenêtre temporelle plus longue pour détecter des incidents causés par des erreurs sur une période longue. Grâce à l’emploi d’une fenêtre temporelle glissante prédéfinie F, il est possible d’enregistrer facilement ce qui est stocké en mémoire tampon dans une mémoire plus durable 34 telle qu’un disque dur ou une mémoire non volatile. De plus, les données de vol V et de maintenance M sont synchronisées car elles sont comprises dans la mémoire tampon dès leur réception. A une étape 52 du procédé 50, le dispositif traite les données de maintenance M de l’aéronef collectées pour détecter un incident. La détection d’incident ne sera pas décrite. Tout procédé de détection d’incident à partir de données de maintenance M d’un aéronef peut être utilisé pour mettre en œuvre l’invention. Lors de la réception de données de maintenance M correspondant à un incident, par exemple à une panne P, le dispositif 40 est configuré pour réaliser l’étape 53. A l’étape 53, les données de vol V collectées correspondant à l’incident sont stockées dans une mémoire durable telle qu’une mémoire non volatile 34. Les données de vol V correspondant à l’incident peuvent être définies par configuration, par exemple dans un fichier de configuration accessible par le dispositif 40. Une telle configuration peut définir, en fonction d’un type d’incident, un ou plusieurs types de données de vol V à stocker. Les données de vol V correspondant à l’incident sont les données de vol V émises à un instant relatif à l’incident, par exemple avant, pendant et après l’incident. Pour stocker les données de vol V correspondant à l’incident détecté, le dispositif 40 transfère simplement le contenu de la mémoire tampon correspondant à la fenêtre temporelle glissante prédéfinie à l’instant de détection de l’incident vers une mémoire non-volatile 34. Les données de vol V correspondant à l’incident détecté, par exemple la panne P comme représenté à la , sont alors stockées conjointement aux données de maintenance M, et les données stockées sont synchronisées, grâce à la collecte simultanée par un même processeur des deux types de données : données de vol V et données de maintenance M, et grâce à la réalisation du traitement 52 par le même dispositif 40 qui a réalisé la collecte 51. Comme représenté à la , la fenêtre temporelle glissante F couvre bien les changement d’état des flux de données data1 et data2 ayant mené à la panne P, car la détection d’incident suite au traitement 52 est réalisée sans délai par le même dispositif 40 qui a réalisé la collecte des données. Ainsi, ce même dispositif 40 qui a traité les données de maintenance M a accès aux données de vol V synchronisées avec ces mêmes données de maintenance M ayant servi à détecter l’incident. Grâce à l’invention, il est donc possible de remonter à la cause racine de l’incident de manière simple et fiable. Dans un mode de réalisation préférentiel, le dispositif 40 comprend un unique processeur configuré pour mettre en œuvre les étapes de collecte 51 et de traitement 52 et au moins une mémoire 34. Dispositif embarqué dans un aéronef, l’aéronef comprenant une pluralité de systèmes produisant des données de vol (V) de l’aéronef et des données de maintenance (M) de l’aéronef, chaque système de la pluralité de systèmes de l’aéronef étant relié au dispositif par au moins un bus de données, le dispositif étant configuré pour collecter (51) simultanément les données de vol (V) de l’aéronef et les données de maintenance (M) de l’aéronef. Dispositif selon la revendication précédente selon lequel la collecte des données de vol (V) de l’aéronef comprend l’acquisition d’un premier flux de données prédéfini pour chaque système de la pluralité de systèmes de l’aéronef sur une fenêtre temporelle glissante prédéfinie (F) et la collecte des données de maintenance (M) de l’aéronef comprend l’acquisition d’un deuxième flux de données prédéfini pour chaque système de la pluralité de systèmes de l’aéronef sur ladite fenêtre temporelle glissante prédéfinie (F). Dispositif selon l’une quelconque des revendications précédentes, le dispositif étant configuré en outre pour : Traiter (52) les données de maintenance (M) de l’aéronef collectées pour détecter un incident, Lorsqu’un incident est détecté, stocker (53) les données de vol (V) collectées correspondant à l’incident. Dispositif selon les revendications 2 et 3 selon lequel le stockage des données de vol (V) correspondant à l’incident comprend le stockage des données de vol (V) de l’aéronef collectées pendant la fenêtre temporelle glissante prédéfinie (F) couvrant un instant durant lequel l’incident détecté a eu lieu. Dispositif selon l’une quelconque des revendications précédentes comprenant un unique processeur configuré pour réaliser les étapes de collecte et de traitement et au moins une mémoire configuré pour mettre en œuvre l’étape de stockage. Procédé d’acquisition et de traitement de données par le dispositif selon l’une quelconque des revendications précédentes, le procédé comprenant au moins les étapes de : Collecte (51) simultanée des données de vol (V) de l’aéronef et des données de maintenance (M) de l’aéronef, Traitement (52) des données de maintenance (M) de l’aéronef collectées pour détecter un incident, Lorsqu’un incident est détecté, stockage (53) des données de vol (V) collectées pendant la fenêtre temporelle glissante prédéfinie (F) correspondant à l’incident détecté. Aéronef comprenant le dispositif selon l’une des revendications 1 à 5. Produit programme d'ordinateur comprenant des instructions qui, lorsque le programme est exécuté par un ordinateur, conduisent celui-ci à mettre en œuvre le procédé d’acquisition et de traitement de données selon la revendication 6. Support d'enregistrement lisible par ordinateur comprenant des instructions qui, lorsqu'elles sont exécutées par un ordinateur, conduisent celui-ci à mettre en œuvre le procédé d’acquisition et de traitement de données selon la revendication 6.