Brevet FR2950184A1 — publié le 20110318

La présente invention concerne la gestion des alarmes dans les aéronefs et plus particulièrement un procédé et un dispositif de gestion centralisée des alertes dans un aéronef comprenant plusieurs interfaces de présentation d'alertes. Les aéronefs sont généralement équipés de systèmes d'alarmes appelé FWS (sigle de Flight Warning System en terminologie anglo-saxonne) capable de détecter des pannes ou des configurations anormales afin de prévenir l'équipage grâce à la génération d'alertes visuelles et/ou sonores et à l'affichage des procédures à effectuer et de l'état de l'aéronef (liste des systèmes inopérants, des limitations de performances, etc.). Les alarmes relatives à des configurations anormales ou à des pannes des systèmes d'un aéronef sont ainsi gérées de manière centralisée par le système d'alarme de l'aéronef. Ce système est garant d'une présentation opportune des messages d'alertes et des procédures associées aux membres d'équipage dans le cockpit via une gestion fine des priorités et en fonction de la phase de vol et via une interface home-machine (IHM) dédiée. Sur certains aéronefs, notamment certains aéronefs militaires, des membres d'équipage spécifiques sont chargés des opérations liées à la gestion du cargo (chargement et déchargement au sol de matériel, largage en vol de personnel parachuté ou de matériel, mission d'évacuation médicale d'urgence et similaire). Ces membres d'équipage, aussi appelés loadmasters en terminologie anglo-saxonne, sont localisés dans la zone cargo de l'aéronef et disposent d'équipements et d'interfaces spécifiques permettant la gestion du cargo. En particulier, par analogie avec les opérations de pilotage incombant aux membres d'équipage présents dans le cockpit, les membres d'équipage opérant dans la zone cargo de l'aéronef peuvent être alertés de défaillances affectant un système ayant un impact sur les opérations de gestion du cargo. La figure 1 illustre schématiquement un dispositif d'alarme permettant de gérer des alertes liées aux opérations de pilotage et de cargo. Le dispositif illustré comprend un premier système 100-1 de gestion d'alarmes comportant une interface de présentation d'alertes liées aux opérations de pilotage et un second système 100-2 de gestion d'alarmes comportant une interface de présentation d'alertes liées aux opérations de cargo d'un aéronef. Plus précisément, le premier système 100-1 comprend un ou plusieurs calculateurs 105-1 pour calculer et confirmer des alertes à partir d'informations issues de systèmes 110-1 à 110-m de l'aéronef. Les alertes calculées et confirmées peuvent être affichées sur un ou plusieurs écrans 115-1 et/ou présentées de façon sonore via un ou plusieurs haut-parleurs 120-1 pour être indiquées aux membres d'équipage du cockpit. De façon similaire, le second système 100-2 comprend un ou plusieurs calculateurs 105-2 pour calculer et confirmer des alertes à partir d'informations issues de systèmes 125-1 à 125-n de l'aéronef. Les alertes calculées et confirmées peuvent être affichées sur un ou plusieurs écrans 115-2 et/ou présentées de façon sonore via un ou plusieurs haut-parleurs 120-2 pour être indiquées aux loadmasters. Cependant, certaines pannes pouvant avoir des impacts tant sur les opérations cockpit que sur les opérations cargo, il apparaît un besoin de synchronisation des tâches et de la communication entre membres d'équipage cockpit et cargo. En particulier pour des pannes communes, c'est-à-dire des pannes ayant des impacts sur les opérations cockpit et cargo, il est nécessaire d'assurer une simultanéité de mise en alerte des membres d'équipage dans les deux zones de l'aéronef. Il est observé ici qu'en cas de défaut de synchronisation sur la mise en alerte des membres d'équipage, des risques de perturbation des pilotes par des interventions du loadmaster, qui serait par exemple seul à être alerté par une panne sur son interface propre, pourraient générer une surcharge de travail inacceptable côté cockpit dans certaines phases de vol critiques (par exemple au décollage ou à l'atterrissage). Les architectures proposées sur certains aéronefs militaires ne permettent pas de répondre à ce besoin. En effet, pour certaines pannes communes, c'est-à-dire des pannes ayant une incidence sur les opérations cockpit et cargo, chaque interface repose sur sa propre chaîne de détection de pannes et sur des logiques de détection et de présentation des alarmes développées indépendamment et à des niveaux de complexité très différents. Il en découle directement des risques d'incohérences sur la présentation des messages d'alerte présentés sur chaque interface. Par ailleurs, il est difficile de garantir que les libellés d'alarmes affichés sur l'interface cockpit et sur l'interface cargo soient cohérents, ce qui peut représenter un risque de mauvaise compréhension des équipages. L'invention permet de résoudre au moins un des problèmes exposés précédemment. L'invention a ainsi pour objet un procédé de gestion centralisée d'alertes dans un aéronef comprenant un système centralisé de gestion d'alertes et une pluralité d'interfaces de présentation d'alertes, chacune desdites interfaces étant adaptée à présenter au moins une alerte à un utilisateur, ce procédé comprenant les étapes suivantes, - détermination d'au moins une alerte dans ledit système centralisé de gestion d'alertes selon au moins un signal reçu d'activation d'alarme ; - présentation de ladite au moins une alerte par une première interface de ladite pluralité d'interfaces ; - filtrage de ladite au moins une alerte déterminée ; et, - en réponse à ladite étape de filtrage, présentation ou non de ladite au moins une alerte déterminée par une seconde interface de ladite pluralité d'interface, ladite seconde interface étant distincte de la première interface. Le procédé selon l'invention permet ainsi d'assurer une mise en alerte synchronisée des membres d'équipage opérant dans différentes parties d'un aéronef, par exemple dans le cockpit d'une part et dans la zone cargo d'autre part, en cas de panne ou de configuration anormale de l'aéronef ayant une incidence sur les tâches de chaque membre d'équipage. Le procédé selon l'invention permet ainsi de faire profiter à l'ensemble des membres d'équipage de la même logique de présentation optimisée des alarmes en fonction, par exemple, de la priorité et de la phase de vol. Le procédé selon l'invention permet également de favoriser une coordination et une efficacité optimales des tâches des membres d'équipage au niveau de l'aéronef. En outre, le procédé selon l'invention permet d'éviter les risques de perturbation des pilotes par d'autres membres d'équipage dans certaines phases de vol critiques. Selon un mode de réalisation particulier, ladite étape de présentation de ladite au moins une alerte déterminée par ladite première interface comprend une étape de filtrage pour déterminer si ladite au moins une alerte déterminée doit ou non être présentée par ladite première interface. Ainsi, selon ce mode de réalisation, toutes les alertes peuvent être gérées par un seul système, les alertes étant filtrées par chaque interface. Selon un autre mode de réalisation particulier, le procédé comprend en outre une étape de transmission de ladite au moins une alerte déterminée à un système d'alertes périphérique associé à ladite seconde interface, ladite étape de filtrage de ladite au moins une alerte déterminée étant mise en oeuvre dans ledit système d'alertes périphérique. De façon avantageuse, le procédé comprend en outre une étape de détermination d'au moins une alerte dans ledit système d'alertes périphérique. Ainsi, selon ce mode de réalisation, les alertes pouvant intéresser plusieurs interfaces différentes peuvent être gérées de façon centralisée tandis que les alertes ne visant qu'une interface particulière sont gérées de façon locale. L'invention a également pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé décrit précédemment lorsque ledit programme est exécuté sur un calculateur. Les avantages procurés par ce programme d'ordinateur sont similaires à ceux évoqués précédemment. L'invention a aussi pour objet un dispositif de gestion d'alertes dans un aéronef, ce dispositif comprenant les moyens suivants, - moyens centralisés de gestion d'alertes pour déterminer au moins une alerte selon au moins un signal d'activation d'alarme ; - premiers moyens de présentation d'alertes pour présenter au moins une alerte déterminée par lesdits moyens centralisés de gestion d'alertes ; - moyens de filtrage pour filtrer au moins une alerte déterminée par lesdits moyens centralisés de gestion d'alertes ; et, - seconds moyens de présentation d'alertes pour présenter au moins une alerte déterminée par lesdits moyens centralisés de gestion d'alertes et filtrée par lesdits moyens de filtrage. Le dispositif selon l'invention permet ainsi d'assurer une mise en alerte synchronisée des membres d'équipage opérant dans différentes parties d'un aéronef, par exemple dans le cockpit d'une part et dans la zone cargo d'autre part, en cas de panne ou de configuration anormale de l'aéronef ayant une incidence sur les tâches de chaque membre d'équipage. Le dispositif selon l'invention permet ainsi de faire profiter à l'ensemble des membres d'équipage de la même logique de présentation optimisée des alarmes en fonction, par exemple, de la priorité et de la phase de vol. Le dispositif selon l'invention permet également de favoriser une coordination et une efficacité optimales des tâches des membres d'équipage au niveau de l'aéronef. En outre, le dispositif selon l'invention permet d'éviter les risques de perturbation des pilotes par d'autres membres d'équipage dans certaines phases de vol critiques. Selon un mode de réalisation particulier, lesdits moyens de filtrage appartiennent auxdits moyens centralisés de gestion d'alertes, lesdits premier moyens de présentation d'alertes présentant au moins une alerte déterminée par lesdits moyens centralisés de gestion d'alertes et filtrée par lesdits moyens de filtrage. Ainsi, selon ce mode de réalisation, toutes les alertes peuvent être gérées par un seul système, les alertes étant filtrées par chaque interface. Selon un autre mode de réalisation particulier, le dispositif comprend en outre des moyens d'alertes périphériques associés auxdits seconds moyens de présentation d'alerte, lesdits moyens d'alertes périphériques comprenant lesdits moyens de filtrage. Ainsi, selon ce mode de réalisation, les alertes pouvant intéresser plusieurs interfaces différentes peuvent être gérées de façon centralisée tandis que les alertes ne visant qu'une interface particulière sont gérées de façon locale. Toujours selon un mode de réalisation particulier, lesdits moyens d'alertes périphériques comprennent des moyens de passerelle pour transmettre au moins un signal d'activation d'alarme reçu par lesdits moyens d'alertes périphériques auxdits moyens centralisés de gestion d'alertes. Ces moyens de passerelle permettent notamment de simplifier la connexion entre différents éléments de l'aéronef. L'invention a également pour objet un aéronef comprenant le dispositif décrit précédemment. D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, au regard des dessins annexés dans lesquels : - la figure 1 illustre schématiquement un dispositif standard d'alarme permettant de gérer des alertes liées aux opérations de pilotage et de cargo ; - la figure 2 illustre un premier mode de réalisation d'un dispositif de gestion centralisée d'alertes dans un aéronef permettant la synchronisation de plusieurs interfaces de présentation d'alertes conformément à l'invention ; - la figure 3 illustre schématiquement un exemple d'algorithme pour gérer des alertes conformément à l'architecture présentée sur la figure 2 ; - la figure 4 illustre un second mode de réalisation d'un dispositif de gestion centralisée d'alertes dans un aéronef permettant la synchronisation de plusieurs interfaces de présentation d'alertes conformément à l'invention ; - la figure 5 illustre schématiquement un exemple d'algorithme pour gérer des alertes conformément à l'architecture présentée sur la figure 4 ; - la figure 6, comprenant les figures 6a, 6b et 6c, représente des exemple d'architecture de messages pouvant être transmis par un système centralisé de gestion d'alarmes à un ou plusieurs systèmes d'alarme périphériques ; et, - la figure 7 illustre un exemple d'architecture matérielle adaptée à mettre en oeuvre l'invention, en particulier le système centralisé de gestion des alertes et les systèmes d'alarme périphériques. De façon générale, l'invention a pour objet une architecture permettant de centraliser les traitements relatifs aux alarmes communes aux opérations de plusieurs membres d'équipage non impliqués dans les mêmes opérations et pouvant être situés en différents emplacements de l'aéronef. Le traitement centralisé des alarmes communes est réalisé dans un seul système qui met à disposition d'autres systèmes d'alarme gérant leurs propres interfaces le résultat de ses calculs d'alarmes. Une telle architecture permet d'uniformiser la nature des messages affichés sur chaque interface de l'aéronef, de façon synchronisée, afin de permettre une communication et une synchronisation optimales entre tous les membres d'équipage au niveau de l'aéronef (même niveau d'information et même instant de mise en alerte). Il est rappelé ici que le FWS est connecté à un très grand nombre de systèmes de l'aéronef. Par conséquent, il est en mesure de faire remonter un grand nombre de messages relatifs à des pannes. En outre, disposant de nombreuses informations en entrée, il est en mesure d'indiquer précisément les conséquences d'une panne d'un système. A titre d'illustration, les alertes calculées et présentées aux pilotes par le FWS peuvent reposer sur des logiques d'activation et d'inhibition très élaborées fonction de la phase de vol et de l'état de certaines ressources (électriques, hydrauliques et réseau de communication) pour ne présenter au moment le plus opportun que les messages d'alerte correspondant à de véritables pannes et pour filtrer les alarmes intempestives. Ces logiques d'alarmes sont également souvent le résultat de traitements complexes appliqués sur les entrées tels que des résultats de votes et d'une logique de sélection de source, la mémorisation de panne et des délais de confirmation. Ainsi, le FWS est, de préférence, utilisé comme système de traitement centralisé des alertes. Selon un premier mode de réalisation, le système FWS gère la détection de l'ensemble des alarmes requises au niveau aéronef, c'est-à-dire, par exemple, les alarmes liées aux opérations de cockpit et de cargo ainsi que l'affichage des alertes sur les interfaces correspondantes. La figure 2 illustre ce premier mode de réalisation. L'architecture 200 comprend ici un système centralisé de gestion d'alertes 205, par exemple un FWS, auquel sont reliés les systèmes 210-1 à 210-n à partir desquels sont reçues les informations utilisées pour identifier les alarmes. Les alertes calculées et, de préférence, confirmées, sont transmises à un module de filtrage 215 auquel sont reliées les interfaces 220 et 225 adaptées à afficher les alertes et/ou à les indiquer de façon sonore. L'interface 220 représente ici l'interface cockpit tandis que l'interface 225 représente l'interface cargo. Il doit être observé ici que le module de filtrage 215 peut être intégré au système centralisé de gestion d'alertes 205. Le module de filtrage 215 a pour objet de filtrer les alertes reçues du système centralisé de gestion d'alertes 205, par exemple sous forme de messages. Ces messages peuvent notamment être filtrés selon leur identifiant et un ensemble de règles prédéterminées mémorisées dans une base de données 230. Ainsi, les alertes uniquement destinées au cockpit sont transmises à l'interface 220, les alertes uniquement destinées au cargo sont transmises à l'interface 225 et les alertes destinées au cockpit et au cargo sont transmises aux interfaces 220 et 225. Bien que seulement deux interfaces 220 et 225 soient représentées sur la figure 2, il doit être compris que le module de filtrage peut être relié à un nombre plus important d'interfaces. La figure 3 illustre schématiquement un exemple d'algorithme pour gérer des alertes conformément à l'architecture présentée sur la figure 2. Une première étape (étape 300) a pour objet de recevoir des signaux d'activation d'alarmes des systèmes 210-1 à 210-n, génériquement référencés 210. Ces signaux sont traités (étape 305) par le système centralisé de gestion d'alertes pour calculer et déterminer, le cas échéant, des alertes. Si aucune alerte n'est déterminée (étape 310), les étapes précédentes (étapes 300 et 305) sont répétées pour traiter les signaux d'activation d'alarmes reçus. Si au moins une alerte est déterminée (étape 310), les alertes déterminées sont filtrées (étape 315), par exemple selon des règles prédéterminées mémorisées dans la base de données 230, pour identifier à partir de quelles interfaces elles doivent être présentées aux membres d'équipage (étape 320). Comme décrit précédemment, cette étape permet notamment de sélectionner l'interface cockpit et/ou l'interface cargo selon la nature des alertes. Les étapes précédentes (étapes 300 à 320) sont alors répétées pour traiter les signaux d'activation d'alarmes reçus. Les étapes 300, 305 et 310 sont ici mises en oeuvre dans le système centralisé de gestion des alertes 205, l'étape 315 est mise en oeuvre dans le module de filtrage 215 (pouvant appartenir au système centralisé de gestion des alertes 205) et l'étape 320 est mise en oeuvre dans les interfaces 220 et 225. Selon un second mode de réalisation, le système centralisé de gestion d'alertes, par exemple le FWS, ne gère que la détection des alarmes liées aux opérations cockpit. Le système centralisé de gestion d'alertes met en outre à disposition d'autres systèmes, appelés systèmes d'alertes périphériques, gérant leurs propres interfaces, le résultat de ses calculs d'alertes en prenant notamment en compte, de préférence, un filtrage selon la phase de vol, des inhibitions inter-alarmes, la gestion de priorité et des commandes de l'équipage cockpit. Les systèmes d'alertes périphériques assurent eux-mêmes, parmi les messages reçus du FWS, la sélection des messages d'alertes cockpit ayant un intérêt à être présentés sur l'interface associée au système d'alerte périphérique concerné. De façon avantageuse, la transmission des messages entre le système centralisé de gestion d'alertes et les systèmes d'alertes périphériques utilise un protocole mis en oeuvre dans l'aéronef, par exemple le protocole utilisé entre le FWS et un système de maintenance. Les informations transmises par le système centralisé de gestion d'alertes à ces systèmes d'alertes périphériques peuvent être transmises à l'aide d'un protocole adapté pour indiquer par exemple l'état d'activation, d'affichage et de désactivation de chaque alarme mais également toute information complémentaire pouvant présenter un intérêt telle que le libellé du titre ou du message de panne, le type et le niveau de l'alarme. Selon ce mode de réalisation, chaque système d'alertes périphérique a par ailleurs en charge la détection et l'affichage de leurs alertes spécifiques, c'est-à-dire les alarmes ne concernant pas les opérations cockpit (les alarmes ayant un intérêt pour les membres d'équipage cockpit étant ici gérées par le système centralisé de gestion d'alertes). La figure 4 illustre ce second mode de réalisation. L'architecture 400 comprend ici un système centralisé de gestion d'alertes 405, par exemple un FWS, auquel sont reliés certains des systèmes 410-1 à 410-n à partir desquels sont reçues les informations utilisées pour identifier les alarmes. Selon la figure 4, les systèmes 410-1, 410-2 et 410-n sont reliés au système centralisé de gestion d'alertes 405. Les alertes calculées et, de préférence, confirmées par le système centralisé de gestion d'alertes 405, sont transmises à l'interface 220' ici similaire à l'interface 220 décrite en référence à la figure 2. Ces alertes sont ainsi celles liées aux opérations cockpit. En outre, ces alertes sont transmises au système d'alertes périphérique 415 auquel est reliée l'interface 225', ici similaire à l'interface 225 décrite en référence à la figure 2. Le système d'alertes périphérique 415 comprend un module de filtrage permettant de filtrer les messages reçus du système centralisé de gestion d'alertes 405 de telle sorte que seules les alertes reçues pertinentes pour l'interface 225' lui soient transmises. Le module de filtrage utilise par exemple des règles prédéterminées mémorisées dans une base de données (non représentée). Le système d'alertes périphérique 415 comprend également un module de gestion d'alertes auquel sont reliés certains des systèmes 410-1 à 410-n à partir desquels sont reçues les informations utilisées pour identifier les alarmes. Selon la figure 4, les systèmes 410-2, 410-3 et 410-n sont reliés au système d'alertes périphérique 415. Les alertes calculées et, de préférence, confirmées par le système d'alertes périphérique 415, sont transmises à l'interface 225' De façon avantageuse, le système d'alertes périphérique comprend en outre un module de passerelle 420 permettant de transmettre des informations reçues de certains des systèmes 410-1 à 410-n lorsque ces systèmes sont reliés au système d'alertes périphérique 415 mais pas au système centralisé de gestion d'alertes 405. Ainsi, à titre d'illustration, le système centralisé de gestion d'alertes 405 peut utiliser des informations reçues du système 410-3 via le système d'alertes périphérique 415 pour gérer des alertes liées aux opérations cockpit. Ainsi, des signaux d'activation d'alarmes sont transmis directement des systèmes 410-1, 410-2 et 410-n vers le système centralisé de gestion d'alertes 405. En outre, des signaux d'activation d'alarmes sont transmis du système 410-3 vers le système centralisé de gestion d'alertes 405 via le système d'alertes périphérique 415. Ces signaux d'activation permettent ainsi de détecter des pannes liées à ces systèmes et à des opérations cockpit. De façon similaire, des signaux d'activation d'alarmes sont transmis directement des systèmes 410-2, 410-3 et 410-n vers le système d'alertes périphérique 415. Ces signaux d'activation permettent ainsi de détecter des pannes liées à ces systèmes et à des opérations cargo, n'affectant pas les opérations cockpit. Ainsi, le système centralisé de gestion d'alertes 405 gère la détection de pannes pour permettre d'avertir les membres d'équipage cockpit via l'interface spécifique 220', par exemple sous forme de messages. Le système d'alertes périphérique 415 gère directement la détection de ses alarmes spécifiques et leur indication à l'aide de l'interface 225' associée. Le système d'alertes périphérique 415 indique en outre, à l'aide de l'interface 225' associée, des alertes communes avec le cockpit, dont les caractéristiques sont reçues du système centralisé de gestion d'alertes 405, présentant un intérêt pour les utilisateurs de l'interface 225'. Il est observé ici que bien qu'un seul système d'alertes périphérique 415 et une interface 225' associée soient représentés sur la figure 4, plusieurs systèmes d'alertes périphériques et interfaces associées peuvent être mis en oeuvre de façon similaire. La figure 5 illustre schématiquement un exemple d'algorithme pour gérer des alertes conformément à l'architecture présentée sur la figure 4. Comme représenté, l'algorithme comprend ici plusieurs parties, la partie 500 étant mise en oeuvre dans le système centralisé de gestion d'alertes 405 ainsi que l'interface associée 220' et la partie 505 étant mise en oeuvre dans chaque système d'alertes périphérique ainsi que dans l'interface associée, c'est-à-dire ici dans le système d'alertes périphérique 415 et l'interface 225'. Une première étape (étape 510) de la partie 500 a pour objet de recevoir des signaux d'activation d'alarmes de certains des systèmes 410-1 à 410-n, génériquement référencés 410. Ces signaux sont traités (étape 515) par le système centralisé de gestion d'alertes 405 pour calculer et déterminer, le cas échéant, des alertes. Si aucune alerte n'est déterminée (étape 520), les étapes précédentes (étapes 510 et 515) sont répétées pour traiter les signaux d'activation d'alarmes reçus. Si au moins une alerte est déterminée (étape 520), les alertes déterminées sont présentées aux membres d'équipage cockpit à l'aide de l'interface 220' (étape 525). Simultanément, ou de façon séquentielle, les alertes déterminées sont transmises, notamment, aux systèmes d'alertes périphériques, notamment au système d'alertes périphérique 415 (étape 530). Les étapes précédentes (étapes 510 à 530) sont alors répétées pour traiter les signaux d'activation d'alarmes reçus. Parallèlement, une étape (étape 535) de la partie 505 a pour objet de recevoir les alertes déterminées par le système centralisé de gestion des alertes. Les alertes reçues du système centralisée de gestion des alertes sont alors filtrées (étape 540) pour ne sélectionner que les alertes pertinentes présentant un intérêt pour le système d'alertes périphérique considéré, ici le système d'alertes périphérique lié aux opérations cargo. Simultanément, des signaux d'activation d'alarmes sont reçus (étape 545) de certains des systèmes 410-1 à 410-n, génériquement référencés 410. Ces signaux sont traités (étape 550) par le système d'alertes périphérique 415 pour calculer et déterminer, le cas échéant, des alertes. Si aucune alerte pertinente n'est reçue du système centralisé de gestion des alertes ou déterminée par le système d'alertes périphérique (étape 555), les étapes précédentes (étapes 535 à 550) sont répétées pour traiter les signaux d'activation d'alarmes reçus et, le cas échéant, les alertes déterminées dans le système centralisé de gestion des alertes. Si au moins une alerte est déterminée (étape 555), les alertes déterminées sont présentées aux membres d'équipage cargo à l'aide de l'interface 225' (étape 560). Les étapes précédentes (étapes 535 à 560) sont alors répétées pour traiter les signaux d'activation d'alarmes reçus et, le cas échéant, les alertes déterminées dans le système centralisé de gestion des alertes. Selon une mise en oeuvre particulière, le média et le protocole d'échange d'informations relatives aux alarmes communes entre les systèmes d'alertes centralisé et périphériques sont ceux utilisés pour transmettre les alertes du système centralisé de gestion d'alertes au système de maintenance aussi appelé CMS (sigle de Centralized Maintenance System en terminologie anglo-saxonne). Ce média et ce protocole d'échange d'informations sont par exemple ceux mis en oeuvre dans l'avion A380 (A380 est une marque) où le CMS utilise les informations relatives à l'activation des alarmes pour composer automatiquement le PFR (sigle de Post-Flight Report en terminologie anglo-saxonne) qui liste l'ensemble des occurrences de panne observées sur un vol. Selon ce mode de réalisation particulier, ces messages protocolaires sont utilisés comme support à la synchronisation de plusieurs interfaces localisées à différents emplacements de l'aéronef. A titre d'illustration, trois types de messages pouvant être transmis de manière asynchrone par le système centralisé de gestion d'alertes aux systèmes d'alertes périphériques, selon un mode de réception par file d'attente, sont ici considérés. Le premier type de messages vise les alertes calculées et confirmées, le second les alertes affichées et le troisième les alertes désactivées. Lorsqu'une alerte est calculée et confirmée, un message du premier type est transmis. Lors de l'affichage de cette alerte, un message du second type est transmis. Enfin, lorsque cette alerte est désactivée par un membre d'équipage, un message de troisième type est transmis. Chaque message peut concerner plusieurs alertes. Les messages du premier type comprennent, pour chaque alerte calculée et confirmée, le code d'identification de l'alarme (aussi appelée FDCE, sigle de Flight Deck and Cargo Effects en terminologie anglo-saxonne), le type de l'alerte, le niveau de l'alerte et le titre de l'alerte ou libellé du message. La constitution de ces messages respecte les règles suivantes : - le premier octet du message donne la taille totale, en nombre d'octets, occupée par les informations de la première alerte (somme de la taille en octets du code d'identification, de la taille en octets du type, de la taille en octets du niveau et de la taille en octets du titre ou du libellé du message) ; - les octets suivants donnent successivement le code d'identification, le type, le niveau puis le titre ou libellé du message de la première alerte ; - la taille, le code d'identification, le type, le niveau puis le titre ou libellé du message de chacune des alertes suivantes sont décrits successivement dans le message ; - la taille totale du message ne doit pas dépasser 8192 octets, un 30 second message étant constitué dans le cas où la taille maximale autorisée est dépassée ; et, - les informations concernant une alerte ne peuvent pas être réparties dans deux messages différents. Les messages du second type comprennent, pour chaque alerte calculée et confirmée, le code d'identification de l'alarme et le niveau de l'alerte. La constitution de ces messages respecte les règles suivantes : - le premier message comprend le niveau suivi du code d'identification de la première alerte ; - le niveau puis le code d'identification de chacune des alertes suivantes sont décrits successivement dans le message ; - la taille totale du message ne doit pas dépasser 8192 octets, un second message étant constitué dans le cas où la taille maximale autorisée est dépassée ; et, - les informations concernant une alerte ne peuvent pas être réparties dans deux messages différents. Les messages du troisième type comprennent, pour chaque alerte calculée et confirmée, le code d'identification de l'alarme. La constitution de ces messages respecte les règles suivantes : - le premier message comprend le code d'identification de la première alerte ; - les codes d'identification de chacune des alertes suivantes sont décrits successivement dans le message ; - la taille totale du message ne doit pas dépasser 8192 octets, un second message étant constitué dans le cas où la taille maximale autorisée est dépassée ; et, - les informations concernant une alerte ne peuvent pas être réparties dans deux messages différents. La figure 6, comprenant les figures 6a, 6b et 6c, illustre un exemple de structure de messages conformément aux premier, second et troisième types, respectivement. Ainsi, lorsque des messages de premier, second ou troisième type sont générés par le système centralisé de gestion des alertes, ils sont transmis pour être utilisés par le CMS ainsi que par les systèmes d'alertes périphériques conformément à l'invention. La figure 7 illustre un exemple d'architecture matérielle adaptée à mettre en oeuvre l'invention, en particulier le système centralisé de gestion des alertes et les systèmes d'alertes périphériques décrits en référence aux figures 2 et 4. Le dispositif 700, de type calculateur ou ordinateur, comporte ici un bus de communication 705 auquel sont reliés : - une unité centrale de traitement ou microprocesseur 710 (CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ; - une mémoire morte 715 (ROM, acronyme de Read Only Memory en terminologie anglo-saxonne) pouvant comporter les programmes nécessaires à la mise en oeuvre de l'invention ; - une mémoire vive ou mémoire cache 720 (RAM, acronyme de Random Access Memory en terminologie anglo-saxonne) comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution des programmes précités ; et - une interface de communication 750 adaptée à transmettre et à recevoir des données, notamment vers et depuis les dispositifs commandés de l'aéronef pour les contrôler et connaître leur état. Le dispositif 700 dispose également, de préférence, des éléments suivants : - un écran 725, utilisé comme interface avec un membre de l'équipage, permettant de visualiser des données telles que des informations liées à l'état de l'aéronef et pouvant servir d'interface graphique avec l'utilisateur qui pourra interagir avec les programmes, à l'aide d'un clavier et d'une souris 730 ou d'un autre dispositif de pointage tel qu'un écran tactile ou une télécommande ; - d'un disque dur 735 pouvant comporter les programmes précités et des données traitées ou à traiter selon l'invention ; et - d'un lecteur de cartes mémoires 740 adapté à recevoir une carte mémoire 745 et à y lire ou à y écrire des données traitées ou à traiter selon l'invention. Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le dispositif 700 ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément du dispositif 700 directement ou par l'intermédiaire d'un autre élément du dispositif 700. Le code exécutable de chaque programme permettant au dispositif programmable de mettre en oeuvre les processus selon l'invention, peut être stocké, par exemple, dans le disque dur 735 ou en mémoire morte 715. Selon une variante, la carte mémoire 745 peut contenir des données, notamment une table de correspondance entre les événements détectés et les commandes pouvant être sollicitées, ainsi que le code exécutable des programmes précités qui, une fois lu par le dispositif 700, est stocké dans le disque dur 735. Selon une autre variante, le code exécutable des programmes pourra être reçu, au moins partiellement, par l'intermédiaire de l'interface de communication 750, pour être stocké de façon identique à celle décrite précédemment. De manière plus générale, le ou les programmes pourront être 20 chargés dans un des moyens de stockage du dispositif 700 avant d'être exécutés. L'unité centrale 710 va commander et diriger l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur 735 ou dans la 25 mémoire morte 715 ou bien dans les autres éléments de stockage précités. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 735 ou la mémoire morte 715, sont transférés dans la mémoire vive 720 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour 30 mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention. Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente. REVENDICATIONS1. Procédé de gestion centralisée d'alertes dans un aéronef comprenant un système centralisé de gestion d'alertes (205, 405) et une pluralité d'interfaces de présentation d'alertes (220, 225, 220', 225'), chacune desdites interfaces étant adaptée à présenter au moins une alerte à un utilisateur, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes, - détermination (305, 515) d'au moins une alerte dans ledit système centralisé de gestion d'alertes selon au moins un signal reçu d'activation d'alarme ; - présentation (320, 525) de ladite au moins une alerte par une première interface (220, 220') de ladite pluralité d'interfaces ; - filtrage (315, 540) de ladite au moins une alerte déterminée ; et, - en réponse à ladite étape de filtrage, présentation (320, 560) ou non de ladite au moins une alerte déterminée par une seconde interface (225, 225') de ladite pluralité d'interface, ladite seconde interface étant distincte de la première interface. 2. Procédé selon la revendication précédente selon lequel ladite étape de présentation de ladite au moins une alerte déterminée par ladite première interface comprend une étape de filtrage (315) pour déterminer si ladite au moins une alerte déterminée doit ou non être présentée par ladite première interface. 3. Procédé selon la revendication 1 comprenant en outre une étape de transmission (530) de ladite au moins une alerte déterminée à un système d'alertes périphérique (415) associé à ladite seconde interface, ladite étape de filtrage de ladite au moins une alerte déterminée étant mise en oeuvre dans ledit système d'alertes périphérique. 4. Procédé selon la revendication 3 comprenant en outre une étape de détermination (550) d'au moins une alerte dans ledit système d'alertes périphérique. 5. Programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications précédente lorsque ledit programme est exécuté sur un calculateur. 6. Dispositif de gestion d'alertes dans un aéronef, ce dispositif étant caractérisé en ce qu'il comprend les moyens suivants, - moyens centralisés de gestion d'alertes (205, 405) pour déterminer au moins une alerte selon au moins un signal d'activation d'alarme ; - premiers moyens de présentation d'alertes (220, 220') pour présenter au moins une alerte déterminée par lesdits moyens centralisés de gestion d'alertes ; - moyens de filtrage (215, 415) pour filtrer au moins une alerte déterminée par lesdits moyens centralisés de gestion d'alertes ; et, - seconds moyens de présentation d'alertes (225, 225') pour présenter au moins une alerte déterminée par lesdits moyens centralisés de gestion d'alertes et filtrée par lesdits moyens de filtrage. 7. Dispositif selon la revendication précédente selon lequel lesdits moyens de filtrage appartiennent auxdits moyens centralisés de gestion d'alertes, lesdits premier moyens de présentation d'alertes présentant au moins une alerte déterminée par lesdits moyens centralisés de gestion d'alertes et filtrée par lesdits moyens de filtrage. 8. Dispositif selon la revendication 6 comprenant en outre des moyens d'alertes périphériques (415) associés auxdits seconds moyens de présentation d'alerte, lesdits moyens d'alertes périphériques comprenant lesdits moyens de filtrage. 9. Dispositif selon la revendication 8 selon lequel lesdits moyens d'alertes périphériques comprennent des moyens de passerelle pour transmettre au moins un signal d'activation d'alarme reçu par lesdits moyens d'alertes périphériques auxdits moyens centralisés de gestion d'alertes. 10. Aéronef comprenant le dispositif selon l'une quelconque des revendications 6 à 9.