FR2989807A1 - Procede et dispositif de configuration d'un systeme de gestion d'alertes pour aeronef - Google Patents

Abstract

La présente invention concerne un procédé et un dispositif pour configurer un système de gestion d'alertes pour aéronef qui comprend les étapes de: - générer une liste d'une pluralité d'alertes et de procédures de résolution pour aéronef ; - pour chaque alerte: o définir: * des caractéristiques distinctives de l'alerte ; * une logique de détection de l'alerte ; * au moins une procédure de résolution de l'alerte ; et o enregistrer dans un fichier d'alertes dédié l'ensemble des informations définies pour ladite alerte, le fichier d'alertes ayant une structure et un format de données prédéfinies pour les alertes et les procédures ; - déterminer des liens existants entre les fichiers d'alertes dédiés ; et - en réponse à l'étape de détermination, mettre à jour le contenu des fichiers d'alertes dédiés selon les liens identifiés.

Description

2989807 PROCEDE ET DISPOSITIF DE CONFIGURATION D'UN SYS- TEME DE GESTION D'ALERTES POUR AERONEF L'invention concerne le domaine des systèmes de 5 gestion d'alertes sur aéronef, et plus particulière- ment un procédé et un dispositif pour configurer un tel système. Le système d'alerte d'un aéronef ou « Flight 10 Warning System » en anglais (FWS) est un système au coeur de l'aéronef. Il comprend généralement un système de gestion de procédures et une centrale d'alarmes. Il indique au pilote les procédures à suivre pour gérer l'avion, que ce soit en mode nominal ou en mode 15 dégradé. Quantitativement, un FWS gère de l'ordre de 5000 signaux, 1000 alertes et 1000 procédures. Ce système d'alerte est connecté à la plupart des équipements électroniques de l'avion, comme par exemple au système de gestion du carburant, au 20 système électrique ou hydraulique pour n'en citer que quelques uns. Les différents systèmes électroniques évoluent au cours du développement de l'avion, que ce soit dans leur interface ou dans les comportements dynamiques 25 des signaux générés, de sorte que la mise au point d'un FWS se fait tout au long du cycle de développement et jusqu'aux derniers vols précédant les vols de certification. Ainsi, le système d'alerte FWS est, par sa 30 position centrale, modifié et mis à jour continuellement pendant le développement de l'avion 2 2989807 mais essentiellement en dernière ligne droite juste avant la certification. Aussi la conception d'un FWS ne peut laisser place à des inexactitudes et des manques. Et un intégrateur d'avion doit s'assurer que tous les besoins d'alerte ont été captés en fonction des événements redoutés et des fonctionnements des différents sous-systèmes de l'avion. La capture du besoin d'alerte est communément réalisée de manière documentaire uniquement en utilisant des modèles documentaires qui listent des situations prédéfinies. Par ailleurs, la vérification de la complétude de ce besoin est faite par un processus de revue documentaire.

Ainsi, l'expression du besoin d'alerte est à ce jour faite en langage naturel et son exactitude reste interprétable. Ceci peut entrainer des inexactitudes et des incompatibilités techniques. Il existe alors le besoin d'une solution qui 20 permette de regrouper de manière complète les besoins d'alerte et permette de s'affranchir des erreurs d'interprétation. La présente invention répond à ce besoin. 25 Un objet de la présente invention est d'offrir un système et une méthode pour définir de manière itérative et complète les caractéristiques d'un FWS. 30 Un autre objet de la présente invention est de fournir un système adapté à l'utilisateur, qu'il soit 3 2989807 intégrateur avion ou compagnie aérienne. Avantageusement, la présente invention offre une interface de saisie des caractéristiques d'un FWS 5 propre à l'environnement de l'aéronef à caractériser. Avantageusement, la présente invention s'applique de manière dynamique à tout nouvel environnement de FWS ou tout nouveau besoin d'alerte à définir. 10 Avantageusement, la présente invention permet une pré-validation de l'édition des caractéristiques du FWS. 15 Un objet supplémentaire de la présente invention est d'offrir un dispositif permettant un développement itératif 'en horizontal' sur toutes les alertes puis sur toutes les procédures d'alerte ou 'en vertical' sur chaque alerte et ses procédures associées.

Avantageusement, la présente invention s'implémentera dans le contexte de l'industrie aéronautique.

Pour obtenir les résultats recherchés, un procédé et un dispositif sont proposés.

4 2989807 En particulier, un procédé exécuté sur un ordina- teur pour configurer un système de gestion d'alertes pour aéronef comprend les étapes de: 5 - générer une liste comprenant une pluralité d'alertes et de procédures de résolution pour aéronef ; pour chaque alerte: o définir: - des caractéristiques distinctives de 10 l'alerte ; ^ une logique de détection de l'alerte ; - au moins une procédure de résolution de l'alerte ; et o enregistrer dans un fichier d'alertes dédié 15 l'ensemble des informations définies pour la- dite alerte, le fichier d'alertes ayant une structure et un format de données prédéfinies pour les alertes et les procédures ; déterminer des liens existants entre les fichiers 20 d'alertes dédiés ; et en réponse à l'étape de détermination, mettre à jour le contenu des fichiers d'alertes dédiés selon les liens identifiés.

25 Différentes variantes d'implémentations sont dé- crites. Différents aspects et avantages de l'invention vont apparaitre en appui de la description d'un mode 30 préféré d'implémentation de l'invention mais non limitatif, avec référence aux figures ci-dessous : 5 2989807 La figure 1 est un schéma d'un système pour configurer un FWS selon les principes de l'invention ; 5 La figure 2 montre les étapes opérées par la méthode de l'invention pour configurer un FWS pour des alertes associées à des procédures ; La figure 3 illustre une interface utilisateur 10 graphique de saisie de caractéristiques d'alerte dans une implémentation préférentielle de l'invention ; La figure 1 illustre un système informatique (100) permettant d'implémenter le dispositif et 15 d'opérer le procédé de l'invention pour configurer un système de gestion d'alertes ou FWS. Le système 100 est composé d'une unité de traitement central 101 avec une mémoire de stockage 20 6 2989807 (RAM et ROM) 102. La mémoire 102 stocke des programmes informatiques relatifs au système d'exploitation et à des applications spécifiques tournant sur le système informatique 100, ainsi que des données du système.

5 Des unités de stockage additionnelles peuvent inclure des disques optiques 103 et des disques magnétiques 104. Cependant, les données et les programmes peuvent aussi être stockés et accessibles sur les unités additionnelles.

10 L'unité de traitement central 101 comprend des moyens d'entrer de données, comme par exemple un clavier de saisie 106, une souris 107, un micro 108 pour entrer du son, de la voix, mais aussi un scanner 109 pour entrer du texte, des images ou des 15 graphiques. L'unité de traitement central 101 comprend aussi des moyens de produire des données, comme par exemple des moyens d'affichage visuel 110, une imprimante 111, une sortie sonore 112, une sortie vidéo 113, ou autre.

20 La Figure 2 montre les étapes 200 opérées dans une variante d'implémentation de la méthode de l'invention. Dans une première étape 202, une liste d'alertes 25 et de procédures est générée. Cette liste peut être nouvelle et créée intégralement ou être issue d'un existant ou encore être une extension d'une liste d'alertes créée précédemment. Des alertes connues relèvent par exemple d'une mauvaise configuration de l'avion au décollage, telle qu'une position incorrecte des volets, une alerte de décrochage imminent ou 7 2989807 encore une alerte de déconnexion du pilote automatique. Des alertes et procédures existantes peuvent être 5 issues d'enregistrements précédents de ces données. Les enregistrements peuvent être stockés localement sur un système comme celui de la figure 1 où peut opérer la méthode ou être transférés depuis une base de données distante.

10 Les alertes sont définies en fonction de différents critères bien connus de l'homme du métier. En particulier, les alertes sont fonction de l'architecture structurelle et fonctionnelle de l'appareil considéré. Elles dépendent aussi de la 15 procédure connue d'analyse de hasard fonctionnelle préliminaireou « Preliminary Functional Hazard Analysis » (PFHA) en anglais qui prend en compte des évènements redoutés, comme par exemple la perte d'un moteur, d'une aile, ou le démarrage d'un feu. Les 20 alertes sont aussi fonction de la conduite de l'appareil considéré. Par ailleurs, certaines alertes sont imposées par une réglementation. A l'étape 204, le procédé fixe une variable (i) 25 pour sélectionner première alerte. A l'étape suivante 206, les caractéristiques de l'alerte sont définies. Pour chaque caractéristique, une valeur est attribuée. La valeur d'une caractéristique est choisie soit dans une liste de valeurs contraintes, soit 30 affectée par certains des attributs de la caractéristique, tel que par exemple la zone de variabilité pour une valeur réelle ou la longueur du 8 2989807 texte pour une chaine de caractère. Les caractéristiques définies à l'étape 206 sont détaillées plus bas en référence avec le tableau 4a et comprennent par exemple, le message de l'alerte tel 5 qu'il va être diffusé à son destinataire, le moyen d'attirer l'attention du destinataire ou « Attention Getter » en anglais, ou encore le niveau de priorité de l'alerte. L'étape suivante 208 consiste à définir la 10 logique de détection de l'alerte sélectionnée pour déclencher l'alerte et la stopper. Cette étape est essentielle et doit s'assurer de la cohérence de toutes les détections d'alerte implémentées pour le système. Cette étape est basée sur le comportement du 15 système surveillé, c'est-dire son état de fonctionnement. L'état de fonctionnement du système peut être nominal (pas d'alerte), dans un mode de configuration spécial (alerte de type MEMO pour un état non classique mais possible pour le système 20 surveillé), dans un état dégradé (tel le cas des systèmes fonctionnant sur 2 chaînes lors de la perte d'une des 2 chaînes), dans un état de panne, ou encore dans un état éteint. A l'étape suivante 210, le procédé vérifie s'il 25 existe au moins une procédure de résolution associée à l'alerte. S'il n'existe pas de procédure de résolution, le procédé s'arrête (224). Il n'y a pas de procédure quand il s'agit d'une simple information, telle que 30 une indication de « Phares de décollage allumés » ou «Ceintures attachées » par exemple.

9 2989807 S'il existe au moins une procédure de résolution, le procédé passe à l'étape 214 où un fichier « d'alerte avec procédure » est créé. La procédure de résolution d'une alerte prend en 5 compte l'ensemble des évènements permettant le choix de la meilleure procédure en fonction du contexte où intervient la panne déclenchant l'alerte. Cette étape essentielle est basée sur l'analyse du comportement du système surveillé et son interaction avec le reste de 10 l'avion. A l'étape 216, le procédé vérifie si toutes les alertes de la liste ont été définies. S'il reste des alertes à caractériser, le procédé incrémente (218) la 15 variable (i) et reboucle à l'étape 204 sur une nouvelle alerte pour en définir les caractéristiques (206), la logique de détection (208) et la ou les éventuelles procédures de résolution associées (210). Quand toutes les alertes ont été définies, le 20 procédé passe à l'étape 220. L'étape 220 consiste à assurer la cohérence globale du système surveillé sur toutes les alertes définies au niveau avion dans son ensemble. Le procédé vérifie les liens qui existent entre l'ensemble des 25 alertes caractérisées en fonction des pannes et de la hiérarchie des pannes. Il peut s'agir par exemple de l'inhibition d'alertes par des alertes primaires, ou de liens entre les procédures, tel que l'acquittement d'une procédure par une autre.

30 Quand des liens entre des alertes sont détectés, 10 2989807 le procédé passe à l'étape 222 où les fichiers d'alerte impliqués sont mis à jour. Quand tous les liens ont été établis, le procédé s'arrête (FIN).

5 La figure 3 illustre une interface utilisateur graphique 300 de saisie de caractéristiques d'alerte dans une implémentation préférentielle de l'invention. L'interface comprend avantageusement différents champs pour saisir les caractéristiques associées à 10 une alerte. Un champ 'Nom Alerte' 302 permet de désigner l'alerte, comme par exemple 'FEU MOTEUR' pour indiquer qu'il s'agit d'un feu moteur, ou encore 'Volets asymétriques', 'Fumée', 'Niveau de carburant bas', 15 'Panne de la pompe hydraulique du circuit 'bleu", `Panne du système de dégivrage des sondes'vpour ne donner que quelques exemples. Un champ 'Catégorie Alerte' 304 permet de sélectionner la catégorie de l'alerte comme alerte 20 normale, anormale, urgente, conseil, état ou autre catégorie. Un champ 'Priorité Alerte' 306 permet de saisir le niveau de priorité de l'alerte au sein de sa catégorie.

25 Un champ 'Effacement Alerte' 308 permet d'effacer l'alerte de l'écran par une action du pilote. Un champ 'Son Référent Alerte' 310 permet de sélectionner si un son doit être associé à l'alerte et lequel. Avantageusement des menus déroulants peuvent 30 proposer des sons. Un champ 'Inhibition Alerte Decollage' 312 permet 11 2989807 de définir les phases de vol dans lesquelles l'alerte est inhibée au décollage. L'interface homme-machine (IHM) décrite est un exemple dans une variante avantageuse d'implémentation 5 de l'invention, mais n'est en rien limitatif et l'homme de l'art pourra appliquer les principes de l'invention sur d'autres interfaces présentant des champs de saisie différents et/ou additionnels et organisés selon une présentation différente.

10 Comme décrit précédemment, la liste des alertes peut soit être créée et toutes les caractéristiques saisies par le/les utilisateurs. Alternativement, des alertes peuvent être préexistantes et rappelées avec 15 leurs caractéristiques qui peuvent être mises à jour depuis l'interface de saisie. Pour la seule compréhension de l'invention et par simplification, les tables 4 à 6 en annexe sont 20 maintenant décrites sur un exemple d'alerte en cas de différence d'altitude fournie par les calculateurs de données air, les calculateurs de données air étant au nombre de deux généralement. Les structures décrites en référence aux tables 4 à 6 sont seulement 25 illustratives, et toute variante d'implémentation peut être appliquée selon les mêmes principes de l'invention. Les tables 4a et 4b illustrent le contenu d'un 30 fichier de définition des caractéristiques d'alertes dans une implémentation préférentielle de l'invention.

12 2989807 Les tables 5a à 5f illustrent le contenu d'un fichier de définition des procédures de résolution d'alertes dans une implémentation préférentielle de l'invention. Le tableau 6 illustre le contenu d'un fichier de 5 définition des logiques de détection d'alertes dans une implémentation préférentielle de l'invention. Avantageusement, la structure du fichier d'alerte dédié est sous la forme d'une table 4a comprenant un 10 ensemble de colonnes (4002, 4004, 4006, 4008, 4010) définissant respectivement le 'Contexte' (4002), les `Données' (4004), la 'Description' (4006), la `Cardinalité' (4008) et la 'Plage' (4010). Le tableau de définition d'une alerte comprend un ensemble 15 d'entrées (402 à 430) qui vont être fixées selon l'alerte et caractérisées pour chacun des éléments des colonnes 4002 à 4010. Ce type d'alerte sera défini comme suit: 20 Nom de l'alerte (414) = Désaccord Air Altitude Type d'alerte (412) = Attention Niveau de priorité (410) = 3 Elément visuel à générer (406) = Attention majeure Elément audio à générer (416) = Simple carillon 25 Inhibition de cette alerte (424) = Phase de vol 1 à 4. Le tableau 4b illustre le contenu d'un fichier de 30 personnalisation de certains paramètres selon le type 13 2989807 d'alerte. Avantageusement, la structure du fichier personnalisé est sous la forme d'une table comprenant un ensemble de colonnes (4012, 4014, 4016) définissant respectivement les `Données Son' (4012), la `Description' (4014) et la 'Plage' (4016). La table personnalisée d'une alerte comprend un ensemble d'entrées (450 à 462) qui vont être fixées pour 10 personnaliser l'alerte. Ainsi, dans l'exemple décrit, la définition du son pour attirer l'attention en cas d'alerte de type 'Attention' est fixée à « Simple carillon» (450). Le son correspondant est basé sur une note 'DO' (452) qui dure 300 ms (échantillons 15 référencés par 462). Le son est séparé de 200ms d'un autre son. Le volume est de la moitié de ce qui est possible (454), sachant qu'il doit rester audible dans toutes les configurations sonores de l'aéronef. Le son n'est pas répété (456 et 458), et le son doit être 20 joué dans sa totalité pour être reconnu par l'équipage (460). La référence à la logique de détection associée à cette alerte est indiquée par une entrée réservée en 25 ligne 404. La définition de la logique de détection est illustrée en figure 6 pour l'exemple donné par : « la différence d'altitude filtrée entre les 2 sources doit être supérieure à 150 pieds et ce confirmé pendant 3 secondes ».

30 L'altitude de la source 1 « HP ADC1 » (602) est sur le label « 206 » (608) du bus « A429 » (604) « ADC1 HS outl » (606). L'altitude de la source 2 est 14 2989807 sur le label 206 du bus A429 ADC2 HS out5. Cette logique est avantageusement traduite par une expression en notation polonaise inverse suivante : 5 IHP_ADC2I 400IFPB 400IFPB IDIFF IABS 150ISUP irising f 3000iCONFI Les opérateurs suivants sont utilisables pour la définition des logiques : AND (et logique) OR (ou logique) 10 NOT (non logique) CONF (confirmation sur front descendant ou montant) PULSE (génération d'un signal égal à 1 pendant un cycle sur front descendant ou montant) MRTRIG (génération d'un signal égal à 1 pendant un 15 le temps spécifié à chaque front (descendant ou montant)) IF THEN ELSE (si la condition est vraie alors la valeur renvoyée est la première sinon c'est la seconde) 20 MULTIPLEXEUR (idem ci dessus avec un n arguments) EQ (égalité) NEQ (inégalité) SUP (supérieur strict à ) INF (inférieur strict à ) 25 DELAY (retarde le signal du temps spécifié HOLD (génération d'un signal égal à 1 pendant un le temps spécifié au premier front (descendant ou montant)) SUM (somme) 30 DIF (différence) 15 2989807 MUL (multiplication) DIV (division) ABS (valeur absolue) trigonométrie (COS, SIN, ATAN) 5 MIN (minimum) MAX (maximum) EXP (exponentiel) LN (logarithme népérien) FPB (filtre passe bas) 10 FPH (Filtre Passe Haut) ARRONDI (arrondi à la décimale spécifiée) RC (Racine Carrée). La définition de toute la procédure de résolution 15 de l'alerte est illustrée par les structures des tables 5a à 5f. Dans l'exemple utilisé, la procédure de résolution est définie par : Définition de la procédure (520) = P_01024 20 Définition du type de la procédure (522) = ANORMAL Définition du titre de la procédure (524) = DESACCORD ALTITUDE ENTRE ADC1 ET ADC2 Cette procédure a un contenu différent si 25 l'aéronef est en vol ou au sol. Ainsi la définition du contenu de la procédure (526) varie selon le contexte vol ou sol. Par, ailleurs, la définition de la procédure sol 30 (540) a des variantes différentes en fonction de la 16 2989807 configuration statique de l'aéronef (542). Par exemple, la définition de la variante sol avec une ADC3 non installée (544) `AU SOL' (546) et contient une seule de la procédure a un sous-titre page (548). La ordonnée d'item par son type 5 page (550) est définie par une liste (552). Un item (554) est défini « action » qui demande à l'équipage de réaliser une action. Une fois l'action faite, le FWS acquitte l'item en fonction de la logique associée (556).

10 L'item est défini par une requête « ADC1 » (558) qui demande à l'équipage de faire l'action associée « METTRE A OFF» (560). Pour cette action, il peut être demandé au cockpit une configuration particulière comme par exemple de présenter une page système (562).

15 Si l'item correspond à la fin d'une procédure, la procédure ou les procédures appelées sont alors définies (528) une fois cette procédure terminée. Dans l'exemple donné, il s'agit alors de la « procédure de dégivrage des sondes air » qui est labellisée 20 « P 01254 ». Ensuite, une fois cette procédure terminée, cette procédure ou les procédures supprimées de la liste sont définies (530). Dans l'exemple donné, il s'agit alors de la « perte du système de pressurisation 25 automatique de la cabine » qui est labellisée par « P 01080 ». Ainsi la présente description illustre une implémentation préférentielle de l'invention, mais 30 n'est pas limitative. Un exemple a été choisi pour permettre une bonne compréhension des principes de 17 2989807 l'invention, et une application concrète, mais il n'est en rien exhaustif et doit permettre à l'homme du métier d'apporter des modifications et variantes d'implémentation en gardant les mêmes principes.

5 La présente invention peut s'implémenter à partir d'éléments matériel et/ou logiciel. Elle peut être disponible en tant que produit programme d'ordinateur sur un support lisible par ordinateur. Le support peut 10 être électronique, magnétique, optique, électromagnétique ou être un support de diffusion de type infrarouge. De tells supports sont par exemple, des mémoires à semi-conducteur (Random Access Memory RAM, Read-Only Memory ROM), des bandes, des 15 disquettes ou disques magnétiques ou optiques (Compact Disk - Read Only Memory (CD-ROM), Compact Disk - Read/Write (CD-R/W) and DVD).

4002 4004 4006 4008 4010 Contexte Données Description Cardinalité Gamme 402 4O0DéfinitionAlerte référence Identifiant de l'Alerte dans la configuration 1 1..1500 404 signal Référence de la logique délcenchant l'alerte 1 IDT 406 moyenAnnonce Moyen d'annonce visuelle de conseil défini pour l'alerte.

1 MC/MW/ATC estEffaçable Booléen ms à VRAI si l'alerte peut être effacée à la demande de l'équipage 1 N/D priorité Niveau de priorité défini pour l'alerte dans un ensemble du même type 1 1..1000 412 type Type Alerte (ALARME ATTENTION, MÉMO, CONSEIL) priorité relative fixe par type 1 NID 414 nom Message CAS 1 Chaîne 40 416 Priorité Niveau de priorité pour son type 1 1..1000 418 DéfinitionAlerte son référence Référence du son devant être généré pour l'alerte 1 IDT 420 DéfinitionAlerte sonVoixétendu référence Référence du son devant être généré pour l'alerte selon réglementation spécifique 1 IDT 422 DéfinitionAlerte AlerteMère référence Identifiant de l'Alerte mère (l'alterte mère inhibe les alertes filles) 1..

10 IDT 424 DéfinitionAlerte inhibitionContexte étiquette Identifiant de la logique délcenchant le contexte inhibiteur 1..500 426 DéfinitionAlerte résolutionDéfinie InhibitionNécessaire Booléen mis à VRAI si l'alerte doit être inhibée dans la phase de vol identifiée 1..16 NID procédureSupérieure Référence de la procédure déclenchée par l'alerte dans la phase de vol identifiée 1..16 IDT 428 TransmissionAlerte AMaintenance TransrnissionNécessaire Booléen mis à VRAI si l'alerte doit être transmise 1 NID 430 TransrnissionAlerte AEnregistrement TransmissionNécessaire Booléen mis à VRAI si l'alerte doit être transmise 1 N/D Tableau 4a 4012 4014 4016 Données de son Description Gamme 450 référence kientifant du son dans la configuration IDT 452 type Type (TONAUTÉ ou VOIX) du son ; Utile pour déterminer le temps de séparation minimum entre deux sons. N/D 454 volume Niveau de volume du son devant être généré 0..256 456 motif Reproduction Nombre de répétitions des échantillons (UNE FOIS, INDEFINIVIENT) N/D 458 retardRépétition Retard entre deux répétitions du motif sonore 0..60000 ms 460 tempstVInimum Ternps minimum pendant lequel le son doit être généré pour être intelligible 0..60000 ms 462 DéfinitionListeEchantillon Liste d'un Echantillon définissant le Son 1..100 Tableau 4b 00 00 O Contexte Données Description Cardinalité Gamme 502 Déf in itionNotif icationNormale référence Identifiant de la NotificationNormale dans la configuration 1 1..1500 504 signal Référence de la logique déclenchant la notification normale 1 IDT 506 procédureSupérieure Référence de la procédure (normale) déclenchée par l'alerte dans la phase de vol identifiée 1 IDT 508 NnTransmission AMaintenance TransrrissionNécessaire Booléen mis à VRAI s'il est nécessaire de transmettre la Notification Normale 1 NID 510 NNITransmission AEnregistrement TransnissionNécessaire Booléen mis à VRAI s'il est nécessaire de transmettre la Notification Normale 1 NID Tableau 5a Procédure Données Description Cardinalité Gamme Activité 520 DéfinitionProcédure référence Identifiant de la Procédure dans la configuration 1 IDT 4 522 TypeProcédure type Définition du type de la procédure 1 URGENCE, ANORMAL, NORMAL, SPECIAL OPS, DIVERS 4 524 TitreProcédure étiquette Titre de la procédure 1 Chaîne 4 526 ProcédureContextuelle référence ,(logique) 1..10 (IDT;IDT} 4' Identifiant de la procédure et de la logique qui lui est associée pour des procédures contextuelles Tableau 5b Sous-Procédure Données Description Cardinalité Gamme 540 DéfinitionSousProcédure référence Identifiant de la sous-procédure dans la configuration 1 1..1000 542 DéfinitionSousProcédure procédurePropriétaire référence Identifiant de la Procédure propriétaire de la Sous-procédure dans la configuration 1 1..1000 Tableau 5c CD X CD Procédure Données Description Cardinalité Gamme 544 DénitionProcédure référence Identifiant de la variante de la Procédure contextuelle dans lai configuration IDT 546 SousTitreProcédure abel Sous-titre de la procédure 1 Chaîne 548 DéfinitionPagesProcédure référence Liste et rang de chaque page de la procédure 1..30 (IDT} Tableau 5d Page Données Description Cardinalité Gamme 550 _isteEléments référence _iste de tous les éléments de la page 1..50 (IDT} Tableau 5e Elément Données Description Cardinalité Gamme 552 IdentificationElément référence Liste de tous les éléments de la page 1 IDT 554 TypeElément type Type de l'élément 1 cf liste 556 _ogiqueAssocciéeAElément référence Référence à la logique associée à cet élément pour 1 IDT qu'il soit achevé 558 DéfiElément étiquette Ftiquette du défi pour cet élément 1 chaîne 560 RéponseElément étiquette ttiquette de la Réponse pour cet élément 0..1 chaîne 562 ConfigurationCockpitAssociée référence Référence à une configuration de cockpit particulière (comme une page système à afficher) 0..1 IDT 528 JéfinitionProcédure Procédures aval référence Identifiant de la Procédure devant être déclenchée lors de l'achèvement de la procédure si le type d'élément est « Procédure achevée » 0..10 IDT 530 JéfinitionProcédure ProcéduresAutoAchevées "éférence Identifiant de la Procédure devant être déclenchée lors de l'achèvement de la procédure si le type d'élément est « Procédure achevée » 0..20 "IDT Tableau 5f Contexte Données Description Cardinalité Gamme Exemple 302 Définition Entrée Logique référence Identifiant de l'entrée logique 1 DT HP_ADC1 SO4 Interface physique référence Type de l'interface physique 1 onnées discrètes, AN, 1553, A429 ou FDX A429 306 Définition Entrée Physique référence Identifiant de l'entrée physique 1 DT du fil pour données iscrète/CAN/1553/A42 ADC1 HS_o JI DT de VL pour AFDX 608 Données d'entrée référence Identifiant du message 0..1 ucune pour données iscrètes/CAN/1553 tiquette pour A429 SG pour AFDX 206 610 Sub référence Identification des,données utilisables 2 SB/MSB 11..18 Tableau 6 22

Claims (11)

1. REVENDICATIONS1. Un procédé exécuté sur un ordinateur pour configurer un système de gestion d'alertes pour aéronef comprenant les étapes de: - générer une liste comprenant une pluralité d'alertes et de procédures de résolution pour aéronef ; - pour chaque alerte: o définir: ^ des caractéristiques distinctives de l'alerte ; ^ une logique de détection de l'alerte ; ^ au moins une procédure de résolution de l'alerte ; et o enregistrer dans un fichier d'alertes dédié l'ensemble des informations définies pour ladite alerte, le fichier d'alertes ayant une structure et un format de données prédéfinies pour les alertes et les procédures; - déterminer des liens existants entre les fichiers d'alertes dédiés ; et - en réponse à l'étape de détermination, mettre à jour le contenu des fichiers d'alertes dédiés selon les liens identifiés.
2. 2. Le procédé selon la revendication 1 dans lequel l'étape de définir les caractéristiques distinctives de l'alerte consiste à définir un message d'alerte, un moyen d'attention, un niveau de priorité ou des inhibiteurs d'alerte.
3. 3. Le procédé selon la revendication 1 ou 2 dans lequel l'étape de définir une logique de détection de l'alerte consiste à définir une logique basée sur des opérateurs booléens et des opérateurs mathématiques. 23 2989807
4. 4. Le procédé selon l'une quelconque des revendications 1 à 3 dans lequel l'étape de définir au moins une procédure de résolution de l'alerte comprend une étape de déterminer des item et des actions de configuration de l'avion.
5. 5. Le procédé selon l'une quelconque des revendications 1 à 4 dans lequel l'étape d'enregistrer dans un fichier d'alertes dédié comprend une étape de stocker le fichier d'alerte dédié dans une base de données d'alertes.
6. 6. Le procédé selon l'une quelconque des revendications 1 à 5 dans lequel l'étape de déterminer les liens existants entre les fichiers d'alertes dédiés consiste à vérifier les liens entre l'ensemble des alertes.
7. 7. Le procédé selon l'une quelconque des revendications 1 à 6 dans lequel l'étape de définir pour chaque alerte comprend une étape de terminer le procédé si aucune procédure de résolution n'est définie pour l'alerte.
8. 8. Un dispositif pour configurer un système de gestion d'alertes pour aéronef comprenant : - un module de génération de liste d'alertes et de procédures de résolution pour aéronef ; - une interface utilisateur de saisie informatique permettant pour chaque alerte de définir: o des caractéristiques distinctives de l'alerte ; o une logique de détection de l'alerte ; o au moins une procédure de résolution de l'alerte ; - un module de stockage pour équipement informatique permettant de stocker dans un fichier d'alertes dédié l'ensemble des informations saisies pour chaque alerte ; - un module de détermination de liens existants entre les fichiers d'alertes stockés ; et 24 2989807 - un module couplé au module de détermination et au module de stockage pour mettre à jour automatiquement le contenu des fichiers d'alertes stockés selon les liens identifiés.
9. 9. Un dispositif selon la revendication 8 dans lequel l'interface utilisateur comprend des champs de saisie prédéfinis pour permettre la saisie des caractéristiques associées à une alerte.
10. 10. Un système de gestion d'alerte pour aéronef apte à être couplé opérativement avec un dispositif selon la revendication 8 pour configurer ledit système de gestion d'alerte.
11. 11. Un produit programme d'ordinateur, ledit programme d'ordinateur comprenant des instructions de code permettant d'effectuer les étapes du procédé selon l'une quelconque des revendications 1 à 7, lorsque ledit programme est exécuté sur un ordinateur.