Brevet FR3148312A1 — publié le 20241101

Procédé et dispositif de traitement automatisé d’une ou plusieurs alertes dans un aéronef Un aspect de l’invention concerne un procédé de traitement automatisé d’une ou plusieurs alertes dans un aéronef, une alerte étant associée à un événement relatif à l’état de l’aéronef, un événement pouvant être associé à une ou plusieurs alertes, le procédé étant mis en œuvre par un système de traitement automatisé comprenant un ou plusieurs panneaux de commandes numérisés et une unité de calcul, le procédé comprenant une étape de préparation du traitement des alertes ; une étape d’évaluation d’une ou plusieurs procédures associées à chaque alerte ; une étape de sélection d’un mode d’exécution des procédures à mettre en œuvre parmi un mode manuel dans lequel les actions associées à chaque procédure sont exécutées par l’utilisateur lui-même et un mode automatique dans lequel les actions associées à chaque procédure sont exécutées par le système de traitement automatisé ; une étape d’exécution des procédures de la liste ordonnée des procédures à mettre en œuvre, cette exécution s’effectuant conformément à l’ordonnancement de ladite liste lorsque le mode d’exécution automatique est sélectionné par l’utilisateur ; une étape d’affichage des actions mises en œuvre lors de l’étape précédente, des changements obtenus et/ attendus associés à chacune de ces actions et de l’adéquation entre les changements obtenus et les changements attendus. Procédé et dispositif de traitement automatisé d’une ou plusieurs alertes dans un aéronef DOMAINE TECHNIQUE DE L’INVENTION Le domaine technique de l’invention est celui de la gestion des alertes dans un aéronef. La présente invention concerne un procédé de traitement des alertes dans un aéronef et en particulier un procédé permettant d’automatiser en partie ou totalement ledit traitement. ARRIERE-PLAN TECHNOLOGIQUE DE L’INVENTION Lorsqu’un aéronef est confronté à un ensemble de défaillances importantes, le ou les pilotes doivent exécuter un ensemble de procédures pour décider si l’aéronef peut rester en condition de vol stabilisé et suffisamment navigable pour continuer le vol / la mission en cours, ou s’il est nécessaire de se dérouter pour atterrir au plus vite. Lors d’un événement majeur tel qu’une explosion moteur endommageant une partie de l’aile de l’aéronef, plusieurs dizaines d’alertes liées à des défaillances systèmes majeures sont affichées aux pilotes. Ce grand nombre d’alertes nécessite un traitement rapide et une prise de décision qui peut être complexe. Lorsqu’il y a plusieurs pilotes dans l’aéronef, ceux-ci peuvent traiter un nombre d’alertes important, par exemple en se répartissant la vérification de tous les systèmes de l’aéronef afin d’identifier les systèmes disponibles. Toutefois, cette répartition des tâches et leur traitement en coopération en situation de crise n’est pas forcément aisée. De plus, lorsqu’un pilote est seul, il lui est parfois impossible de traiter toutes les alertes tant elles sont nombreuses et complexes. Ainsi, il existe un besoin d’assister le ou les pilotes dans la gestion des alertes. Afin d’assister le ou les pilotes dans la gestion des alertes, le document WO 2021130520 A1 propose un système de gestion de défaillance pour des systèmes complexes. Plus particulièrement, le système proposé détermine et restaure la fonctionnalité de systèmes et de sous-systèmes défaillants à l'aide d'une approche d'intervention basée sur un graphe orienté de l'état de système. Mais si un tel système permet d’améliorer l’information du ou des pilotes, elle ne permet pas d’automatiser, ne serait-ce que partiellement la résolution des alertes. Il existe donc un besoin d’un dispositif et d’un procédé permettant d’automatiser, au moins partiellement, la gestion des alertes. L’invention offre une solution aux problèmes évoqués précédemment, en proposant un procédé de traitement automatisé d’une ou plusieurs alertes dans un aéronef. Pour cela, un premier aspect de l’invention concerne un procédé de traitement automatisé d’une ou plusieurs alertes dans un aéronef, une alerte étant associée à un événement relatif à l’état de l’aéronef, un événement pouvant être associé à une ou plusieurs alertes, le procédé étant mis en œuvre par un système de traitement automatisé comprenant un ou plusieurs panneaux de commandes numérisés et une unité de calcul, le procédé comprenant : Une étape de préparation du traitement des alertes comportant : Une sous-étape de stockage des alertes ainsi que d’un niveau de sévérité associé à chaque alerte ; Une sous-étape de vérification de l’absence d’un autre traitement automatisé d’alertes déjà en cours ; Une étape d’évaluation d’une ou plusieurs procédures associées à chaque alerte, ladite évaluation comportant : Une sous-étape de tri et d’ordonnancement des procédures en fonction d’une liste d’actions et vérifications à effectuer associées à chaque procédure de sorte à obtenir une liste ordonnée des procédures à mettre en œuvre ; Une sous-étape d’affichage de la liste ordonnée des procédures à mettre en œuvre, les procédures associées à l’alerte ayant le niveau de sévérité le plus élevée et/ou permettant de garantir des conditions de vol stable étant affichées en premier ; Une étape de sélection d’un mode d’exécution des procédures à mettre en œuvre parmi un mode manuel dans lequel les actions associées à chaque procédure sont exécutées par l’utilisateur lui-même et un mode automatique dans lequel les actions associées à chaque procédure sont exécutées par le système de traitement automatisé ; Une étape d’exécution des procédures de la liste ordonnée des procédures à mettre en œuvre, cette exécution s’effectuant conformément à l’ordonnancement de ladite liste lorsque le mode d’exécution automatique est sélectionné par l’utilisateur, ladite étape comportant, pour chaque action associée à chaque procédure : Lorsque le mode d’exécution automatique est sélectionné par l’utilisateur, une sous-étape d’exécution de l’action par le système de traitement automatisé ; Pour chaque action exécutée lors de la sous-étape précédente ou exécutée par l’utilisateur, une sous-étape de mise à jour de l’avancement de chaque procédure ainsi que des changements obtenus associés à cet avancement dans l’état de l’aéronef ; Une étape d’affichage des actions mises en œuvre lors de l’étape précédente, des changements obtenus et/ou attendus associés à chacune de ces actions et d’une adéquation entre les changements obtenus et des changements attendus. Grâce à l’invention, il est possible d’automatiser partiellement ou totalement le traitement de ces alertes, notamment en triant et ordonnançant les alertes à traiter et les actions et vérifications à effectuer. Il permet en outre de guider l’utilisateur (par exemple le pilote) dans le traitement de ces alertes lorsque ce dernier choisit de traiter tout ou partie de ces alertes de manière manuelle. L’invention permet notamment de diminuer la charge de l’utilisateur (par exemple le pilote) pendant la gestion d’une situation anormale afin de lui permettre de se focaliser sur le pilotage de l’aéronef. Outre les caractéristiques qui viennent d’être évoquées dans le paragraphe précédent, le procédé 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. Dans un mode de réalisation, l’étape de sélection d’un mode d’exécution des procédures à mettre en œuvre comprend une sous-étape d’affichage d’une fenêtre de dialogue permettant à l’utilisateur de choisir le mode d’exécution. Dans un mode de réalisation, l’étape d’exécution des procédures comprend, pour au moins une action associée à une procédure : Une sous-étape d’actionnement des éléments (numériques) du ou des panneaux de commandes ; et/ou Une sous-étape d’actionnement d’un ou plusieurs contacteurs électriques en lien avec les au moins une action associée à la procédure, de sorte à éteindre un composant défaillant et/ou allumer un composant de secours (ou « backup »). Dans un mode de réalisation, lors de la sous-étape de mise à jour de l’avancement de chaque procédure, une case cochée est affichée lorsqu’une action est réalisée et qu‘un résultat obtenu associé à ladite action est conforme à un résultat attendu. On entend par « résultat obtenu associé à une action », le résultat produit par les changements obtenus associés à ladite action. On entend par « résultat attendu associé à une action », le résultat produit par les changements attendus associés à ladite action. Dans un mode de réalisation, à l’issue de la sous-étape de mise à jour de l’avancement de la procédure considérée, lorsque les changements obtenus associés à l’action considérée ne sont pas conformes aux changements attendus associés à ladite action, le procédé comprend une sous-étape de sélection par l’utilisateur d’une marche à suivre parmi les deux marches à suivre suivantes : une poursuite de la procédure en cours ou de la procédure suivante si la procédure en cours est terminée, par la mise en œuvre des sous-étapes précédentes pour l’action suivante (c’est à dire la prochaine action de la procédure en cours ou la première action de la procédure suivante si la procédure en cours est terminée) ; ou lorsque les changements obtenus associés à l’action considérée entraînent la nécessité de mettre en œuvre une nouvelle procédure, l’exécution de cette procédure selon les sous-étapes précédentes, le traitement de la procédure en cours reprenant à la fin de la mise en œuvre de la nouvelle procédure ; La marche à suivre sélectionnée étant mise en œuvre par le système de traitement automatique. Dans un mode de réalisation, à l’issue de l’étape d’affichage des actions mises en œuvre, le procédé comprend une étape de transition du système de traitement automatisé dans un mode de surveillance dans lequel le système de traitement est configurée pour détecter la survenance d’une ou plusieurs alertes. Un deuxième aspect de l’invention concerne un système de traitement automatisé des alertes comprenant au moins un panneau de commande numérisé, une unité de calcul connectée au panneau de commande numérique et des moyens de contrôle de l’état des éléments unitaires qui composent un panneau de commande numérique, ledit système de traitement automatisé des alertes étant configuré pour mettre en œuvre un procédé selon le premier aspect de l’invention. Un troisième aspect de l’invention concerne un programme d'ordinateur comprenant des instructions qui, lorsque le programme est exécuté par un ordinateur, conduisent l'appareil selon le deuxième aspect de l’invention à exécuter les étapes du procédé selon le premier aspect de l’invention. Un quatrième aspect de l’invention concerne un support lisible par ordinateur, sur lequel est enregistré le programme d'ordinateur selon un troisième aspect de 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. Les à montrent une représentation schématique d’un procédé selon l’invention. La montre une représentation schématique d’un système selon l’invention. La montre un extrait d’un document MEL. La montre une représentation schématique de la fonction GEP. DESCRIPTION DETAILLEE Les figures sont présentées à titre indicatif et nullement limitatif de l’invention. Sauf précision contraire, un même élément apparaissant sur des figures différentes présente une référence unique. Dans la suite, une procédure est définie comme une ou plusieurs actions et/ou vérifications à effectuer. De plus, une action peut être associée à plusieurs procédures et elle peut être exécutée une fois ou plusieurs fois dans chaque procédure. Procédé de traitement automatisé d’une ou plusieurs alertes dans un aéronef Un premier aspect de l’invention illustré aux à concerne un procédé de traitement automatisé d’une ou plusieurs alertes dans un aéronef, une alerte étant associée à un événement ou une situation relatifs à l’état de l’aéronef, un événement ou une situation pouvant être associé à une ou plusieurs alertes. Plus particulièrement, dans un aéronef, le poste de pilotage est généralement pourvu de systèmes qui alertent l’utilisateur en cas de danger ou de défaillances de systèmes impactant le déroulement de la mission. Ces alertes sont matérialisées de plusieurs façons, par exemple : Un affichage de messages sur les écrans du poste de pilotage ; Des indications visuelles par des indicateurs dédiés (par exemple orange ou rouges en fonction de la criticité de la situation) aussi appelés « attention getter » ; Des alertes sonores par des messages vocaux ou des sons ; Des alertes sensitives par des vibrations ou pressions appliquées aux éléments avec lesquels l’utilisateur interagît avec l’aéronef. Ces alertes peuvent être de plusieurs natures et sont déclenchées dans certaines situations (par exemple, en cas de risque de collision avec un autre aéronef, en cas de risque de collision avec un obstacle ou avec le relief) ou bien encore en fonction de certains événements (par exemple, en cas de dysfonctionnement grave d’un ou plusieurs systèmes ayant un impact sur la navigabilité de l’aéronef). Le procédé selon l’invention vise à automatiser partiellement ou totalement le traitement de ces alertes, notamment en triant et ordonnançant les alertes à traiter et les actions et vérifications à effectuer, le procédé permettant en outre de guider l’utilisateur dans le traitement de ces alertes lorsque ce dernier choisit de traiter tout ou partie de ces alertes de manière manuelle. Le procédé selon l’invention est mis en œuvre par un système de traitement automatisé selon l’invention (décrit plus en détail dans la seconde partie de la description et illustré aux à ) comprenant une unité de calcul et un ou plusieurs panneaux de commandes numérisés. L’unité de calcul comprend un moyen de calcul tel qu’un processeur ainsi qu’une mémoire (par exemple une mémoire vive de type RAM et/ou un disque dur) configurée pour stocker les données et les instructions nécessaires à la mise en œuvre du procédé selon l’invention. Grâce à la numérisation, dans un panneau de commande d’un aéronef moderne, le comportement des éléments unitaires et des panneaux intégrés peut être contrôlé soit par une action de l’utilisateur, soit par une fonction logicielle exécutée par l’unité de calcul du système. On parle généralement de panneaux de commandes numérisés. Dans le système selon l’invention, lorsqu’une ou plusieurs alertes se déclenchent, le procédé selon l’invention est mis en œuvre de sorte à exécuter les étapes qui vont maintenant être décrites. Étape de préparation du traitement des alertes Comme illustré à la , le procédé selon l’invention comprend tout d’abord une étape E1 de préparation du traitement des alertes. Cette étape E1 comporte une sous-étape de stockage (par exemple dans la mémoire du système selon l’invention) des alertes ainsi que d’un niveau de sévérité associé à chaque alerte. Cette étape comprend également une sous-étape de vérification de l’absence d’un autre traitement automatisé d’alertes déjà en cours (par exemple lié à une mise en œuvre antérieure du procédé selon l’invention). Si aucune procédure n’est en cours, le procédé selon l’invention se poursuit. Dans le cas contraire, le procédé selon l’invention se met en pause jusqu’à ce que la ou les procédures associées au traitement d’une alerte en cours se terminent. De manière alternative, plusieurs procédures associées au traitement d’une ou de plusieurs alertes peuvent être traitées en parallèle. Le terme « en parallèle » signifie ici que leur traitement est concomitant et indépendant. Étape d’évaluation d’une ou plusieurs procédures associées à chaque alerte Comme illustré à la , le procédé comprend également une étape E2 d’évaluation d’une ou plusieurs procédures associées à chaque alerte, ladite évaluation comportant : Une sous-étape de tri et d’ordonnancement des procédures, par exemple en fonction d’une liste d’actions et vérifications (ou « Non-Normal Checklist ») à effectuer associées à chaque procédure de sorte à obtenir une liste ordonnée des procédures à mettre en œuvre ; Une sous-étape d’affichage de la liste ordonnée des procédures à mettre en œuvre, les procédures associées à l’alerte ayant le niveau de sévérité le plus élevé et/ou permettant de garantir des conditions de vol stable étant affichées en premier. Dans un exemple de réalisation, la sous-étape de tri et d’ordonnancement comprend, lors de la définition de l’aéronef, l’étude de l’ensemble des arbres de défaillance de tous les composants et systèmes de l’aéronef. De plus, cette étude peut être effectuée de manière plus précise pour les systèmes ou composants ayant un impact fort sur la sécurité des vols/la navigabilité. Cette étude permet au fabricant de construire un document appelé liste principale des équipements nécessaires minimum ou noté MMEL, pour Master Minimum Equipment List en anglais. Ce document estime l’impact de chaque composant ou système sur la navigabilité des vols. Le document MMEL, pouvant être fourni par le fabricant de l’aéronef, est utilisé pour construire un document plus restrictif MEL, qui est de la responsabilité de l’opérateur. Dans le cas où il y a plusieurs alertes à traiter, la phase de tri peut déterminer quelles alertes peuvent être réalisées en parallèle, un critère utilisé étant que les systèmes/composants incriminés dans les alertes n’ont pas de liens fonctionnels entre eux. Dans un exemple de réalisation, le niveau de sévérité des procédures associées à l’alerte peut être déterminé en tenant compte de deux critères : le niveau d’impact de la défaillance d’un composant et/ou d’un système sur le maintien de la stabilité de l’aéronef et/ou lorsqu’il y a plusieurs défaillances, quelle procédure exécuter en premier pour assurer au plus tôt la stabilité de l’aéronef. Ainsi, les procédures, qui comprennent une liste d’actions et de vérifications à réaliser, sont ordonnancées selon leur niveau de sévérité. Dans un exemple de réalisation, l’évaluation des procédures est réalisée en prenant deux types d’informations en compte ; le premier type est une liste d’actions associées à chaque alerte et définies par le système d’alertes, le deuxième type est une liste d’actions et de vérifications associées à chaque système et définies par la fonction prédictive MEL qui identifie les vérifications et potentielles restrictions opérationnelles à prendre en compte durant le vol ou durant une opération de maintenance avant vol. Dans un mode de réalisation, le procédé comprend une étape d’affichage à destination de l’utilisateur des restrictions à prendre en compte au moment où la phase de vol en question est atteinte. Dans un mode de réalisation, l’affichage de la liste des procédures et vérifications à effectuer est fait en fonction de l’ordre de priorité, du plus important au moins important, l’affichage comprenant également les éléments documentaires MEL étant présentés à l’utilisateur en correspondance avec l’alerte de plus haut niveau de priorité à traiter. Étape de sélection d’un mode d’exécution Comme illustré à la , le procédé comprend également une étape E3 de sélection d’un mode d’exécution des procédures à mettre en œuvre parmi un mode manuel dans lequel les actions associées à chaque procédure sont exécutées par l’utilisateur lui-même et un mode automatique dans lequel les actions associées à chaque procédure sont exécutées par le système de traitement automatisé selon l’invention. Autrement dit, une fois l’identification de la liste de procédures à mettre en œuvre effectuée, l’unité de calcul du système selon l’invention est configurée pour demander confirmation à l’utilisateur avant de lancer l’exécution automatique des procédures. Pour ce faire, dans un mode de réalisation, le procédé comprend la génération d’un message dans une fenêtre (par exemple de type « pop-up ») à l’écran. L’utilisateur peut choisir de valider l’exécution automatique des procédures (par exemple, en choisissant « Y ») ou pas (par exemple, en choisissant « N »). S’il choisit « N », l’utilisateur devra exécuter manuellement l’ensemble des actions liées à la ou les procédures. Toutefois, grâce à la numérisation de l’ensemble des éléments avec lequel le pilote interagit, l’unité de calcul est configurée pour enregistrer tous les changements d’états qui résulteront des actions de l’utilisateur. L’unité de calcul est également configurée pour diffuser ces changements d’états vers d’autres fonctions, par exemple la fonction prédictive MEL. Ce partage de l’état courant du poste de pilotage et des systèmes avion permet aux fonctions embarquées de corréler des informations pour améliorer l’assistance à l’utilisateur dans la poursuite de la mission. Étape d’exécution des procédures Comme illustré à la , le procédé comprend également une étape E4 d’exécution des procédures de la liste ordonnée des procédures à mettre en œuvre, cette exécution s’effectuant conformément à l’ordonnancement de ladite liste lorsque le mode d’exécution automatique est sélectionné par l’utilisateur. Cette étape comprend, pour chaque action associée à chaque procédure, lorsque le mode d’exécution automatique est sélectionné par l’utilisateur, une sous-étape d’exécution de l’action par le système de traitement automatisé. Lorsque le mode d’exécution est le mode manuel, chaque action est exécutée par l’utilisateur et seules les sous-étapes suivantes sont mises en œuvre à chaque action exécutée par l’utilisateur. Cette étape comprend également, pour chaque action considérée exécutée lors de la sous-étape précédente ou exécutée par l’utilisateur, une sous-étape de mise à jour de l’avancement de la procédure considérée ainsi que des changements obtenus associés à cet avancement dans l’état de l’aéronef. Cette étape comprend également, lorsque les changements obtenus associés à l’action considérée ne sont pas conformes à des changements attendus associés à ladite action, une sous-étape de sélection, par l’utilisateur, d’une marche à suivre parmi les deux marches à suivre suivantes : Une poursuite de la procédure en cours ou de la procédure suivante si la procédure en cours est terminée, par la mise en œuvre des sous-étapes précédentes pour l’action suivante (c’est à dire la prochaine action de la procédure en cours ou la première action de la procédure suivante si la procédure en cours est terminée) ; ou Lorsque les changements obtenus associés à l’action considérée entraînent la nécessité de mettre en œuvre une nouvelle procédure, l’exécution de cette procédure selon les sous-étapes précédentes, le traitement de la procédure en cours reprenant à la fin de la mise en œuvre de la nouvelle procédure ; La marche à suivre sélectionnée est ensuite mise en œuvre par le système de traitement automatisé. Dans un mode de réalisation, l’unité de calcul est configurée pour évaluer l’impact et décider de : Continuer à exécuter les actions suivantes de la procédure si l’action ou la procédure qui ne donne pas le résultat attendu n’impacte pas le déroulement des actions ou des procédures suivantes ; Suspendre l’exécution des actions suivantes de la procédure et informer l’utilisateur que le résultat obtenu d’une action automatique est différent du résultat ’attendu. La décision de poursuivre est dans les mains du pilote/utilisateur. Le traitement de ce cas est décrit dans l’étape E4bis. Ainsi, l’utilisateur n’a besoin d’intervenir que lorsque la procédure impacte le déroulement des actions et procédures suivantes. En règle générale, l’utilisateur évalue l’impact du résultat attendu de l’action suspendue. Si l’impact est faible (ou nul), l’utilisateur peut décider de relancer l’exécution automatique des actions suivantes de la procédure en cours ou des procédures suivantes si la procédure en cours est terminée. Si, au contraire, l’impact peut être important et/ou de nature à induire une ou plusieurs nouvelles procédures (aussi appelées procédures additionnelles ou procédures imbriquées) liées à ce nouvel état non attendu d’un système, l’utilisateur a le choix entre réaliser manuellement ou automatiquement les actions de la procédure imbriquée ou des procédures imbriquées. Lorsque l’utilisateur décide de lancer la procédure automatique, l’unité de calcul est configurée pour exécuter les actions de la procédure imbriquée de checklist. Une fois l’ensemble des actions effectuées avec succès, l’unité de calcul est configurée pour informer l’utilisateur du résultat obtenu de la procédure imbriquée. L’utilisateur valide le résultat obtenu de la procédure imbriquée et, dans le même temps, valide la continuation de la procédure initiale. Si durant l‘exécution des actions de la procédure imbriquée un nouveau résultat « non attendu » est obtenu, le processus précédemment décrit est à nouveau mis en œuvre. L’unité de calcul est configurée pour mettre en œuvre les étapes (et sous-étapes) précédentes autant de fois que nécessaire pour que l’ensemble des alertes soit traité. Dans un mode de réalisation, lors de la sous-étape d’exécution, l’unité de calcul est configurée pour exécuter les actions associées à chaque procédure de la manière suivante : Par le pilotage automatique des éléments numériques de panneaux de commande pour modifier le comportement d’une fonction aéronef ou d’un système en conformité avec la procédure du système d’alerte et/ou de la procédure prédictive MEL, Par le pilotage automatique de la modification d’un contacteur électronique via une fonction Gestionnaire des Contacteurs Electroniques de Distribution Electrique pour éteindre un système défaillant en conformité avec la procédure du système d’alerte et/ou de la procédure prédictive MEL, ou bien pour activer un système de compensation ou « backup » en conformité avec la procédure du système d’alerte et/ou de la procédure prédictive MEL. Dans un mode de réalisation, lors de la sous-étape de mise à jour, l’unité de calcul est configurée pour afficher la progression de l’exécution des actions listées par la procédure, à l’aide de « tick-box » validés par exemple, à chaque fois qu’une action est réalisée avec succès. Cela permet à l’utilisateur de suivre la progression des actions. Les informations affichées concernent par exemple les modifications de composants des panneaux de commandes numériques, les pages systèmes et/ou les procédures exécutées. De plus, l’unité de calcul est configurée pour enregistrer tous les changements d’états qui résultent des actions automatisées. En outre, l’unité de calcul est configurée pour diffuser ces changements d’états vers d’autres fonctions comme la fonction prédictive MEL et la fonction d’acquisition des paramètres de vol et systèmes. Ce partage de l’état courant du poste de pilotage et des systèmes avion permet aux fonctions embarquées de corréler des informations pour améliorer l’assistance à l’utilisateur dans la poursuite de la mission. Étape d’affichage Comme illustré à la , le procédé comprend également une étape E5 d’affichage des actions mises en œuvre lors de l’étape précédente, des changements obtenus et/ou attendus associés à chacune de ces actions et de l’adéquation entre les changements obtenus et les changements attendus. Dans un mode de réalisation, une fois l’ensemble des procédures (et des actions correspondantes) exécutées, l’unité de calcul est configurée pour générer un « pop-up » d’information listant l’ensemble des procédures exécutées et les tick-box associés montrant le résultat obtenu des actions. Dans un mode de réalisation, après validation par l’utilisateur du résultat obtenu, l’unité de calcul est configurée pour revenir à l’état de surveillance continue de l’apparition d’alerte de dysfonctionnement de système aéronef. Système selon l’invention Afin de mettre en œuvre le procédé selon l’invention, un deuxième aspect de l’invention concerne un système de traitement automatisé comprenant des moyens configurés pour mettre en œuvre ledit procédé. Plus particulièrement, le système selon l’invention comprend un panneau de commande numérisé. Dans un exemple de réalisation illustré à la , le panneau de commande numérisée PCN selon l’invention est configuré pour interagir avec des panneaux tactiles PT. Ces panneaux de commandes ou tactiles peuvent, grâce à leur numérisation, être personnalisés et/ou modifiés par exemple en reconfigurant l’utilisation d’un bouton et/ou panneau, en améliorant la surveillance fonctionnelle d’un bouton et/ou panneau. L’ensemble de ces panneaux est relié à l’unité de calcul UC (parfois désigné sous les termes RCCP/UCAP ou RCCP venant de l’anglais « Remote Centralized Control Panel » et UCAP venant de l’anglais « Ultra-Compact Avionics Platform »), cette unité de calcul UC comprenant l’ensemble des modules de service, et notamment : Un module MG de génération graphique Arinc 661 (standard de définition et réalisation d’interface homme-machine graphique certifiés aéronautiques) faisant notamment le lien avec des fonctions FIA, FIL et FIR; Un module MP de gestion/pilotage des panneaux de commandes faisant notamment le lien avec la fonction pilotage FIP; Un module MC de calcul centralisé. L’unité de calcul UC du système selon l’invention est configurée pour exécuter la fonction principale associée au procédé selon l’invention : la fonction Gestionnaire de Pages Ecran, d’exécution NNC (pour Non-Normal Checklist en anglais ou liste des vérifications anormales en français) et de pilotage RCCP, désignée dans la suite par fonction GEP. Cette fonction GEP permet notamment de modifier l’état d’un élément numérique du poste de pilotage tout en enregistrant l’état initial et l’état modifié afin de tracer tout changement. Elle permet également d’exécuter de manière automatique tout ou partie des procédures de la liste de vérifications (ou « check-list ») routinières durant la phase de préparation au vol. Elle permet également, dans le cas d’une situation anormale ou de défaillances de systèmes, de faire le lien avec le contenu de la « Minimum Equipment List » accessible à travers une fonction prédictive d’une liste d’équipements nécessaires minimum communément appelée MEL, pour « Minimum Equipment List » en anglais , dans le but d’exécuter automatiquement tout ou partie des procédures (et donc des actions et vérifications) associées à la gestion de la liste des vérifications anormales (NNC). Pour mémoire, les informations que l’on trouve dans le document MEL sont organisées par système (chapitre ATA pour Air Transport Association, ATA 36 dans l’exemple ci-dessus), sous-système (sous-chapitre ATA 36-11), sous-sous-système ou composant (sous-sous-chapitre ATA 36-11-05). Une telle organisation permet d’identifier finement les éléments contributeurs à la navigabilité de l’aéronef. Un exemple d’un extrait d’un document MEL A350XWB édité par la FAA qui illustre comment sont structurées les informations est représenté à la . Dans cet exemple, lorsque la condition ‘Engine Bleed IP Check Valve’ détecté non fonctionnel mais en position ‘ouverte’ est remplie, il y a deux types de recommandations à effectuer : (O) : vérifier durant le vol les impacts opérationnels afin de garantir la continuité de l’opération (M) : si le défaut apparaît lorsque l’aéronef est au sol, la décision de réaliser le vol est tributaire de la vérification des impacts fonctionnels et de leur prise en compte par l’utilisateur. Dans cet exemple, le dispositif (ou le procédé) selon l’invention, au travers de la fonction logicielle GEP, est configuré pour piloter l’exécution des vérifications décrites dans la procédure (O) durant le vol à savoir : Vérification : Vérifier que le système Bleed du moteur non affecté par la défaillance est complètement opérationnel ; ET Vérification : que la vanne Haute Pression du moteur affecté par la défaillance Bleed est désactivée et en position ‘fermée’ ; ET Restriction : A basse puissance, ne pas utiliser le système Bleed du moteur affecté dans les phases descente et taxi. De plus, le gestionnaire des contacteurs électroniques de distribution électrique permet de contrôler le pilotage des contacteurs électroniques. En effet, certaines procédures peuvent demander qu’un système défaillant soit éteint afin d’éviter toute perturbation du comportement global de l’aéronef. Dans d’autres cas, une procédure peut nécessiter un cycle de l’alimentation d’un système (Off – On) pour le faire passer dans un mode particulier de fonctionnement. En d’autres termes, le lien entre la fonction logicielle GEP et la fonction gestionnaire des contacteurs électroniques de distribution électrique permet donc l’automatisation du pilotage des contacteurs électroniques. En outre, la fonction GEP génère les pages système (ou System Pages en anglais) avec un ensemble de paramètres et un plan haut niveau d’architecture. Les pages système sont affichées sur l’écran dédié aux pages système. Les pages système décrivent de façon simplifiée une vue de l’architecture d’un système pouvant être complexe avec un focus sur les éléments principaux. Ces pages servent à informer le pilote de manière synthétique sur l’état de fonctionnement d’un système. Les systèmes affichés sont ceux ayant un impact sur le déroulement du vol quelle que soit la phase. Par exemple, un vol ne peut pas se dérouler si une des portes n’est pas correctement verrouillée, cette condition doit être détectée au sol avant la phase de taxi. Un exemple de page système peut comprendre les informations suivantes (basées sur la définition A350XWB) : APU page– (ATA49) BLEED page – (ATA36) C/B page – statut des contacteurs électroniques ouverts ou disjonctés (ATA24) CABIN PRESSURE page – pression et température cabine (ATA21) AIR CONDITIONING page – (ATA21) indication de détection de fumée et baie avionique et en cargo CRUISE page – statut Fuel, Air Conditioning et pression cabine. DOOR page – (ATA52) OXYGEN page (ATA35) ELEC AC page – (ATA24) ELEC DC page – (ATA24) ENG page – page complémentaire à des affichages moteurs dédiés (ATA70) FLIGHT/CTRL page – (ATA27) FUEL page – (ATA28 & 47) HYDRAULIC page – (ATA29) & statut des circuits hydrauliques avec paramètres principaux par exposition des vannes WHEEL page – (ATA32) & statut du train d’atterrissage, des freins et de la pression des pneus. Ainsi, la fonction logicielle GEP est configurée pour donner au pilote la conclusion des vérifications via la ou les pages système et indique les restrictions opérationnelles à prendre en compte et éventuellement les rappelle au pilote au moment des phases « descente » et « taxi » (en lien avec l’exemple illustratif utilisé dans ce document). La fonction GEP assure également le lien avec une fonction alerte de vols (ou FW pour flight warning en anglais) qui gère les alertes communiquées à l’utilisateur sur écran, sur indicateurs dédiés ou bien encore de manière audio. Plus particulièrement, la fonction alertes de vol FW génère des alertes en cas de défaillance de systèmes mais aussi lorsque l’aéronef vole trop près du relief, s’il y a risque de collision, et plus généralement lors de toute situation nécessitant l’attention de l’utilisateur pour prendre une action corrective. De même, durant une opération normale ou sans alerte active (situation non couverte par le procédé selon l’invention), le système FWS reçoit des informations circulant sur le ou les bus d’interconnexion de tous les systèmes de l’aéronef sous surveillance. La fonction centrale FC reçoit aussi des informations circulant sur le ou les bus d’interconnexion de tous les systèmes de l’aéronef sous surveillance et génère les pages systèmes à partir de ces informations. La fonction GEP permet également l’exécution automatique des procédures pas-à-pas tout en fournissant le retour d’information nécessaire à l’utilisateur. En général, ce retour est matérialisé par des affichages de pages systèmes sur le système d’affichage dont un écran ou une zone d’écran est dédié à ces affichages (ou « System Display » en anglais), de changement d’état du poste de pilotage (ou « cockpit control » en anglais) numérisé et/ou tout autre moyen qui permet de maintenir l’utilisateur informé de la situation courante ou de son évolution. Par exemple, lorsqu’une procédure peut impacter ou interférer avec une action de pilotage, cette fonction peut être configurée pour générer un message demandant l’accord du pilote/utilisateur avant d’exécuter la procédure. La fonction GEP assure également le lien avec tout ou partie de la fonction prédictive MEL pour évaluer les impacts opérationnels liés à une défaillance d’un système si l’information n’est pas déjà disponible avec la liste de vérification NNC. Pour cela, comme illustrée à la , cette fonction GEP est organisée autour d’une fonction centrale exécution d’automate, dite fonction centrale FC dans la suite. Cette fonction centrale FC fait le lien avec les fonctions extérieures (c’est-à-dire, ne faisant pas partie de la fonction GEP) suivantes : La fonction FWS ou CAS (de l’anglas « Flight Warning System » ou « Crew Alerting System ») qui permet, entre-autre, l’affichage des alertes au niveau du poste de pilotage de l’aéronef ; La fonction gestionnaire FD des contacteurs électriques et des distributions électriques ; La fonction prédictive MEL ; La fonction apprentissage FA ; La fonction acquisition FP de paramètres de vol et systèmes. En outre, au sein de la fonction GEP, la fonction centrale FC fait le lien avec les fonctions internes suivantes : La fonction pilotage FIP (RCCP) ; La fonction génération et affichage des pages système FIA ainsi que des procédures en cas d’alerte ; La fonction de génération de listes des procédures anormale FIL (ou Non Normal Check-List Procedures en anglais ou NNC) ; La fonction de de génération de liste de procédures de routine FIR (ou Routine Check-List Procedure en anglais ou RC). Dans un mode de réalisation, les différents systèmes de l’aéronef sont connectés entre eux par un ou plusieurs bus de connexion, et la fonction centrale FC est connectée aux bus d’interconnexion de sorte à pouvoir interagir avec les différents systèmes de l’aéronef, par exemple à l’aide des fonctions externes décrites précédemment. Dans le même temps, la fonction centrale FC génère les pages système via la fonction de génération graphique de confiance (basée sur le standard Arinc 661), acquiert et enregistre l’état des panneaux de contrôle numériques via la fonction, acquiert et enregistre l’état des contacteurs électroniques de la distribution électrique et fournit tout ou partie de ces informations à la fonction MEL Prédictive afin d’alimenter une base de connaissances à partir de laquelle la fonction d’apprentissage va être apprise et mise à jour. La fonction d’apprentissage va apprendre de toutes les situations anormales rencontrées et surtout de la manière dont ces situations anormales ont été gérées et résolues. Un des objectifs est d’améliorer le tri et l’ordonnancement des procédures à exécuter face à une situation multi-alertes et de déterminer si les alertes doivent être gérées séquentiellement ou s’il y a possibilité de paralléliser le traitement de certaines d’entre elles. Aussi, l’idée est que cette fonction d’apprentissage soit déployée sur tous les aéronefs d’une flotte et que tout l’apprentissage soit consolidé au niveau d’une flotte. Le but est de tirer crédit d’une montée en connaissance globalisée au niveau d’une flotte d’aéronefs. Grâce à cette organisation, l’unité de calcul UC (parfois appelée plateforme avionique) peut effectuer une surveillance continue de l’apparition d’alertes de dysfonctionnement. Cette surveillance est possible grâce au lien fonctionnel entre la fonction logicielle GEP et la fonction FWS. En outre, la fonction prédictive MEL qui se base sur la structure MEL apporte des fonctionnalités qui permettent de proposer une efficacité optimale. Ainsi, l’association de la fonction MEL avec la fonction logicielle GEP d’une part et la fonction OMS, pour « On-board Maintenance System » en anglais, d’autre part va permettre de créer un espace collaboratif embarqué et un recueil du résultat obtenu de toutes les actions exécutées par l’utilisateur et/ou la fonction GEP pour traiter les alertes. La fonction OMS est une fonction ou un système de maintenance centralisé embarqué. Généralement, la fonction OMS couvre plusieurs fonctions comme l’acquisition des paramètres de vol pour qu’une fonction pronostic puisse les traiter, l’acquisition de messages de maintenance pour qu’une fonction diagnostic puisse les traiter. Ainsi, la fonction d’acquisition de paramètres de vol et systèmes reçoit des informations circulant sur le ou les bus d’interconnexion de tous les systèmes de l’aéronef et de la part de tous les systèmes capables de générer des informations sous format numérique et disponibles sur le ou les bus d’interconnexion. En outre, grâce à la numérisation du poste de pilotage déjà mentionnée, la fonction logicielle GEP permet d’associer à la fonction centrale FC (dite de pilotage et d’exécution des procédures automatisées) une fonction d’apprentissage. Cette fonction d’apprentissage a pour objectif d’améliorer de façon continue le niveau d’accompagnement de l’utilisateur. Grâce à cette amélioration continue globale de la gestion des alertes dans un poste de pilotage, l’invention permet de préparer la transition entre les différents niveaux vers l’autonomie tels que définis par l’AESA à savoir : niveau 1 = assistance à l’humain ; niveau 2 = collaboration humain-machine ; niveau 3 = la machine exécute, l’humain est dans la boucle. Dans un mode de réalisation, la fonction centrale FC de la fonction GEP est développée suivant les standards aéronautiques les plus contraignants afin d’assurer un niveau de confiance dans l’exécution des procédures le plus élevé possible. Plus particulièrement, le développement de cette fonction est basé sur l’application des normes suivant un objectif de ‘Design Assurance Level’ ou DAL ; de préférence, pour le cas présent, le niveau de DAL ciblé sera B, c’est à dire un design permettant d’assurer qu’un comportement erratique avec une conséquence ‘Hazardous’ ne puisse pas avoir de probabilité d’occurrence supérieure à 10 e-7 , ou A, c’est à dire un design permettant d’assurer qu’un comportement erratique avec une conséquence ‘Catastrophique’ ne puisse pas avoir de probabilité d’occurrence supérieure à 10e -9 . Ainsi, le système selon l’invention qui vient d’être décrit, en mettant en œuvre le procédé selon l’invention, permet de décharger l’utilisateur dans l’exécution de procédures et de tâches de « bas niveau », ce qui permet à ce dernier de se focaliser sur la stabilité et la navigabilité de l’aéronef tout en alimentant une base de connaissance de l’état de navigabilité de l’aéronef. Procédé de traitement automatisé d’une ou plusieurs alertes dans un aéronef, une alerte étant associée à un événement relatif à l’état de l’aéronef, un événement pouvant être associé à une ou plusieurs alertes, le procédé étant mis en œuvre par un système de traitement automatisé comprenant un ou plusieurs panneaux de commandes numérisés et une unité de calcul, le procédé comprenant : Une étape (E1) de préparation du traitement des alertes comportant : Une sous-étape de stockage des alertes ainsi que d’un niveau de sévérité associé à chaque alerte ; Une sous-étape de vérification de l’absence d’un autre traitement automatisé d’alertes déjà en cours ; Une étape (E2) d’évaluation d’une ou plusieurs procédures associées à chaque alerte, ladite évaluation comportant : Une sous-étape de tri et d’ordonnancement des procédures en fonction d’une liste d’actions et vérifications à effectuer associées à chaque procédure de sorte à obtenir une liste ordonnée des procédures à mettre en œuvre ; Une sous-étape d’affichage de la liste ordonnée des procédures à mettre en œuvre, les procédures associées à l’alerte ayant le niveau de sévérité le plus élevée et/ou permettant de garantir des conditions de vol stable étant affichées en premier ; Une étape (E3) de sélection d’un mode d’exécution des procédures à mettre en œuvre parmi un mode manuel dans lequel les actions associées à chaque procédure sont exécutées par l’utilisateur lui-même et un mode automatique dans lequel les actions associées à chaque procédure sont exécutées par le système de traitement automatisé ; Une étape (E4) d’exécution des procédures de la liste ordonnée des procédures à mettre en œuvre, cette exécution s’effectuant conformément à l’ordonnancement de ladite liste lorsque le mode d’exécution automatique est sélectionné par l’utilisateur, ladite étape comportant, pour chaque action associée à chaque procédure : Lorsque le mode d’exécution automatique est sélectionné par l’utilisateur, une sous-étape d’exécution de l’action par le système de traitement automatisé ; Pour chaque action exécutée lors de la sous-étape précédente ou exécuté par l’utilisateur, une sous-étape de mise à jour de l’avancement de chaque procédure ainsi que des changements obtenus associés à cet avancement dans l’état de l’aéronef ; Une étape (E5) d’affichage des actions mises en œuvre lors de l’étape précédente, des changements obtenus et/ou attendus associés à chacune de ces actions et d’une adéquation entre les changements obtenus et les changements attendus. Procédé selon la revendication précédente dans lequel l’étape de sélection d’un mode d’exécution des procédures à mettre en œuvre comprend une sous-étape d’affichage d’une fenêtre de dialogue permettant à l’utilisateur de choisir le mode d’exécution. Procédé selon l’une des revendications précédentes dans lequel l’étape d’exécution des procédures comprend, pour au moins une action associée à une procédure : Une sous-étape d’actionnement des éléments (numériques) du ou des panneaux de commandes ; et/ou Une sous-étape d’actionnement d’un ou plusieurs contacteurs électriques en lien avec les au moins une action associée à la procédure, de sorte à éteindre un composant défaillant et/ou allumer un composant de secours (ou « backup »). Procédé selon l’une des revendications précédentes dans lequel, lors de la sous-étape de mise à jour de l’avancement de chaque procédure, une case cochée est affichée lorsqu’une action est réalisée et qu’un résultat obtenu associé à ladite action est conforme à un résultat attendu. Procédé selon l’une des revendications précédentes comprenant, à l’issue de la sous-étape de mise à jour de l’avancement de la procédure considérée, lorsque les changements obtenus associés à l’action considérée ne sont pas conformes aux changements attendus associés à ladite action, une sous-étape de sélection par l’utilisateur d’une marche à suivre parmi les deux marches à suivre suivantes : Une poursuite de la procédure en cours ou de la procédure suivante si la procédure en cours est terminée, par la mise en œuvre des sous-étapes précédentes pour l’action suivante (c’est à dire la prochaine action de la procédure en cours ou la première action de la procédure suivante si la procédure en cours est terminée) ; ou Lorsque les changements obtenus associés à l’action considérée entraînent la nécessité de mettre en œuvre une nouvelle procédure, l’exécution de cette procédure selon les sous-étapes précédentes, le traitement de la procédure en cours reprenant à la fin de la mise en œuvre de la nouvelle procédure ; La marche à suivre sélectionnée étant mise en œuvre par le système de traitement automatique. Procédé selon l’une des revendications précédentes comprenant, à l’issue de l’étape d’affichage des actions mises en œuvre, une étape de transition du système de traitement automatisé dans un mode de surveillance dans lequel le système de traitement est configurée pour détecter la survenance d’une ou plusieurs alertes. Système de traitement automatisé des alertes comprenant au moins un panneau de commande numérisé, une unité de calcul connecté au panneau de commande numérique et des moyens de contrôle de l’état des éléments unitaires qui composent un panneau de commande numérique, ledit système de traitement automatisé des alertes étant configuré pour mettre en œuvre un procédé selon l’une des revendications précédentes. Programme d'ordinateur comprenant des instructions qui, lorsque le programme est exécuté par un ordinateur, conduisent l'appareil selon la revendication précédente à exécuter les étapes du procédé selon l’une des revendications 1 à 6. Support lisible par ordinateur, sur lequel est enregistré le programme d'ordinateur selon la revendication précédente.