Titre de l’invention : Procédé de traitement de données d’un dispositif d’assistance au pilotage d’aéronefs

[0001] Domaine technique

[0002] L’invention concerne de manière générale le domaine de gestion de mission d’aéronefs, et en particulier un procédé de traitement de données d’un dispositif d’assistance au pilotage d’aéronefs.

[0003] Les aéronefs, qu’ils soient civils ou militaires, sont de complexité toujours croissante. La gestion stratégique des missions en cours et futures d’un aéronef, implique une charge de travail de plus en plus importante pour l’équipage, et notamment pour les pilotes, lorsqu’un évènement survient. Un évènement peut être un évènement interne à l’aéronef, tel qu’une défaillance d’un système, un problème médical d’un passager, ou un événement externe à l’aéronef, tel que par exemple un changement de météo ou une dégradation d’une installation. Un évènement peut aussi être un évènement opérationnel, comme par exemple une modification de la mission initialement prévue, pouvant résulter d’un évènement interne ou externe.

[0004] Les solutions connues d’assistance et/ou de gestion de missions en cours et futures d’un aéronef sont classiquement soit des systèmes purement avioniques soit des systèmes du monde ouvert. Par définition, les systèmes purement avioniques appelés ‘systèmes certifiés’ (ou parfois ‘systèmes de l’avionique certifiée’) sont soumis à des contraintes de certification sur le matériel et le logiciel. Les systèmes du monde ouvert appelés ‘systèmes non-certifiés’ (ou parfois ‘systèmes de l’avionique non-certifiée’), ne sont pas soumis aux mêmes contraintes de certification que les systèmes certifiés. Les systèmes non-certifiés couvrent du matériel pouvant accueillir du logiciel non-certifié mais soumis à une approbation opérationnelle de l’aéronef. Les systèmes non-certifiés ont l’avantage d’avoir moins de contraintes de développement, avec des processus de développement et de déploiement plus courts.

[0005] Ces systèmes non-certifiés ne tiennent pas compte de l’ensemble des données provenant des systèmes certifiés et non-certifiés de l’aéronef. Par exemple, les systèmes non-certifiés ne sont pas connectés à l’avionique. Ils ont donc une vision incomplète d’une situation courante car ils n’intègrent pas de manière continue l’état de l’aéronef et l’évolution de la mission prévue. Ces systèmes ne permettent donc pas de proposer aux opérateurs de l’aéronef des propositions ou suggestions leur permettant de prendre une décision pertinente dans son ensemble. Au contraire, chacune des solutions connues présent uniquement des informations parcellaires ne permettant pas à elles seules de générer une vision globale du contexte de vol et du contexte environnemental.

[0006] Les systèmes non-certifiés sont généralement constitués de plusieurs applications, ayant chacune une fonctionnalité spécifique, qui ne sont pas adaptées pour délivrer des suggestions relatives à la mission dans sa globalité. Typiquement, les systèmes non-certifiés se contentent de présenter des affichages synthétiques de situations à des opérateurs de l’aéronef. Enfin, les systèmes non-certifiés ne proposent pas d’affichage d’informations basé sur le principe de notifications d’informations aux opérateurs de l’aéronef.

[0007] Les systèmes certifiés traitent avant tout des aspects tactiques et de sécurité d’un changement de contexte, c’est-à-dire orientés vers une réaction immédiate que les opérateurs de l’équipage doivent avoir. Les systèmes certifiés ne sont pas en mesure d’analyser les conséquences à moyens et/ou longs termes d’une situation courante. Même si ces systèmes certifiés évoluaient afin d’intégrer des capacités de suggestions, ils se trouveraient vite limités en termes de puissance de calcul et également en termes de capacités de collecte de nouvelles données, notamment du fait que leurs cycles de développement et d’évolution sont des cycles longs, et évidement du fait des contraintes de certification.

[0008] Avec les différents systèmes de l’état de l’art, lorsqu’un changement de l’état de l’aéronef ou un évènement extérieur survient, les opérateurs de l’équipage d’un aéronef doivent analyser les informations fournies par une multitude de systèmes et déterminer la stratégie d’adaptation de la mission qui lui parait être la meilleure.

[0009] La plupart du temps, les opérateurs de l’équipage d’un aéronef doivent se contenter d’analyser un sous-ensemble de données qui lui parait pertinent, car ils n’ont ni le temps ni la capacité de reconsidérer le contexte dans sa globalité, les informations étant trop nombreuses. Aussi, les opérateurs de l’équipage d’un aéronef font l’hypothèse que les seuls changements vis-à-vis de la situation initiale, sont ceux ayant déclenché l’analyse. Cependant, une telle hypothèse n’est pas toujours avérée. Par exemple, la météo sur un des aéroports de déroutement possible peut avoir évoluée entre la préparation du vol et son exécution. Les opérateurs de l’équipage d’un aéronef peuvent prendre la décision d’un déroutement sur cet aéroport inopérant, ce qui correspond à une mauvaise solution de déroutement.

[0010] Certaines solutions existantes de dispositif d’assistance au pilotage d’aéronefs visent à apporter des aides aux opérateurs de l’équipage pour leur permettre une analyse de l’impact d’un changement de contexte sur une mission en cours, comme décrit par exemple dans US 10096253 et US 10109203.

[0011] Cependant, ces solutions connues sont basées sur la présentation brute d’informations à l’équipage provenant directement de quelques systèmes. Ces solutions connues ne fournissent pas de propositions de suggestions établies sur des multicritères, selon l’ensemble des différents systèmes disponibles.

[0012] Les solutions existantes de dispositif d’assistance au pilotage d’aéronefs ne fournissent pas de procédé dynamique de calculs de suggestions et de générations de notifications d’informations issues de telles suggestions, permettant aux opérateurs d’un équipage d’analyser l’impact d’un changement de contexte sur la mission en cours de l’aéronef en prenant en compte les données de l’ensemble des différents systèmes certifiés et non-certifiés.

[0013] Il existe ainsi un besoin pour un procédé amélioré de traitement de données provenant d’un dispositif d’assistance au pilotage d’aéronefs.

[0014] Résumé de l’invention

[0015] La présente invention vient améliorer la situation en proposant un procédé de traitement de données générées par un dispositif de gestion des évènements, le dispositif déterminant des suggestions d’adaptation de mission à partir de sources de données de mission en cours ou futures, le procédé comprenant les étapes consistant à :

[0016] - recevoir du dispositif de gestion des évènements au moins une suggestion, la suggestion comprenant au moins une information et au moins une donnée liée à la construction de la suggestion ; [0017] - générer au moins une notification pour chaque suggestion reçue en fonction d’au moins une des informations, la notification comprenant la suggestion et au moins une métadonnée structurée à partir d'un registre de métadonnées ;

[0018] - enregistrer la au moins une notification dans une mémoire de notifications.

[0019] Le procédé comprend en outre au moins une itération des étapes suivantes :

[0020] - appliquer une opération de classification à une notification enregistrée dans la mémoire de notifications, l’opération de classification associant à la notification une classe X, la classe étant déterminée en fonction de règles prédéfinies parmi un ensemble de classes comprenant au moins une première classe V et une deuxième classe W ;

[0021] - appliquer un traitement à la notification en fonction de la classe X déterminée, le traitement comprenant une étape de génération d’un rendu de la notification sur une interface Homme-Machine si la classe X satisfait une condition d’affichage dépendant de l’appartenance de la classe X à la première classe V ou à la deuxième classe W, le rendu utilisant au moins une forme d’affichage et une dynamique d’affichage définies en fonction des métadonnées associées à la notification.

[0022] Dans un mode de réalisation particulier, les règles prédéfinies de détermination de la classe X peuvent dépendre d’un ensemble comprenant des critères de pondération, des critères définis par une ontologie et/ou des critères définis par des règles.

[0023] Les sources de données de mission en cours ou futures peuvent comprendre les données acquises de différents systèmes de l’avionique certifiée ou de l’avionique non-certifiée et/ou de différentes sources externes ou sources internes à l’aéronef, le procédé comprenant en outre une étape de transfert de données aux systèmes de l’avionique certifiée et/ou de l’avionique non-certifiée.

[0024] Dans un mode de réalisation, l’étape de transfert de données peut comprendre une étape de génération d’un rendu de la notification sur au moins une autre interface Homme-Machine reliée aux systèmes de l’avionique certifiée et/ou de l’avionique non-certifiée. [0025] Avantageusement, la notification peut comprendre une métadonnée d’horodatages, les horodatages comprenant un horodatage de génération de la notification, au moins un horodatage de classification de la notification, au moins un horodatage de traitement de la notification et/ou au moins un horodatage d’action lié à l’exécution d’une action.

[0026] Dans un mode de réalisation particulier, la première classe V peut identifier une notification « à exécuter » indiquant que la notification doit être exécutée et la deuxième classe W identifie une notification « à archiver » indiquant que la notification doit être archivée dans une mémoire de sauvegarde connectée aux sources de données de mission en cours ou futures.

[0027] Les classes peuvent comprendre en outre une troisième classe U identifiant une notification « en attente » indiquant que la notification doit être mise en attente.

[0028] Dans un mode de réalisation particulier, la classe X satisfait la condition de reclassification X ç U v X ç V, l'étape de traitement comprenant la réitération de l’étape consistant à appliquer une opération de classification.

[0029] L’étape de réitération de l’opération de classification peut être déclenchée en fonction :

[0030] - d’un contrôle d’une durée déterminée à partir de la métadonnée d’horodatages,

[0031] - d’une modification des données acquises pendant une mission, et/ou

[0032] - d’un contrôle d’une action détectée sur l’interface homme-machine.

[0033] Dans un mode de réalisation particulier, la classe X satisfait la condition de sauvegarde X ç W, l'étape de traitement comprenant une étape consistant à supprimer la notification de la mémoire de notifications et une étape consistant à archiver la notification dans la mémoire de sauvegarde.

[0034] Dans certains modes de réalisation, le registre de métadonnées peut comprendre en outre :

[0035] - une métadonnée de type simple associée aux notifications comprenant une information ou une action relative à au moins un paramètre de mission, l’information ou l’action étant déterminée à partir de la suggestion ; et [0036] - une métadonnée de type complexe associée aux notifications comprenant une concaténation de plusieurs informations ou actions relatives à au moins un paramètre de mission, les informations ou actions étant déterminées à partir de la suggestion.

[0037] Le registre de métadonnées peut comprendre en outre une métadonnée de priorité associée aux notifications, la métadonnée de priorité étant déterminée à partir de la suggestion et mise à jour à chaque étape du procédé, la métadonnée de priorité étant associée à l’importance et/ou l’urgence des informations ou des actions relatives à au moins un paramètre de mission, la métadonnée de priorité comprenant au moins deux indicateurs de priorité, incluant un indicateur de priorité élevée et un indicateur de priorité modérée.

[0038] En particulier, le registre de métadonnées peut comprendre une métadonnée définissant la catégorie des informations et/ou des actions relatives à la suggestion parmi des catégories d’environnement, et d’état de l’aéronef.

[0039] Dans des modes de réalisation, la forme d’affichage définie en fonction des métadonnées associées à une notification peut comprendre une première forme d’affichage et une seconde forme d’affichage, l’étape de génération de rendu utilisant la première forme d'affichage pour générer l’affichage d’au moins :

[0040] - un premier élément graphique, la sélection de l’élément graphique déclenchant la seconde forme d'affichage ;

[0041] - un deuxième élément graphique contenant une information ou une action relative à au moins un paramètre de mission, l’information ou l’action étant déterminée à partir de la suggestion, la sélection de l’élément graphique déclenchant l’affichage de l’information ou de l’action dans une première zone de la seconde forme d'affichage.

[0042] L’étape de génération de rendu peut comprendre :

[0043] - un décompte de notifications parmi le nombre de notifications n’ayant pas subi de rendu utilisant la seconde forme d'affichage ;

[0044] - une incrémentation du nombre de notifications n’ayant pas subi de rendu utilisant la seconde forme d'affichage. [0045] L’étape de génération de rendu peut utiliser la première forme pour générer en outre l'affichage du nombre de notifications décomptées non affichées dans le second mode d’affichage.

[0046] Alternativement, l’étape de génération de rendu peut utiliser la seconde forme d'affichage pour générer l’affichage d’au moins :

[0047] - la première zone comprenant un premier ensemble d’au moins un élément graphique, générée à partir d’une suggestion d’une notification dont la classe X satisfait la condition X ç V, les éléments graphiques du premier ensemble comprenant l’affichage d’au moins une information ou une action relative à au moins un paramètre de mission, l’information ou l’action étant déterminée à partir de la suggestion, les éléments graphiques comprenant en outre l’affichage d’au moins une durée définie par la métadonnée d’horodatages de la suggestion ;

[0048] - une deuxième zone comprenant un deuxième ensemble d’au moins un élément graphique, la sélection des éléments graphiques du deuxième ensemble déclenchant un filtrage du rendu des notifications selon des critères de filtrage ;

[0049] - une troisième zone comprenant un troisième ensemble d’au moins un élément graphique, générée à partir d’une suggestion d’une notification dont la classe X satisfait la condition de X ç W, le troisième ensemble comprenant un élément graphique de déclenchement, la sélection de l’élément graphique de déclenchement déclenchant l’affichage ou l’occultation de la troisième zone ;

[0050] - une quatrième zone comprenant un quatrième ensemble d’au moins un élément graphique, la sélection de l’élément graphique déclenchant l’interruption de l’étape de génération de rendu.

[0051 ] Avantageusement, si après une itération de l’étape consistant à appliquer une opération de classification d’une notification de classe X ç U, la classe X de la notification satisfait la condition X ç V, la notification étant associée à une métadonnée de type, alors l’étape de génération de rendu utilise la première forme d'affichage pendant une durée définie par la métadonnée d’horodatages de la notification.

[0052] Dans des modes de réalisation, si après une itération de l’étape consistant à appliquer une opération de classification d’une notification de classe X ç U, la classe X de la notification satisfait la condition X ç V, la notification étant associée à une métadonnée de complexe, alors l’étape de génération de rendu utilise la seconde forme d'affichage.

[0053] Il est en outre proposé un produit de programme informatique comportant des instructions pour l’exécution du procédé lorsque le programme est exécuté par un processeur.

[0054] L’invention fournit également un dispositif de traitement des suggestions d’adaptation de mission générées à partir de sources de données de mission en cours ou futures, les suggestions étant générées par un dispositif de gestion des évènements, le dispositif étant configuré pour :

[0055] - recevoir du dispositif de gestion des évènements au moins une suggestion, la suggestion comprenant au moins une information et au moins une donnée liée à la construction de la suggestion ;

[0056] - générer au moins une notification pour chaque suggestion reçue en fonction d’au moins une des informations, la notification comprenant la suggestion et au moins une métadonnée structurée à partir d'un registre de métadonnées;

[0057] - enregistrer la au moins une notification dans une mémoire de notifications ;

[0058] Le dispositif est en outre configuré pour mettre en oeuvre au moins une itération des opérations suivantes :

[0059] - appliquer une opération de classification à une notification enregistrée dans la mémoire de notifications (166-4), l’opération de classification associant à la notification une classe X, la classe étant déterminée en fonction de règles prédéfinies parmi un ensemble de classes comprenant au moins une première classe V et une deuxième classe W ;

[0060] - appliquer un traitement (450) à la notification en fonction de la classe X déterminée, le traitement comprenant une étape (452) de génération d’un rendu de la notification sur une interface Homme-Machine (180) si la classe X satisfait une condition d’affichage dépendant de l’appartenance de la classe X à la première classe V ou à la deuxième classe W, le rendu utilisant au moins une forme d’affichage et une dynamique d’affichage définies en fonction des métadonnées associées à la notification. [0061] Les modes de réalisation de l’invention fournissent ainsi un dispositif d’assistance au pilotage d’aéronefs amélioré capable de calculer des suggestions, de générer un affichage de telles suggestions et d’interagir dynamiquement avec les opérateurs d’un équipage à travers un tel affichage. De telles interactions sont adaptées pour minimiser la charge mentale des opérateurs d’un équipage, et fournir un temps de réponse optimisé du dispositif d’assistance.

[0062] Le dispositif et le procédé d’assistance au pilotage d’aéronefs selon les modes de réalisation de l’invention permettent de corréler l’intégralité des informations qui sont disponibles et de transmettre à un équipage, même réduit, les meilleures options (suggestions) de manière à permettre une prise de décision rapide et fiable, dans toutes les étapes d’un vol. Les informations délivrées par le dispositif et le procédé d’assistance au pilotage d’aéronefs selon les modes de réalisation de l’invention permettent ainsi une gestion optimale des tâches de l’équipage, y compris lorsqu’elles sont nombreuses.

[0063] Description des figures

[0064] D’autres caractéristiques, détails et avantages de l’invention ressortiront à la lecture de la description faite en référence aux dessins annexés donnés à titre d’exemple, dans lesquels :

[0065] [Fig.1] La figure 1 est un schéma d’une architecture informatique mettant en oeuvre le procédé de l’invention.

[0066] [Fig.2] La figure 2 est un schéma d’un dispositif de gestion des évènements, selon des modes de réalisation de l’invention.

[0067] [Fig.3] La figure 3 est un schéma d’un dispositif de traitement des suggestions mettant en oeuvre le procédé de traitement de données, selon des modes de réalisation de l’invention.

[0068] [Fig.4] La figure 4 est un organigramme représentant les étapes du procédé de traitement de données, selon des modes de réalisation de l’invention.

[0069] [Fig.5] La figure 5 est un organigramme représentant l’étape consistant à appliquer un traitement de notifications du procédé de traitement de données, selon des modes de réalisation de l’invention. [0070] [Fig.6] La figure 6 représente plusieurs exemples de rendu de notifications, sous forme condensée, sur une interface Homme-Machine.

[0071] [Fig.7] La figure 7 représente un exemple de rendu de plusieurs notifications, sous forme étendue, sur une interface Homme-Machine.

[0072] [Fig.8] La figure 8 représente un exemple de rendu d’une notification de type complexe, sous forme étendue sur une interface Homme-Machine.

[0073] Une référence identique utilisée dans plusieurs figures désigne des éléments identiques ou analogues.

[0074] Description détaillée

[0075] La figure 1 est un schéma d’une architecture informatique du dispositif d’assistance au pilotage d’un aéronef 100 selon des modes de réalisation de l’invention.

[0076] Le dispositif d’assistance au pilotage d’un aéronef 100 comprend des sources de données de mission en cours ou futures 120, un dispositif de gestion des évènements 140, un dispositif de traitement des suggestions 160 et une interface Homme-Machine 180.

[0077] Tel qu’utilisées ici, les sources de données de mission en cours ou futures 120 font référence à l’ensemble des données pouvant être acquises par le dispositif d’assistance au pilotage de l’aéronef 100 à travers différentes systèmes de l’avionique certifiée ou l’avionique non-certifiée et/ou de différentes sources externes (tel que l’environnement et la météorologie) ou sources internes à l’aéronef. Ces données sont accessibles au dispositif de gestion des évènements 140.

[0078] Le dispositif de gestion des évènements 140 est configuré pour effectuer une analyse puis corréler de manière fiable l’intégralité du contenu des sources données de mission en cours ou futures 120 pertinentes concernant un aéronef. Le dispositif de gestion des évènements 140 est notamment configuré pour déterminer si une adaptation d’une situation courante doit être réalisée par l’équipage de l’aéronef. Le cas échéant, le dispositif de gestion des évènements 140 peut fournir à l’équipage de l’aéronef une ou plusieurs suggestions représentant les solutions qui apparaissent les plus pertinentes pour cette adaptation. [0079] Comme illustré sur la figure 2, le dispositif de gestion des évènements 140 peut comprendre un module de compétences 142. Ce module comprend une ou plusieurs unités de calcul non représenté sur la figure. Ces unités de calculs peuvent être configurées pour calculer des évènements à partir des données ou paramètres de mission en cours ou futures, pour traiter des requêtes de résolution et/ou générer des propositions de résolution.

[0080] Le dispositif de gestion des évènements 140 peut comprendre en outre un module de traitement 144 configuré pour déterminer l’existence d’un impact sur la mission (ou sur un paramètre associé à une mission, appelé paramètre de mission) en cours de l’aéronef, soit à partir d’un évènement calculé, soit à partir d’une proposition de résolution.

[0081] Le dispositif de gestion des évènements 140 peut également comprendre un module de résolution 146 configuré pour émettre les requêtes de résolution à partir de l’existence d’un impact, pour évaluer et sélectionner des propositions de résolution selon des critères prédéfinis, et ainsi pour construire une suggestion, caractérisée comme une solution d’adaptation de la mission en cours de l’aéronef à partir d’au moins une proposition de résolution.

[0082] Dans un mode de réalisation, le dispositif de gestion des évènements 140 peut comprendre un module de gestion 148 configuré d’une part pour gérer des contentions et des priorités de flux, et d’autre part pour aiguiller les échanges entre les différents modules du dispositif

[0083] Telle qu’utilisée ici, une ‘suggestion’ désigne une ou plusieurs informations et/ou une proposition d’actions, relatives à un ou plusieurs paramètres de mission, prédéfinies par le dispositif de gestion des évènements 140. Une suggestion est destinée à être affichée sur l’interface Homme-Machine 180. Les informations d’une ‘suggestion’ peuvent comprendre en outre des données auxiliaires associées à une partie ou à l’ensemble des éléments liés à la construction de la suggestion (éléments de construction) Les données auxiliaires peuvent être par exemple des données de contexte liée à la construction de la suggestion (par exemple suggestion de déroutement vers un aéroport proche suite à un contexte de défaillance système de l’avionique). Les actions associées à une suggestion peuvent être exécutées par au moins un membre de l’équipage. Les suggestions calculées par le dispositif de gestion des évènements 140 peuvent être utilisées par les opérateurs de l’équipage comme support d’aide à la décision, par exemple dans le cadre de tâches de planification de vol et de mission, de gestion de la mission en cours et de systèmes constituant le cockpit, jusqu’à l’arrivée de l’aéronef à sa destination finale. Ainsi, une suggestion peut comprendre un ensemble de messages et/ou des données numériques spécifiques aptes à être utilisé(e)s par l’équipage comme aide à la prise de décision. Les suggestions déterminées par le dispositif de gestion des évènements 140 peuvent être de différentes natures, comme par exemple des suggestions correspondant à un rappel d’actions ou des informations stratégiques (par exemple suggestion d’optimisation ou encore une suggestion d’alternative suite à un évènement non prévu).

[0084] Le dispositif de gestion de mission de l’aéronef 140 peut être connecté au dispositif de traitement des suggestions 160, par exemple via le module de résolution 146 qui peut transférer les suggestions construites et sélectionnées. Avantageusement, le dispositif de traitement des suggestions 160 selon les modes de réalisation de l’invention permet de notifier des suggestions à l’équipage de l’aéronef, en mettant en oeuvre un tri et une analyse organisée des suggestions préalablement à leur affichage sur l’interface Homme-Machine 180, selon différentes échelles. Un tel affichage généré à partir d’un traitement optimisé des suggestions permet à l’équipage de traiter des suggestions ayant tout type de complexité, telles que des suggestions basiques (telles des mémos) et/ou complexes (telles des propositions stratégiques). Un tel traitement des suggestions est réalisé de manière à fournir des informations pertinentes, avec une complexité computationnelle et un temps de réponse optimisé, ce qui optimise les actions de l’équipage dans un environnement multifonctions où les informations sont nombreuses.

[0085] L’interface Homme-Machine 180 est au moins connectée au dispositif de traitement des suggestions 160. L’interface Homme-Machine 180 est configurée pour gérer les interactions d’un ou plusieurs opérateurs avec différents composants informatiques du dispositif d’assistance au pilotage d’un aéronef 100. Selon certains modes de réalisation, l’interface Homme-Machine 180 du dispositif d’assistance au pilotage d’un aéronef 100 peut être une interface Homme-Machine spécifique parmi un ensemble d’interfaces Homme-Machine pouvant être associées à un ou plusieurs autres systèmes constituant le cockpit. Avantageusement, l’interface Homme- Machine 180 peut être agencée dans un espace dédié au dispositif d’assistance au pilotage d’un aéronef 100, pouvant être utilisé à tout moment par les différents opérateurs de l’équipage de l’aéronef pour une aide à la « Situation Awareness » (terme anglais signifiant ‘conscience de la situation’), à la prise de décision, ou à la réalisation d’autres actions.

[0086] Les interactions entre opérateurs et dispositifs informatiques peuvent être d’ordre multimodal. De ce fait, les échanges d’informations peuvent être visuels, c’est-à-dire textuelle et graphique, auditifs ou encore tactiles/haptiques.

[0087] L’implémentation du dispositif d’assistance au pilotage de l’aéronef 100 peut par exemple être réalisée en intégrant différents composants sur une plateforme de calcul de l’avionique certifiée ou de l’avionique non-certifiée, ou répartis entre des plateformes de calcul de l’avionique certifiée, des plateformes de calcul de l’avionique non-certifiée et des plateformes de calcul d’une infrastructure sol. La plateforme de l’infrastructure sol est connectée à la plateforme avionique par une liaison de données.

[0088] Telle qu’utilisée ici, une action associée à une suggestion fait référence à une action exécutable par l’équipage en agissant sur au moins un des systèmes constituant le cockpit.

[0089] Une action exécutable par l’équipage peut être ainsi une action sur l’interface Homme-Machine 180 par un ou plusieurs opérateurs de l’équipage, en utilisant des moyens d’entrée (dispositif de pointage telle qu’une souris ou clavier, gestes sur un écran tactile, commande vocales, etc.). Un affichage d’une suggestion peut être généré sur l’interface Homme-Machine 180, sur un dispositif d’affichage (écran par exemple). Les moyens d’entrée (souris ou clavier par exemple) peuvent être utilisés par un opérateur de l’équipage pour sélectionner une ou différentes options associées aux suggestions, en réponse à cet affichage. L’opérateur de l’équipage peut également choisir de rejeter une suggestion retournée par le dispositif de gestion des évènements 140, par exemple en cliquant sur un bouton tactile affiché sur l’interface Homme-Machine sur lequel est indiqué « Rejeter ». L’opérateur de l’équipage peut aussi choisir de requérir, via l’interface Homme-Machine 180, des informations complémentaires quant à la suggestion et/ou aux informations disponibles utilisées pour construire la suggestion proposée, en cliquant sur un bouton tactile associé à la mention « Afficher plus de détails ». L’opérateur de l’équipage peut en outre choisir d’appliquer la suggestion, en cliquant sur un bouton tactile sur lequel est indiqué « Accepter ». Une telle action spécifique peut entraîner par exemple une automatisation au sein du dispositif d’assistance au pilotage de l’aéronef 100 pour ouvrir un des systèmes non-certifiés, afin d’y inclure les informations relatives à la suggestion acceptée au sein d’une planification de vol dans un espace de travail connecté à un système non-certifié. Avantageusement, cet espace de travail peut être connecté à un service tiers permettant l’importation des plans de vol produits dans un système certifié.

[0090] Une action de l’équipage peut aussi être définie comme une action réalisée par un ou plusieurs opérateurs de l’équipage directement sur un système certifié, telle qu’une action de modification du cap, une action de réglage de l’altitude, ou encore une action de changement de fréquence. Ainsi, une action de l’équipage peut être définie comme une action (ou manipulation) réalisée sur le système certifié ou non-certifié.

[0091] Avantageusement, le procédé de l’invention et le dispositif associé permettent de transférer les éléments de la solution d’adaptation de la mission en cours de l’aéronef aux sources de données de mission en cours ou futures 120 associées aux plateformes de l’avionique certifiée ou de l’avionique non-certifiée et d’une infrastructure sol. Ainsi, le dispositif de traitement des suggestions 160 peut être également connecté aux sources de données de mission en cours ou futures 120 afin de sauvegarder toutes les suggestions traitées et les informations liées à leur traitement. Cette opération de sauvegarde permet ainsi d’enrichir des critères prédéfinis de construction de résolutions et donc la recherche de solutions d’adaptation de mission par le dispositif de gestion des évènements 140. Cette recherche de solution devient ainsi plus performante au fil du temps.

[0092] Le dispositif de traitement des suggestions 160 est représenté de façon plus détaillée sur la figure 3, selon des modes de réalisation. Comme illustré sur la figure 2, le dispositif de traitement des suggestions 160 peut comprendre une unité de génération de notifications 162 apte à recevoir des suggestions à partir du dispositif de gestion des évènements 140. [0093] L’unité de génération de notifications 162 est configurée pour générer des notifications à partir de ces suggestions et d’un registre de métadonnée 166-2 inclus dans le dispositif de traitement des suggestions 160. Les métadonnées désignent des modèles de données techniques permettant de caractériser une notification. Un registre de métadonnée fait référence à un système de gestion des métadonnées. Une ‘notification’ comprend ainsi :

[0094] - la ou les informations (ou actions) liées à la suggestion, et

[0095] - des métadonnées caractérisant la notification.

[0096] L’unité de génération de notifications 162 peut comprendre en outre une horloge interne configurée pour associer un horodatage à la génération de la notification. Dans des modes de réalisation, l’horodatage dit ‘horodatage de création’ peut être inclus dans une des métadonnées de la notification.

[0097] L’unité de génération des notifications 162 peut être également configurée pour enregistrer les notifications créées dans une mémoire de notifications 166-4 incluse dans le dispositif de traitement des recommandations 160.

[0098] Dans des modes de réalisation, le dispositif de traitement de suggestions 160 peut comprendre une unité de classification et de traitement des notifications 164 apte à associer une classe mathématique spécifique aux notifications enregistrées dans la mémoire de notifications 166-4.

[0099] Une classe, encore appelée état, fait référence à un ensemble auquel peut appartenir une notification.

[0100] Dans des modes de réalisation, l’unité de classification et de traitement des notifications 164 peut utiliser un ensemble de critères prédéfinis afin d’associer une classe mathématique spécifique aux notifications. Ces critères peuvent comprendre des critères de pondération, des critères définis par une ontologie et/ou des critères définis par des règles.

[0101] L’unité de classification et de traitement des notifications 164 est ainsi configurée pour effectuer une opération de classification d’une notification, définie comme une analyse, selon des règles prédéfinies, de toutes les informations de la notification et pour calculer l’état de la notification à partir de cette analyse. [0102] L’unité de classification et de traitement des notifications 164 est en outre configurée pour traiter la notification en fonction de la classe qui lui est associée. Cette opération de traitement de la notification peut correspondre à l’application d’une nouvelle opération de classification de la notification définie comme une opération de reclassification et/ou la génération du rendu des notifications sur l’interface Homme-Machine 180, et/ou l’enregistrement des notifications dans une mémoire de sauvegarde 166-6.

[0103] Selon certains modes de réalisation, une classe peut correspondre à un état dit « en attente » indiquant que la notification doit être mise en attente par l’unité de classification et de traitement des notifications 164. Si la classe est dans un état « en attente », un affichage ne sera pas généré pour la suggestion sur l’interface Homme- Machine 180.

[0104] Une classe peut correspondre à un état dit « à exécuter » indiquant que la notification doit être exécutée par l’unité de classification et de traitement des notifications 164. Si la classe est dans un état « à exécuter », un affichage sera généré pour la suggestion sur l’interface Homme-Machine 180.

[0105] Une classe peut correspondre à un état dit « à archiver » indiquant que la notification doit être doit être archivée dans une mémoire de sauvegarde 166-6 connectée à l’unité de classification et de traitement des notifications 164 au sein du dispositif de traitement des suggestions 160. Si la classe est dans un état « à archiver », un rendu d’archivage sera généré pour la suggestion sur l’interface Homme-Machine 180.

[0106] Dans des modes de réalisation, la mémoire de notifications 166-4 du dispositif de traitement des suggestions 160 comprend uniquement les notifications ayant un état « en attente » ou « à exécuter ».

[0107] La mémoire de sauvegarde 166-6 peut former, pour le dispositif d’assistance au pilotage d’un aéronef 100, une source de données internes à l’aéronef au sein des sources de données de mission en cours ou futures 120.

[0108] Selon certains modes de réalisation, la génération du rendu d’une notification peut être multiple et contrôlée par l’unité de classification et de traitement des notifications 164. Le rendu d’une notification utilise au moins une forme d’affichage et une dynamique d’affichage définies en fonction des métadonnées associées à la notification.

[0109] L’unité de classification et de traitement des notifications 164 peut comprendre également une horloge interne utilisée pour associer un ou plusieurs horodatages à la classification ou reclassification de la notification, un ou plusieurs horodatages au traitement de la notification associés (notamment à de multiples générations de rendu), et/ou un ou plusieurs horodatages liés à l’exécution d’actions de l’équipage qui peuvent être associées à la notification. Ainsi, selon certains modes de réalisation, les horodatages de classification, les horodatages de traitement et les horodatages d’actions peuvent être ajoutés à l’horodatage de génération de notification, notamment par exemple dans une métadonnée dite ‘métadonnée d’horodatages’.

[0110] La figure 4 est un schéma décrivant les étapes du procédé de traitement de données selon des modes de réalisation de l’invention. Les données traitées par ce procédé sont des suggestions générées par un dispositif de gestion des évènements 140 à partir de sources de données de mission en cours ou futures 120.

[0111] A l’étape 410, une suggestion est reçue par le dispositif de traitement des suggestions 160.

[0112] A l’étape 420, une notification est générée pour chaque suggestion reçue à partir d’au moins une information (ou action) de la suggestion, telle que la notification comprend les informations de la suggestion et au moins une métadonnée structurée à partir d'un registre de métadonnées 166-2.

[0113] A l’étape 430, un enregistrement de la notification est effectué dans la mémoire de notifications 166-4.

[0114] A l’étape 440, une opération de classification est appliquée à la notification contenue dans la mémoire de notifications 166-4. Lors de cette étape une classe mathématique spécifique est associée aux notifications.

[0115] A l’étape 450, un traitement de la notification est appliqué en fonction de la classe mathématique associée. Les étapes 440 et 450 d’application d’une opération de classification et de traitement de la notification sont mises en oeuvre par l’unité de classification et de traitement des notifications 164. [0116] A l’étape 452, un rendu est généré sur l’interface Homme-Machine 180.

[0117] Selon certains modes de réalisation, le procédé de traitement de données peut comprendre une étape de transfert de données (non représentée dans les figures) aux systèmes de l’avionique certifiée et/ou de l’avionique non-certifiée. Notamment, lors de cette étape de transfert de données, un rendu de notification peut être généré sur une autre interface Homme-Machine reliée aux systèmes de l’avionique certifiée et/ou de l’avionique non-certifiée.

[0118] Afin de réaliser l’étape de génération d’un rendu sur l’interface Homme- Machine 180, l’unité de classification et de traitement des notifications 164 peut utiliser les informations comprises dans les métadonnées de la notification. En particulier, une ou plusieurs métadonnées peuvent caractériser le type de la notification. Un type de notification fait référence à un comportement global de notification. Tel qu’utilisé ici, le comportement global d’une notification englobe l’ensemble des éléments de rendu de la notification sur l’interface Homme-Machine 180 selon différentes formes d’affichage et la dynamique d’affichage de ces éléments de rendu. Pour cela, le type spécifie la ou les formes sous lesquelles la notification sera affichée dans l’interface Homme-Machine 180 pour générer un rendu de la suggestion associée. Ces formes permettent une ou plusieurs interactions pouvant être d’ordre multimodal, entre un ou plusieurs opérateurs de l’aéronef et le dispositif de traitement des suggestions 160. Un type de notification spécifie également la dynamique de représentation de la ou des différentes formes prédéfinies, en fonction notamment de la métadonnée d’horodatages de la notification.

[0119] L’étape 420 de génération d’une notification peut ainsi comprendre la détermination à partir du registre de métadonnée 166-2 d’une ou plusieurs métadonnées dites ‘métadonnées de type’, selon des règles prédéfinies associées à l’unité de génération des notifications 162, et en fonction des informations de la suggestion.

[0120] Selon certains modes de réalisation, une notification peut être caractérisée par une métadonnée de type « simple » ou de type « complexe ». Une métadonnée de type complexe peut être « complexe informative » ou « complexe conseil ». Pour faciliter la compréhension de l’invention, à titre d’exemple non limitatif, la description qui suit de certains modes de réalisation sera faite en référence à certains exemples de mécanismes d’association d’une métadonnée de type à une notification, selon une analyse de la suggestion. Avantageusement, l’analyse de la suggestion permet de déterminer si la proposition d’action ou l’information comprise dans la suggestion est claire et succincte, voire auto-suffisante, et facilement assimilable par un ou plusieurs opérateurs de l’équipage de sorte que la conséquence d’une action à mettre en oeuvre est évidente pour un ou plusieurs opérateurs de l’équipage. Cette analyse de la suggestion peut être mise en oeuvre par l’unité de génération de notifications 162 ou encore antérieurement par le dispositif de gestion des évènements 140. Cette analyse par le dispositif de 140 résulte en une ‘information de type’ par exemple (comprise dans la suggestion transmise au dispositif de traitement des suggestions 160) pour générer la métadonnée de type. L’homme du métier comprendra aisément que les mécanismes d’association d’une métadonnée de type peuvent être généralisés à d’autres cas pour construire l’ensemble des règles prédéfinies permettant la construction des notifications par l’unité de génération de notifications 162. Une règle de génération d’une notification dite ‘notification de type simple’ peut être définie par l’énumération d’une unique action, ou une unique information, relative à un ou plusieurs paramètres associés à une mission.

[0121] Une notification de type simple peut donc correspondre à une commande élémentaire destinée à être réalisée par un opérateur de l’équipage de l’aéronef sur un seul système constituant le cockpit. Une notification de type simple peut aussi comprendre une information élémentaire à transmettre à l’équipage comme par exemple une information indiquant que le statut du plan de vol a été mis à jour, le statut mis à jour étant l’un des statuts parmi : un statut « brouillon », un statut « rejeté >> ou un statut « validé >>.

[0122] Une autre règle de génération d’une notification de type simple peut être définie si la ou les actions peuvent être directement préréglées (ou pré-réglables) dans les systèmes de l’avionique, de sorte qu’un opérateur de l’équipage de l’aéronef peut simplement mettre en oeuvre ces actions par vérification et validation de l’action proposée dans les systèmes de l’avionique, sans nécessiter d’action directe dans l’interface Homme-Machine 180, si ces propositions d’actions sont adaptées. [0123] Selon l’exemple suivant, bien que nullement limitatif, une notification de type simple peut donc correspondre à une action unique de gestion de vol, calculée par le dispositif de gestion des évènements 140 suite à la détection de communications entre un contrôleur aérien et l’équipage. Notamment, le contrôleur aérien peut avoir fourni, par exemple oralement, une ou plusieurs autorisations à l’équipage telles que « Monter au niveau FL150 » ou encore « Prendre le cap 130 ». Une telle autorisation se traduit par le dispositif de gestion des évènements 140 comme une suggestion associée à une action simple. Avantageusement, une notification de type simple évite une prise de notes par l’équipage, lors de l’écoute d’instructions par le contrôleur aérien. Ainsi, le dispositif d’assistance au pilotage d’un aéronef 100 peut aisément être programmé pour reconnaître ces suggestions et subséquemment prérégler automatiquement ces actions dans un système de l’avionique.

[0124] En outre, une règle de génération d’une notification dite ‘notification de type complexe’ peut être définie par l’énumération de plusieurs actions et/ou plusieurs informations, relatives à un ou plusieurs paramètres associées à une mission.

[0125] Selon l’exemple suivant, bien que nullement limitatif, une notification de type complexe peut donc correspondre à une ou plusieurs commandes ayant plusieurs contraintes de manipulation d’un ou plusieurs opérateurs de l’équipage de l’aéronef, telles qu’elles engendrent par exemple des actions à réaliser sur plusieurs fonctions de l’avionique pas nécessairement co-localisées, ou plusieurs systèmes constituant le cockpit. Une notification de type complexe peut aussi comprendre plusieurs informations venant de différentes sources de données de mission en cours ou futures 120, que l’opérateur de l’équipage doit prendre en compte pour traiter la notification. Par exemple, une telle notification peut être une proposition de déroutement vers un aéroport proche suite à une défaillance système de l’avionique.

[0126] En particulier, une règle de génération d’une notification dite ‘notification de type complexe informative’ peut être définie comme une notification de type complexe permettant de préparer à l’avance les actions à effectuer dans les systèmes de l’avionique.

[0127] Une notification de type « complexe informative » peut par exemple correspondre à plusieurs informations ou propositions d’actions permettant d’ajuster le cap, régler l’altitude, changer de fréquence, etc. Avantageusement, une notification de type « complexe informative » évite une prise de notes par les opérateurs de l’équipage de l’aéronef, lors de la phase de préparation des étapes de vol en cours ou à venir. Une notification de type « complexe informative » peut de plus être une concaténation de notifications de type simple permettant un préréglage automatique d’une multitude d’actions dans divers systèmes de l’avionique. Par exemple, une telle notification peut être une proposition de consigne ATC : « Descent at alt. 10000ft at 25 nm before WPT » (instruction technique du domaine en langue anglaise signifiant ‘Descendre à l'altitude de 10000ft à 25nm avant WPT’).

[0128] Une règle de génération d’une notification dite ‘notification de type complexe conseil’ peut être définie comme une notification de type complexe induisant un impact sur la mission en cours, notamment un impact sur le plan de vol ou comportant plusieurs choix possibles à effectuer par un ou plusieurs opérateurs l’équipage de l’aéronef. Dans ce cas, la notification a une compréhensibilité suffisante pour expliquer aux opérateurs la suggestion construite par le dispositif de gestion des évènements 140. Avantageusement, une telle notification est émise dans l’objectif d’optimiser la performance et de proposer des stratégies alternatives de mission en cours ou futures.

[0129] Une notification de type « complexe conseil » peut correspondre à une suggestion contenant différents choix calculés et retenus par le dispositif de gestion des évènements 140 selon différents critères, par exemple le Flight Policy (terme anglais signifiant ‘politique de vol’), des requêtes spéciales dites VIP, etc. Une notification de type « complexe conseil » peut par exemple être liée à la détection d’un évènement météo impactant la mission en cours, notamment avec le calcul par le dispositif de gestion des évènements 140 de la nécessité de modifier le plan de vol pour contourner la zone météo non accessible par l’aéronef.

[0130] Selon un autre exemple, suite à une défaillance système de l’avionique (par exemple une panne hydraulique, ou la présence d’un feu moteur sur l’aéronef), le dispositif de gestion des évènements 140 peut prendre en compte plusieurs sources de données de mission en cours ou futures 120, telles que des sources de données météorologiques, de performances avionique ou encore d’informations aéroportuaires, pour déterminer une ou plusieurs suggestions relatives au maintien de la mission en cours, et/ou à la modification de la mission en cours et/ou des missions futures. Une notification de type « complexe conseil » peut par exemple être liée à la proposition de plusieurs aéroports possibles (en prenant en compte un ensemble de critères) pour le cas d’une action de déroutement vers un aéroport proche.

[0131] Le registre de métadonnées 166-2 utilisé par l’unité de génération de notifications 162 peut comprendre des indicateurs de priorité qui peuvent être associés aux notifications selon des règles prédéfinies et en fonction des informations de la suggestion. Tel qu’utilisé ici, un indicateurs de priorité fait référence à la priorité d’affichage de la suggestion. L’indicateur de priorité peut être défini par exemple en fonction d’informations d’importance et/ou d’urgence de transmission de la suggestion à l’équipage. Ces informations d’importance et/ou d’urgence sont associées à la suggestion (par exemple pour indiquer une importance « haute » ou « basse », ou une urgence « haute » ou « basse ») par le dispositif de gestion des évènements 140. Les informations d’importance et/ou d’urgence peuvent en outre être modifiées en fonction d’horodatages et/ou de données de mission en cours ou futures à chaque étape du procédé de l’invention par le dispositif de traitement des suggestions 160. La métadonnée dite ‘métadonnée de priorité’ évolue donc avec la priorité de la suggestion. La métadonnée de priorité est prise en compte lors de l’étape 440 d’application d’une opération de classification à la notification, et de l’étape 450 d’application d’un traitement de la notification, mises en oeuvre par l’unité de classification et de traitement des notifications 164.

[0132] Selon certains modes de réalisation, une métadonnée de priorité peut être « modéré » ou « élevé ». Une notification dite ‘notification de priorité modérée’ fait référence à une suggestion de priorité basse pour la mission en cours, alors qu’une notification dite ‘notification de priorité élevée’ fait référence à une suggestion de priorité haute à délivrer à l’équipage, en lien avec par exemple un possible état critique d’un composant dans un des systèmes certifiés de l’avionique.

[0133] Avantageusement, l’intégration d’une métadonnée de priorité dans le procédé de l’invention permet d'identifier aisément le niveau d’importance et/ou d’urgence d’une suggestion, et en conséquence de réduire la charge de travail de l’équipage, les opérateurs étant plus attentifs aux tâches prioritaires intégrées dans leurs flux d’actions. [0134] A Tissue de l’étape 440 d’application d’une opération de classification à la notification enregistrée dans la mémoire de notifications 166-4, une classe notée X est associée à la notification x. La classe X(x) est déterminée parmi un ensemble de classes (U, V et W par exemple), et en fonction de règles prédéfinies mises en oeuvre par l’unité de classification et de traitement des notifications 164. La première classe correspondant à la classe de notifications « à exécuter » par l’unité de classification et de traitement des notifications 164 est notée V. La deuxième classe correspondant à la classe de notifications « à archiver » (dans une mémoire de sauvegarde 166-6) est notée W. La troisième classe d correspond à la classe des notifications « en attente ».

[0135] La figure 5 est un schéma illustrant les différentes sous-étapes possible de l’étape 450 d’application d’un traitement de la notification en fonction de la classe X déterminée, par l’unité de classification et de traitement des notifications 164, selon des modes de réalisation.

[0136] L’étape 452 de génération d’un rendu sur l’interface Homme-Machine 180 est une sous-étape du traitement de notification. Cette sous-étape 452 est mise en oeuvre si une notification appartenant à la classe X satisfait une condition d’affichage définie telle que X ç V v X ç W (1). La formulation (1) indique que la classe X est soit incluse dans la première classe V ou soit incluse la deuxième classe W.

[0137] A la sous-étape 454, la notification peut être supprimée de la mémoire de notifications 166-4, puis sauvegardée dans la mémoire de sauvegarde 166-6 dans la sous-étape 456. Ces sous-étapes 454 et 456 sont mises en oeuvre si la notification traitée correspond à une classe X satisfaisant la condition de sauvegarde X ç W (2). La formulation (2) indique que la classe X est incluse dans la deuxième classe W.

[0138] L’étape 440 d’application d’une opération de classification mise en oeuvre par l’unité de classification et de traitement des notifications 164 peut être réitérée, telle une sous-étape possible de l’étape 450, si la notification traitée correspond à une classe X satisfaisant une condition de reclassification X ç U v X ç V (3). La formulation (3) indique que la classe X est soit incluse dans la première classe V ou soit incluse la troisième classe U.

[0139] Le procédé selon les modes de réalisation de l’invention permet ainsi un traitement efficace des suggestions et un affichage optimisé des notifications associées sur l’interface Homme-Machine 180 (c’est-à-dire déclenché aux instants les plus adaptés), compte tenu du contenu des suggestions et de la surveillance de la situation courante de la mission. La surveillance de la situation courante de la mission fait référence aux mises à jour, effectuées selon une fréquence prédéfinie par le dispositif, des sources de données de mission en cours ou futures 120, afin notamment de maintenir :

[0140] - la surveillance de l’état de l’aéronef et de l’avionique (par exemple et de manière non limitative par une veille de la phase de vol),

[0141] - la surveillance de l’environnement (par exemple par une veille météo), et/ou

[0142] - la surveillance des actions des opérateurs de l’équipage de l’aéronef (par exemple une veille des interactions des opérateurs sur différentes interfaces Homme-Machine des systèmes constituant le cockpit), ou encore la surveillance de l’état physiologique des opérateurs de l’équipage de l’aéronef (c’est-à-dire une veille associée à des capteurs auditifs, visuels ou encore de santé connectés aux opérateurs).

[0143] Ainsi, l’unité de génération de notifications 162 et l’unité de classification et de traitement des notifications 164, sont adaptées pour prendre en compte dans leurs règles prédéfinies respectives, une partie au moins du contenu des suggestions, et une partie au moins de la surveillance de la situation courante de la mission. Selon certains modes de réalisation, ces unités 162 et 164 peuvent être connectées au moins en partie aux sources de données de mission en cours ou futures 120 (exemple, mise à jour de contexte suite à un changement de phase de vol).

[0144] En particulier, l’étape 440 d’application d’une opération de classification peut prendre en compte des informations relatives :

[0145] - aux suggestions,

[0146] - à la surveillance de la situation courante de la mission et notamment à la capacité des opérateurs de l’équipage à traiter la notification,

[0147] - au type de la notification (« simple » ou « complexe » par exemple) et à l’indicateur de priorité de la notification (par rapport au moment présent par exemple), et/ou [0148] - aux différents horodatages de la notification par l’unité de génération de notifications 162 et l’unité de classification et de traitement des notifications 164.

[0149] Le procédé de traitement de données décrit en figure 4 comprend donc au moins une itération des étapes 440 d’application d’une opération de classification, 450 d’application d’un traitement de la notification et 452 de génération de rendu de notification.

[0150] Pour faciliter la compréhension de l’invention, la suite de la description sera faite en référence à certains mécanismes de l’étape 440 d’application de l’opération de classification d’une notification, à titre d’exemples non limitatifs. L’homme du métier comprendra aisément que ces mécanismes peuvent être généralisés à tout mécanisme permettant d’appliquer l’opération de classification à l’ensemble des notifications par l’unité de classification et de traitement des notifications 164.

[0151] La classe U dite « en attente » peut être associée aux notifications dont les suggestions doivent être mises en attente. Des suggestions mises en attente correspondent aux suggestions devant être communiquées à l’équipage de l’aéronef, mais pour lesquelles l’instant optimal de communication (moment le plus adapté et le plus pertinent pour une telle communication) n’est pas encore atteint (l’instant optimal est ainsi un instant futur). Avantageusement, de telles notifications sont enregistrées dans la mémoire de notifications 166-4 et un traitement de génération d’un rendu sur l’interface Homme-Machine 180 pour ces notifications n’est pas appliqué. Ces notifications restent donc invisibles à l’équipage de l’aéronef, ce qui limite la charge computationnelle et l’encombrement visuel de l’interface Homme- Machine 180. Il en résulte une réduction de la charge mentale des opérateurs de l’équipage, ces notifications étant destinées à être traitées ultérieurement.

[0152] Par exemple, en considérant une mission de plusieurs legs (terme anglais technique du domaine signifiant ‘vols’), les notifications, associées à des suggestions fournies par le dispositif de gestion des évènements 140 concernant un événement météorologique impactant le leg suivant, peuvent être classées « en attente ». Ainsi, selon une règle prédéfinie ces notifications ne seront pas retournées à l’équipage, via l’interface Homme-Machine 180, dans le cas où l’aéronef se trouve dans une situation de phase d’approche. En effet, cette phase de vol correspond à un moment critique de pilotage de l’aéronef. De ce fait, un rendu de telles notifications lors de cette phase serait inutile, voire dangereux, et augmenterait notamment momentanément la charge mentale de l’équipage. Cette notification peut cependant être affiché à un instant ultérieur plus optimal, par exemple lorsque l’aéronef sera au sol dans une situation de phase de préparation du /eg suivant.

[0153] Dans un autre exemple, suite à une défaillance système de l’avionique (par exemple une panne hydraulique, ou la présence d’un feu moteur sur l’aéronef), l’équipage a pour premier objectif de maîtriser cette défaillance système et ramener l’avion dans un état stable. Les premières actions de l’équipage concernent donc le traitement de cette défaillance. Les notifications reliées aux solutions de reconfigurations de mission liées à cette défaillance ne doivent pas être affichées tant que ces premières actions ne sont pas complétées. A titre d’exemple, les opérateurs de l’équipage sont tenus dans un premier temps de dérouler une ou des procédures (plus ou moins longues) liées à l’alerte levée par le système certifié FWS (acronyme pour l’expression anglo-saxonne correspondante « Flight Warning System »). Ensuite seulement, lorsque la défaillance est maîtrisée, les opérateurs de l’équipage peuvent considérer un déroutement vers un aéroport proche. En outre, le dispositif de gestion des évènements 140 peut avoir calculé en parallèle des solutions de déroutement à suggérer à l’équipage. Cependant, selon l’invention, la notification associée, générée et traitée par le dispositif de traitement des suggestions 160, ne sera affichée que lorsque les opérateurs de l’équipage seront le plus à même de la prendre en considération, c’est-à-dire une fois que les opérateurs auront terminées les procédures de traitement de la défaillance.

[0154] La classe V dite « à exécuter » est ainsi associée aux notifications à afficher en temps réel ou quasi-réel. L’affichage de la notification doit être exécuté.

[0155] La classe W dite « à archiver » est associée aux notifications dont les suggestions sont considérées comme traitées. La notification doit être archivée dans une mémoire de sauvegarde (166-6) connectée auxdites sources de données de mission en cours ou futures (120).

[0156] Selon certains modes de réalisation, une notification correspondant à la classe X ç U « en attente » ou à la classe X ç V « à exécuter » peut subir une opération de reclassification vers la classe W, dite « à archiver », dans le cas où la suggestion n’est plus pertinente par rapport à la surveillance de la situation courante. [0157] Selon certains modes de réalisation, une notification correspondant à la classe d ç V considérée « à exécuter » peut subir une reclassification vers la classe W dite « à archiver » suite à une ou plusieurs actions de l’équipage indiquant un rejet ou une acceptation de la suggestion associée à la notification. Par exemple, un opérateur peut « Rejeter » ou « Accepter » la suggestion au travers l’interface Homme-Machine 180.

[0158] Dans l’exemple précité de la défaillance système de l’avionique, suite à l’alerte levée par le FWS, l’unité de classification et de traitement des notifications 164 associe aux notifications reliées aux solutions de reconfigurations de mission liées à cette défaillance la classe U dite « en attente ». Lorsque les procédures de traitement de la défaillance sont terminées, l’information est intégrée dans les sources de données de mission en cours ou futures 120, ce qui engendre une opération de reclassification de l’ensemble des notifications liées à cette défaillance. L’unité de classification et de traitement des notifications 164 associera, lors de cette opération de reclassification la classe V dite « à exécuter » aux notifications relatives à des solutions de reconfigurations de mission liées à cette défaillance.

[0159] Dans un mode de réalisation, l’étape 440 d’application de l’opération de classification d’une notification correspondant à la classe X ç V (classe « à exécuter ») peut être mise en oeuvre en fonction des horodatages associés à la notification. En particulier, une telle notification peut subir une reclassification vers la classe W dite « à archiver » en fonction d’un temps prédéterminé et calculé à partir de la métadonnée d’horodatages de la notification, tels que l’horodatage de création, les horodatages de classification, les horodatages de traitements, et/ou les horodatages d’actions de la notification.

[0160] En considérant par exemple une notification de type simple ou complexe ayant une classe X ^ K considérée « à exécuter » et un horodatage de cette classification noté T _{v ciassification)} , la notification peut subir une reclassification vers la classe W dite « à archiver » si l’unité de classification et de traitement des notifications 164, ayant une horloge interne définissant un temps t, détecte une durée spécifique définie par T _o = t - T _{v ciassification} , avec T _o désignant une valeur préfixée par des règles de reclassification des notifications de type simple ou complexe. Avantageusement, cela permet à une notification de type simple ou complexe d’être automatiquement rejetée par le dispositif de traitement des suggestions 160 au bout d’un certain temps, tel que par exemple T _o = 5 minutes.

[0161] Selon un autre exemple, une notification de type complexe ayant une classe X ç V peut ne subir aucune reclassification vers la classe W dite « à archiver » tant qu’un opérateur n’a pas réalisé une action spécifique, par exemple une action définie dans une procédure opérationnelle comprise dans la suggestion associée à la notification. Dans cet exemple, la mise en oeuvre de cette action spécifique par l’opérateur induit un horodatage d’action noté T _v(actian Ainsi, si l’unité de classification et de traitement des notifications 164 détecte une durée spécifique définie par T _o = t - T _v(action ^ avec T _o désignant une valeur préfixée par des règles de reclassification des notifications de type complexe. Avantageusement, cela permet à une notification de type complexe d’être automatiquement rejetée par le dispositif de traitement des suggestions 160 au bout d’un certain temps, à partir du moment où un opérateur a réalisé une action spécifique, tel que par exemple T _o = 5 minutes.

[0162] Ainsi, selon des modes de réalisation, la réitération de l’opération de classification peut être déclenchée par un contrôle de la durée en fonction de la métadonnée d’horodatages, par une modification des données acquises pendant une mission, et/ou par un contrôle d’une action détectée sur l’interface Homme- Machine 108.

[0163] Les figures 6, 7 et 8 représentent plusieurs rendus de notifications sur l’interface Homme-Machine 180, à titre d’exemples non limitatifs. Ces exemples de rendu comprennent des formes d’affichage, notamment graphiques et textuelles, sur un écran de l’interface Homme-Machine 180. Ces formes d’affichage et la dynamique d’affichage associée à chaque notification facilitent la compréhension rapide de la teneur d’une notification par les opérateurs de l’aéronef et leurs prises de décision. Ces formes peuvent être mises en oeuvre selon un format graphique condensé (par exemple avec un affichage en bandeau de la notification) ou selon un format graphique étendu (par exemple avec un affichage dans un centre de notifications). Dans un format graphique étendu, ces formes peuvent aussi être mises en oeuvre selon un format textuel court (par exemple avec un affichage de la notification associés à un titre de notification) ou selon un format textuel complet (par exemple avec un affichage d’un texte destiné à être lu et/ou écouté par l’opérateur). [0164] La figure 6 représente plusieurs exemples de rendu de notifications dans une première forme d’affichage dite ‘forme condensée’ en bandeau sur l’interface Homme-Machine 180. Tel qu’utilisé ici, un bandeau fait référence à un rectangle en haut d’un écran de l’interface Homme-Machine 108 contenant un ensemble d’éléments graphiques ou visuels, comme représenté en figure 6 (i), (ii) et (iii).

[0165] Selon certains modes de réalisation, un premier élément contenu dans le bandeau est un moyen (par exemple une icône cliquable noté (a) en figure 6) utilisé pour générer le rendu de notifications selon une autre forme d’affichage, telle qu’une forme d’affichage présenté en figure 7 et dite ‘forme étendue’. Par exemple, dans un affichage selon une forme condensée, la sélection de l’élément graphique (a) peut déclencher l’affichage d’une forme étendue.

[0166] Un second élément contenu dans le bandeau peut être un rectangle apte à être affiché dans la zone correspondant au bandeau et contenant une information (ou action) liée à la suggestion associée à la notification traitée. Cet élément (ou ‘toast en langue anglo-saxonne) est représenté sur la figure 6 (ii), et est noté (b). L’information est affichée selon un format textuel court comme un titre et peut représenter une synthèse de suggestion. De même, le ‘toast peut être utilisé pour générer le rendu de notifications selon la forme étendue. Par exemple, dans un affichage d’une notification selon une forme condensée, la sélection de l’élément graphique (a) peut déclencher l’affichage de la notification selon une forme étendue.

[0167] Un élément contenu dans le bandeau peut correspondre en variante à un chiffre ou un nombre lié à l’énumération des notifications associées à la classe V dite « à exécuter » par l’unité de classification et de traitement des notifications 164. Cet élément peut être défini par une pastille graphique contenant le chiffre ou le nombre, comme représenté en figure 6 (ii) et (iii), et est noté (c).

[0168] D’autres éléments non représentés sur les figures peuvent être contenus dans le bandeau, tels qu’un champ de recherche permettant à un opérateur de l’aéronef d’interagir avec une partie du dispositif d’assistance au pilotage d’un aéronef 100, un logo créé pour identifier le dispositif d’assistance au pilotage d’un aéronef 100, ou encore un moyen (lien cliquable par exemple) permettant à un opérateur de l’équipage d’effectuer une configuration du Flight Policy. [0169] Dans ces exemples, la forme condensée est caractérisée par l’affichage d’une seule notification à la fois et selon un format textuel court. Cette forme condensée fait référence à un affichage sur l’interface Homme-Machine 180. Le dispositif d’assistance au pilotage d’un aéronef 100 étant connecté à divers systèmes constituant le cockpit (via différents composants sur une plateforme de calcul de l’avionique certifiée et de l’avionique non-certifiée), cette forme condensée peut aussi faire référence à d’autre instanciation sur des interfaces Homme-Machine de ces systèmes constituant le cockpit. Par exemple, cette forme condensée peut être exploitée sur un PED (« Personal Electronic Device » signifiant Dispositif Electronique Personnel), ou un système de l’EFB (« Electonic Flight Bag », expression anglo-saxonne signifiant Sacoche de Vol Electronique). L’EFB est un système électronique embarqué dans le cockpit, à l’intention de l’équipage de conduite de l’aéronef, ayant des fonctionnalités se substituant à celles traditionnellement remplies par l’usage de documentation papier telle que les cartes de navigation, le manuel d’exploitation, les calculs de performances. L’EFB peut également disposer de fonctionnalités additionnelles, non remplies par la documentation papier, telles que l’affichage de la position de l’aéronef sur les cartes de navigation. De plus, cette forme condensée peut être affichée sur l’interface Homme-Machine d’un espace de travail connecté à un système non-certifié.

[0170] Selon certains modes de réalisation, pour les notifications de type simple ou complexe, la dynamique d’affichage associée comprend une première génération de rendu des notifications sous forme dite condensée au travers du bandeau sur l’interface Homme-Machine 180. C’est-à-dire, si après une itération de l’étape 440 consistant à appliquer une opération de classification d’une notification de type simple ou complexe (préalablement non classifié ou de classe X ç U), la classe X de la notification satisfait la condition X ç V, alors l’étape 452 de génération de rendu utilise la forme condensé d'affichage. Avantageusement, une telle dynamique d’affichage correspond à des interactions mineures avec les opérateurs de l’équipage et est très peu intrusive dans leurs activités.

[0171] Selon certains modes de réalisation, pour les notifications de type simple ou complexe, la première génération de rendu des notifications sous forme condensée peut comprendre une dynamique d’affichage déterminée en fonction d’un temps prédéterminée et calculé à partir de la métadonnée d’horodatages de la notification, tels que l’horodatage de création, l’horodatage de classification, horodatages de traitement ou encore un des horodatages d’action de la notification.

[0172] Par exemple, il est considéré une notification de type simple ou de type « complexe informative » ayant un horodatage de traitement d’une première génération de rendu de la notification sous forme condensée noté T _{v traitement} L’unité de classification et de traitement des notifications 164, ayant une horloge interne définissant un temps t, peut alors mettre en oeuvre ce rendu des notifications sur le bandeau de l’interface Homme-Machine 180 selon une durée spécifique d’affichage définie par T _o = t - T _{v traitemen} ^, avec T _o désignant une valeur préfixée par des règles prédéfinis. Avantageusement, cela permet à une notification de type simple ou de type « complexe informative » d’être affichée automatiquement sur le bandeau pendant un certain temps seulement, et effacée du bandeau au bout de cette durée spécifique, tel que par exemple T _o = 5 secondes.

[0173] Dans un autre exemple, il est considéré une notification de type « complexe conseil » ayant un horodatage de traitement d’une première génération de rendu de la notification sous forme condensée noté T _{v traitemen} ^ et comprenant une action (définie par exemple dans une procédure opérationnelle comprise dans la suggestion associée à la notification). La mise en oeuvre de cette action spécifique par l’opérateur induit un horodatage d’action noté T _{v action)} . Dans cet exemple, l’unité de classification et de traitement des notifications 164, ayant une horloge interne définissant un temps t, met en oeuvre le rendu des notifications sur le bandeau de l’interface Homme-Machine 180 pendant toute la durée spécifique d’affichage définie par T _o = t - T _{v action)} , avec T _o désignant une valeur préfixée par des règles prédéfinis, indépendamment de l’horodatage T _{v traitement} Avantageusement, cela permet à une notification de type complexe d’être affichée automatiquement sur le bandeau jusqu’à ce qu’un opérateur ait réalisé une action spécifique, puis pendant un certain temps après la réalisation de cette action avec par exemple T _o = 5 secondes. Un exemple d’action spécifique peut être l’actionnement du moyen donné à l’opérateur de l’équipage sur le bandeau pour générer un rendu de notifications différent, comme par exemple sous forme étendue.

[0174] Selon certains modes de réalisation, pour les notifications de type simple ou complexe, le rendu des notifications sous forme condensée peut comprendre une dynamique d’affichage associée à l’affichage à la pastille graphique d’énumération des notifications. En particulier, le nombre ou le chiffre contenu dans la pastille graphique peut correspondre au comptage (ou décompte) et l’incrémentation du nombre de notifications associées à la classe V dite « à exécuter » qui n’ont pas subi de traitement de génération de rendu de notifications selon la forme étendue via un centre de notifications. Ainsi, si le centre de notifications est ouvert, par exemple par l’actionnement du moyen donné à l’opérateur de l’équipage sur le bandeau pour générer un rendu de notifications sous forme dite étendue, alors par définition l’ensemble des notifications apparaissent dans le centre de notification. De ce fait, le nombre ou le chiffre contenu dans la pastille graphique est égale à zéro. Dans le cas où cette valeur est nulle, selon certains modes de réalisation cette pastille graphique peut être supprimée du bandeau sur l’interface Homme-Machine 180, comme représenté en figure 6 (i).

[0175] Dans un autre exemple, il est considéré une notification de type simple comprenant une information élémentaire à transmettre à l’équipage telle qu’une information de mise à jour du statut du plan de vol dans l’espace de travail connecté à un système non-certifié. Les différents statuts de mise à jour du plan de vol peuvent comprendre un statut « brouillon », un statut « rejeté » ou un statut « validé » par exemple. Avantageusement, un opérateur de l’aéronef peut importer un plan de vol dans un système de l’avionique certifié, si le statut du plan de vol dans l’espace de travail est « validé ». De ce fait, le dispositif d’assistance au pilotage d’un aéronef 100 transmet l’information utile à l’opérateur de l’aéronef de mise à jour du plan de vol en un statut « validé ». Pour cela, la notification de type simple peut présenter un dynamique d’affichage comprenant une première génération de rendu des notifications sous forme dite condensée pendant toute la durée spécifique d’affichage définie par la métadonnée d’horodatages de la notification, par exemple une durée T _o = t - 7V(trait _e7 ne t) = 5 secondes. Notamment, l’information élémentaire associée est affichée sur le toast du bandeau sur l’interface Homme-Machine 180, selon le format textuel court suivant "Flight Plan Status : VALIDATED" (expression anglo-saxonne signifiant "statut de plan de vol : validé"), comme représenté sur la figure 6 (ii). Dans ce cas, le chiffre contenu dans la pastille graphique associé à l’énumération de notification est incrémenté de 1 . [0176] La figure 7 représente un exemple de rendu de notifications sous une forme d’affichage dite ‘forme étendue’. Typiquement, la forme étendue en figure 7 est définie selon l’affichage d’un centre de notifications sur l’interface Homme-Machine 108. Tel qu’utilisé ici, un centre de notifications fait référence à une page applicative dans un écran de l’interface Homme-Machine 180 composé par exemple de plusieurs zones contenant divers ensembles d’éléments, comme représenté sur la figure 7.

[0177] Dans des modes de réalisation, une zone composant le centre de notifications peut comprendre une zone de filtrage par catégorie des notifications. Dans ce cadre, la catégorie de la notification peut être une des métadonnées de la notification associées selon des règles prédéfinies à la suggestion par l’unité de génération de notifications 162, parmi les catégories de l’environnement (par exemple météo, état des pistes de l’aéroport, etc.) ou encore de l’état de l’aéronef. Les éléments contenus dans cette zone de priorisation peuvent donc être des moyens (par un ensemble d’icônes cliquables par exemple comme représenté en zone (1 ) de la figure 7) utilisés pour générer le rendu de notifications et permettant de filtrer ou prioriser les notifications en fonction de ces catégories. Avantageusement, l’opérateur peut ainsi choisir la catégorie de notifications à afficher dans le centre de notifications.

[0178] Selon certains modes de réalisation, une zone composant le centre de notifications peut comprendre la liste de notifications associées à la classe V dite « à exécuter » par l’unité de classification et de traitement des notifications 164. Les éléments contenus dans cette zone peuvent être des notifications sous une forme s’apparentant à la forme condensée (appelées alors « boites de notifications en cours » et représentées à titre d’exemple en zone (2) de la figure 7) et donc comprenant l’affichage de la ou les informations (ou de la ou les actions) relative à un ou plusieurs paramètres associés à une mission déterminée à partir de d’une suggestion. L’ordre d’apparition des notifications dans cette liste peut être défini par la métadonnée de priorité, c’est-à-dire en fonction de la priorité de transmission de la suggestion à l’équipage. Enfin, les boites de notifications en cours peuvent contenir une information temporelle (ou durée) déterminée à partir de la métadonnée d’horodatages de la notification, c’est-à-dire à partir de l’horodatage de création, les horodatages de classification, les horodatages de traitement ou encore les horodatages d’action de la notification. [0179] Selon certains modes de réalisation, une zone composant le centre de notifications peut comprendre la liste de notifications associées à la classe W dite « à archiver » par l’unité de classification et de traitement des notifications 164. Les éléments contenus dans cette zone dite ‘zone d’archivage’ peuvent aussi être des notifications sous une forme s’apparentant à la forme condensée (appelées alors « boites de notifications archivées » et représentées à titre d’exemple en zone (3) de la figure 7) et donc comprenant l’affichage de la ou les informations (ou de la ou les actions) relative à un ou plusieurs paramètres associés à une mission déterminée à partir de d’une suggestion. Les boites de notifications archivées peuvent contenir une information temporelle (ou durée) déterminée à partir de la métadonnée d’horodatages de la notification. Un élément additionnel dit ‘élément de déclenchement’ contenu dans la zone d’archivage peut être un moyen (correspondant à un icône cliquable par exemple, comme représenté en zone (3) de la figure 7) utilisé pour générer un rendu de notifications et permettant de cacher la liste de notifications en supprimant l’affichage de ces boites de notifications archivées. Ainsi, la sélection de cet élément de déclenchement peut déclencher l’affichage ou l’occultation de la zone d’archivage. Avantageusement, deux possibilités d’implémentation sont possibles, la zone d’archivage pouvant :

[0180] - être cachée par défaut et être affichée par l’opérateur de l’équipage uniquement quand il en a besoin, ou

[0181 ] - inversement, être affichée par défaut.

[0182] L’affichage de la liste de boites de notifications archivées peut permettre de distinguer les suggestions appliquées par l’équipage, de celles qui n’ont pas été appliquées. L’affichage de la liste de boites de notifications archivées peut également permettre de distinguer les suggestions non appliquées car obsolètes ou non appliquées car explicitement rejetées par un opérateur de l’équipage.

[0183] Selon certains modes de réalisation, une zone composant le centre de notifications peut être un moyen (correspondant par exemple à un icône cliquable, comme représenté dans la zone (4) de la figure 7) utilisé pour désactiver la génération de rendu de notifications. Avantageusement, la sélection de cet élément graphique déclenchant l’interruption de l’étape (452) de génération de rendu et donc permet de désactiver l’affichage des notifications. [0184] Selon certains modes de réalisation, pour les notifications de type « complexe informative » ou « complexe conseil », la dynamique d’affichage associée peut comprendre une première génération de rendu des notifications sous forme dite étendue via l’affichage du centre de notification sur l’interface Homme-Machine 108. C’est-à-dire, si après une itération de l’étape 440 consistant à appliquer une opération de classification d’une notification de type complexe (préalablement non classifié ou de classe X ç U), la classe X de la notification satisfait la condition X ç V, alors l’étape 452 de génération de rendu utilise la forme étendue d'affichage. Une telle dynamique d’affichage correspond à une interaction prégnante avec les opérateurs de l’équipage. Elle s’inscrit dans une situation d’urgence et/ou d’importance haute, impliquant que la suggestion associée à la notification est conseillée d’être prise en compte à ce moment-là.

[0185] Selon certains modes de réalisation, le rendu des notifications sous forme dite étendue, au moyen de l’affichage du centre de notification sur l’interface Homme-Machine 108, pour les notifications de type « complexe informative » ou « complexe conseil », peut prendre en compte la métadonnée de priorité, c’est-à-dire la métadonnée reflétant la priorité de transmission de la suggestion à l’équipage. A titre d’exemple, une notification de priorité élevée peut comporter des caractéristiques d’affichage visuellement accentuées permettant d’attirer plus rapidement l’attention d’un opérateur, tels qu’une couleur d’affichage associée vive (par exemple ambre) et/ou une police de texte plus grande ou en gras. A l’inverse, une notification de priorité modérée comportera les caractéristiques d’affichage nominales du rendu des notifications.

[0186] L’étape 452 de rendu de notification peut ainsi tenir compte du type de la notification, c’est-à-dire des différentes formes et de la dynamique d’affichage. Dans un format graphique étendu, ces formes peuvent aussi être mises en oeuvre selon un format textuel court (par exemple avec un affichage de la notification comprenant un titre de notification composé de quelques mots) ou selon un format textuel complet (par exemple avec un affichage d’un texte). Les boites de notifications (en cours ou archivées) décrites en relation avec la figure 7 représentent un exemple de mise en oeuvre d’un affichage de notification selon une forme étendue courte.

[0187] Afin d’augmenter la compréhensibilité d’une notification par les opérateurs de l’aéronef, un élément additionnel (noté (d) en figure 8) peut être contenu dans les boites de notifications de type complexe par exemple. Tel que représenté en figure 8, cet élément (d) peut-être un moyen (correspondant par exemple à un icône cliquable) utilisé pour générer une alternative du rendu de la notification sous forme étendue dans le centre de notifications sur l’interface Homme-Machine 180. La boite de notification associée est alors représentée sous forme dépliée, ce qui permet d’afficher dans cet exemple un format textuel court (ou titre de la notification, qui est dans l’exemple de la figure 8 « Alerte tempête »), avec un format textuel complet comprenant par exemple des informations complémentaires, des données numériques et éventuellement des éléments graphiques comme l’image (e) de la figure 8.

[0188] Cette forme étendue dite « complète » permet d’apporter à un opérateur de l’équipage des informations supplémentaires dans le cas où la forme étendue dite « courte » de la notification déterminée par l’unité de génération de notifications 162 ne suffit pas à reproduire clairement le contenu de la suggestion calculée par le dispositif de gestion des évènements 140.

[0189] Pour les notifications de type « complexe conseil », la boîte de notification associée, représentée sous forme dépliée, peut contenir en outre un moyen (un bouton tactile sur lequel est inscrit « Afficher plus de détails » par exemple) utilisé pour générer une autre alternative du rendu de la notification sur l’interface Homme- Machine 180. Par exemple, en considérant l’exemple d’une mission en cours subissant une diversion d’un aéronef, un opérateur de l’aéronef peut préférer visualiser une notification sur une autre page applicative (non représentée sur les figures) de l’interface Homme-Machine 180, afin de pouvoir afficher différentes informations et/ou choix d’actions compris dans la suggestion associée. Avantageusement, cela permet de fournir une visualisation comparative et un affichage des critères utilisés pour les calculs des suggestions, ainsi qu’un classement visuel par pertinence de suggestion ou encore l’affichage du détail de certains choix spécifiques de la suggestion à la demande de l’opérateur.

[0190] Selon certains modes de réalisation, pour les notifications de type « complexe conseil », la dynamique d’affichage associée peut comprendre une première génération de rendu des notifications sous forme dite « étendue complète » au moyen de l’affichage de la notification dépliée dans le centre de notification sur l’interface Homme-Machine 108. Avantageusement, cela correspond à une interaction majeure avec les opérateurs de l’équipage dans une situation d’urgence « haute » et d’importante « haute », impliquant que la suggestion associée à la notification est conseillée d’être prise en compte immédiatement. Dans ce cas, la dynamique d’affichage associée comprend une génération de rendu ultérieure sous forme dite « courte » de ces notifications en fonction d’un temps prédéterminé et calculé à partir de la métadonnée d’horodatages de la notification. La génération de rendu ultérieure sous forme dite « courte » peut aussi être mise en oeuvre à la suite d’une action d’un opérateur de l’équipage via le moyen (par un icône cliquable par exemple) donné pour générer l’alternative du rendu de la notification.

[0191] Dans ces exemples, non limitatifs, les différentes formes dites étendues, courtes ou complètes, sont caractérisées par l’affichage de multiples notifications dans le centre de notification faisant référence à l’interface Homme-Machine 108. Cependant, le dispositif d’assistance au pilotage d’un aéronef 100 étant connecté par implémentation à divers systèmes constituant le cockpit (via différents composants sur une plateforme de calcul de l’avionique certifiée et de l’avionique non-certifiée), ces formes étendues peuvent aussi faire référence à d’autres instanciations sur des interfaces Homme-Machine de ces systèmes constituant le cockpit. Par exemple, une forme étendue complète peut être affichée sur l’interface Homme-Machine d’un espace de travail connecté à un système non-certifié. Avantageusement, cela permet aux opérateurs de l’équipage d’effectuer des choix qualifiés plus conscients par rapport aux suggestions calculées par le dispositif de gestion des évènements 140 dans un espace de travail habituel.

[0192] En considérant l’exemple d’une mission en cours subissant une diversion d’un aéronef, un opérateur de l’aéronef peut préférer visualiser la notification sur une page spécifique de l’espace de travail d’un système non-certifié, afin de pouvoir superposer la synthèse de la situation délivrée par l’espace de travail et les différentes suggestions calculées par le dispositif de gestion des évènements 140. Avantageusement, cela permet de fournir une visualisation comparative, par exemple sur une carte, un affichage des critères utilisés pour les calculs des suggestions, ainsi qu’un classement visuel par pertinence de suggestion ou encore l’affichage du détail de certaines suggestions spécifiques à la demande de l’opérateur. Ainsi, selon certains modes de réalisation, pour les notifications de type « complexe conseil », la dynamique d’affichage associée peut comprendre en outre une génération de rendu des notifications sur l’interface Homme-Machine d’un espace de travail connecté à un système non-certifié via le moyen par un bouton tactile sur lequel est inscrit « Afficher plus de détails » par exemple.

[0193] L’homme du métier comprendra que le dispositif de traitement de notification ou des sous-systèmes du dispositif selon les modes de réalisation de l’invention peuvent être mis en oeuvre de diverses manières par matériel (« hardware »), logiciel, ou une combinaison de matériel et de logiciels, notamment sous la forme de code de programme pouvant être distribué sous la forme d'un produit de programme, sous diverses formes. En particulier, le code de programme peut être distribué à l'aide de supports lisibles par ordinateur, qui peuvent inclure des supports de stockage lisibles par ordinateur et des supports de communication. Les procédés décrits dans la présente description peuvent être notamment implémentés sous la forme d’instructions de programme d’ordinateur exécutables par un ou plusieurs processeurs dans un dispositif informatique d'ordinateur. Ces instructions de programme d’ordinateur peuvent également être stockées dans un support lisible par ordinateur.

[0194] Par ailleurs, l'invention n'est pas limitée aux modes de réalisation décrits ci- avant à titre d’exemple non limitatif. Elle englobe toutes les variantes de réalisation qui pourront être envisagées par l'homme du métier. En particulier, l’invention n’est pas limitée aux exemples de donnés dans la description à titre d’exemple non limitatif.