FR 2935818 A1 20100312 FR 0804879 A 20080905 SYSTEME D'ORDONNANCEMENT DE TACHES POUR CONTROLER L'EXECUTION DE PROCEDURES D'ALERTE SUR UN AERONEF La présente invention appartient au domaine des systèmes de gestion de vol embarqués sur des aéronefs. Plus précisément, elle s'applique au système de gestion des alertes à bord qui contrôle la communication à l'équipage des alertes émises par un sous-système qui a détecté une panne ou un risque et liste les procédures à appliquer par ledit équipage en réponse aux dites alertes. Un système d'alertes en vol centralisé (Flight Warning System en anglais) constitue un progrès par rapport à des reports d'alertes par sous-système qui ne permettaient pas à l'équipage d'avoir une vue d'ensemble en cas de survenance concomitante de plusieurs alertes. En revanche, le développement et la maintenance de tels systèmes sont complexes et coûteux car ils dépendent non seulement des spécifications techniques des équipements des aéronefs mais plus encore des procédures opérationnelles des exploitants. Il est donc important de pouvoir facilement modifier la configuration d'un système de gestion d'alertes d'une part, pour un même modèle d'avion, en fonction de la commande de la compagnie aérienne qui l'exploite, d'autre part, pour une même compagnie aérienne, dans le temps, en fonction de l'évolution de la réglementation et des retours d'expérience. Ces conditions ne sont pas remplies par les systèmes de gestion d'alertes de l'art antérieur qui présentent la caractéristique d'être développés, compte tenu des contraintes de certification, comme un code séquentiel monolithique. Pour résoudre ce problème, l'idée générale de l'invention est de structurer le logiciel qui implémente les fonctions du FWS à la façon d'un séquenceur de tâches ayant un coeur système commun pour un même modèle d'avion et dont différents modules peuvent facilement être remplacés pour être adaptés à une configuration exploitant. A cet effet l'invention divulgue un système de gestion des alertes à bord d'un aéronef comprenant un module d'acquisition des données avion, un module de détection de pannes, un module d'alerte sur les dites pannes, un module d'interface utilisateur, caractérisé en ce qu'il comprend en outre un module d'ordonnancement de tâches à exécuter pour au moins une alerte et au moins une procédure à exécuter pour ladite alerte, ledit ordonnancement étant paramétrable par une table de configuration modifiable par une opération de maintenance d'exploitation. Avantageusement, la table de configuration comprend au moins, pour chacune des tâches, l'indication de l'alerte et de la procédure qui la définissent ainsi qu'au moins un paramètre d'ordonnancement de ladite tâche. Avantageusement, un des paramètres d'ordonnancement d'une tâche est un ordre de priorité d'affichage sur le module d'interface. Avantageusement, à chaque tâche est associée une variable d'état, ladite 10 variable étant historisable de manière paramétrable. Avantageusement, le système de gestion des alertes selon l'invention comprend en outre un module de conversion de fichiers XML pour générer la table de configuration. L'invention porte également sur un procédé de procédé de gestion des 15 alertes à bord d'un aéronef comprenant une étape d'acquisition des données avion, une étape de détection de pannes, une étape d'alerte sur lesdites pannes, une étape d'interface utilisateur, caractérisé en ce qu'il comprend en outre une étape d'ordonnancement de tâches à exécuter pour au moins une alerte et au moins une procédure à exécuter pour ladite alerte, ledit 20 ordonnancement étant paramétrable par une table de configuration modifiable par une opération de maintenance d'exploitation. Avantageusement, l'étape d'ordonnancement comprend une première sous-étape de définition de l'ordre de priorité d'exécution des tâches et une deuxième sous-étape de modification de l'état des tâches à partir des sorties 25 de l'étape d'acquisition des données avion et de l'étape d'interface utilisateur. En outre, l'invention porte sur un procédé de développement et de maintenance du système de gestion des alertes à bord d'un aéronef caractérisé en ce qu'il comprend au moins une étape de définition d'une liste de tâches à exécuter caractérisées par des variables choisies dans le groupe 30 (alerte, procédure, catégorie, priorité, état) et une étape de programmation en langage de haut niveau d'une partie au moins de la logique d'exécution des dites tâches. Avantageusement, le procédé de développement et de maintenance de l'invention comprend une étape de conversion en langage d'exécution du 35 programme en langage de haut niveau et une étape de chargement d'une partie au moins des sorties de l'étape de conversion dans une table de configuration dudit système à bord de l'aéronef. Avantageusement, l'étape de chargement est effectuée lors d'une opération de maintenance d'exploitation de l'aéronef. L'invention procure l'avantage supplémentaire que les contrôles, en particulier les acknowledge équipage, qui sont traditionnellement programmés dans la partie de l'interface homme-machine dédiée aux alertes dans les systèmes de l'art antérieur, sont, dans le système selon l'invention, effectués dans le séquenceur lui-même ce qui permet de répondre aux spécifications des compagnies clientes sans modifier la programmation de l'interface homme-machine. En outre, le séquenceur de tâches peut conserver en mémoire les états successifs des différents paramètres du système, ce qui permet d'améliorer la traçabilité des différentes actions accomplies pendant une alerte. De plus, la gestion des priorités au niveau des tâches, permet de gérer les conflits de priorité à différents niveaux des procédures applicables à plusieurs alertes en cours simultanément. Egalement, le temps de développement et de maintenance sont grandement réduits par la factorisation des développements qui résulte du découpage en tâches. L'invention sera mieux comprise, ses différentes caractéristiques et avantages ressortiront de la description qui suit de plusieurs exemples de réalisation et de ses figures annexées dont : La figure 1 représente les relations d'un système de gestion 25 d'alertes avec les autres systèmes embarqués; - La figure 2 représente l'architecture fonctionnelle simplifiée d'un système de gestion d'alertes selon l'invention ; - La figure 3 représente la logique de fonctionnement au niveau d'une tâche selon un mode de réalisation de l'invention ; 30 - La figure 4 illustre le fonctionnement du procédé de gestion des alertes à bord d'un aéronef selon l'invention sur une exemple de cas d'alerte. Sauf mention contraire, dans la description et les figures, les sigles, acronymes et abréviations ont la signification en français et en anglais indiquée dans le tableau ci-dessous. Sigle/Abréviation Signification NC Aircraft AFDX Avionics Full DupleX switched Ethernet AMS Avionics Management System ou Système de gestion de l'avionique ARINC Aeronautical Radio, Inc. BITE Built-In Test Equipment ou Equipement à auto-test integré 1 C/W Caution and Warning system ou Système de notification et d'alerte CAS Crew Alert System ou Système d'alerte équipage CKL Check List CDS Cockpit Display System ou Système d'affichage du cockpit ECAM Electronic Centralised Aircraft Monitor ou Moniteur centralisé de l'électronique de l'avion ECP ECAM Control Panel EWD Emergency Warning Display ou Panneau d'alerte d'urgence FWA Flight Warning application FWS Flight Warning System ou Système d'alerte en vol HMI/IHM Human Machine Interface ou Interface homme machine IMA Integrated Modular Avionics ou Avionique modulaire intégrée (AMI) DFFWS CSCI Communication Management Function/System Computer Software Configuration Item ou Article de configuration logicielle DCA Data concentration application ou Application de concentration de données Definition file du FWS MWC Master Warning Caution ou Système principal de notification et d'alerte NVM Non Volatile Memory ou Mémoire non volatile INOP SYS Système inopérant SWAP Severe Weather Avoidance Procedure ou Procédure d'évitement des conditions météo sévères T2CAS Terrain and Trafic Collision Avoidance System ou Système anticollision terrain/traffic TFTP Trivial File Transfer Protocol ou Protocole de transfert de fichier trivial WXR Weather Radar system ou Radar météorologique XML eXtensible Mark-up Language ou Language de balisage extensible La figure 1 représente les relations d'un système de gestion d'alertes avec les autres systèmes embarqués. Le système FWS est implanté en mode redondé sur deux calculateurs de l'architecture IMA (Avionique modulaire intégrée, pouvant être implantée sur un calculateur Power PC) dont la cohérence des sorties est vérifiée à chaque étape de calcul. Chaque calculateur FWS/FWA a donc pour entrée celles du calculateur dual à l'étape correspondante et lui envoie également ses résultats. En outre, le FWS reçoit en entrée les données A/C (ie : les discrets remontant des calculateurs embarqués utilisés pour détecter les défaillances d'un équipement électronique relié) et les données DCA sur n canaux (permettant de corréler les pannes entre elles). Enfin, quatre systèmes envoient avantageusement leurs sorties vers le calculateur FWS : Les sorties du panneau de contrôle du sous-système Moniteur centralisé de l'électronique de l'avion (ECP/ECAM) qui remontent les actions pilotes (acquittement d'item, déplacement dans la check-list, accès au pages systèmes et aux listes de procédures) ; Les états du bouton C/W de notification et d'alerte en sortie du système FWS; Les sorties du système T2CAS anticollision terrain et aéronefs ; ce système gère le positionnement de l'aéronef par rapport au relief et par rapport aux trajectoires des autres aéronefs détectés et envoie au système FWS des alertes en cas de trajectoire de collision ; Les sorties du système WXR de radar météorologique ; ces sorties permettent de déclencher des alertes sur intempéries sévères. Ces données sont conditionnées pour une utilisation par le système FWS (Fonction � Traitement des entrées �). Des logiques d'alerte équipage, de gestion des états et d'alerte A/C sont mises en oeuvre pour traiter les données d'entrées, les données traitées étant fournies au coeur de fonction générique FWS. Les logiques d'alertes équipages sont dédiées au déclanchement des alertes courantes spécifiques à un équipement donné. Lors de la réalisation d'une check-list (déclenchée par le premier type de logique), la logique d'état induit un check-list status. Les logiques d'alertes A/C sont identiques au premier type de logique, mais sont génériques à un ensemble de calculateurs et non à un calculateur unique. Les paramètres de la phase de vol en cours sont également fournis au coeur FWS. Le coeur FWS est avantageusement partitionné en trois fonctions de gestion (alertes équipage, états et liste de vérification) et quatre fonctions de gestion des alertes en sortie (zone CASICKL gérant les alertes déclanchées et induisant une procédure de check-list , INOP SYS gérant les alertes qui sont déclenchées et filtrées et n'induisant ni alerte ni procédure - seul le voyant INOP SYS sera vu par l'équipage, alertes audio, alertes bouton C/W). Les alertes audio sont sélectionnées dans une base de données de messages audio prévus à cet effet. Les alertes visuelles sont affichées sur les écrans prévus à cet effet dans le cockpit et la cabine de pilotage. Les protocoles Arinc 661 et TFTP permettent de communiquer avec le CDS (Cockpit display system)). Le protocole CMF permet d'envoyer les données de panne au système de maintenance centralisé, pour tracer toutes les anomalies détectées durant le vol); Gestion des procédures SWAP (Severe Weather Avoidance Procedure) : outil d'aide à la mise en oeuvre des procédures spécifiques de l'espace aérien nord-américain édictées par la FAA et déclenchées par le contrôle de trafic aérien en cas de nécessité de reroutage, notamment en cas d'orage sévère ou de cyclone. La figure 2 représente l'architecture fonctionnelle simplifiée d'un système de 35 gestion d'alertes selon l'invention. Un module d'acquisition des données 10 regroupe des paramètres nécessaires à l'évaluation du fonctionnement des systèmes supervisés. II peut s'agir de données intrinsèques (dysfonctionnement d'un équipement électronique ou d'un moteur, pression cabine, altitude, vitesse...) ou extrinsèques (sortie du système anticollision, sortie du système météo, message exploitant, message contrôle...). Il est également envisageable que le module d'acquisition de données acquière les données modifiées par l'équipage en réponse à une alerte et permette ainsi la validation en boucle fermée de l'exécution d'une procédure. Un module de détection de panne 20 analyse ces données supervisées pour en déduire la détection de pannes qui sont stockées dans un répertoire de pannes. Les commandes exécutées par l'équipage génèrent un répertoire des actions. Les pannes stockées dans le répertoire des pannes déclenchent le cas échéant une action du Master Warning, Master Caution (MWC) 30, généralement sous forme d'un signal visuel du bouton correspondant, éventuellement accompagné d'un message audio, le tout sous le contrôle de la logique de comportement du module MWC. Les actions à effectuer par l'équipage sont affichées par l'intermédiaire du module d'interface homme machine (IHM) 40 sous forme de procédures listées par pages. Une procédure standard est d'imposer à l'équipage l'acquittement de la consultation des pages listant les procédures à effectuer dans le cas d'une alerte en cours. Le séquencement proprement dit est effectué par les fonctions de gestion des priorités et de gestion des tâches regroupées dans le module d'ordonnancement de tâches 50. Ce module d'ordonnancement comprend les composants logiciels permettant de déclencher les alertes propres à chaque panne et de fournir aux utilisateurs les procédures associées en fonction des critères définis dans les différentes versions du système FWS. Comme détaillé par la suite, une tâche est un couple alerte, procédure qui comprend par ailleurs d'autres attributs. L'objet � Tâche � permet de réaliser l'ordonnancement à un niveau plus fin que celui de la procédure, qui est le niveau d'ordonnancement des systèmes FWS de l'art antérieur. Les paramètres d'ordonnancement des tâches de traitement des alertes par le système FWS qui sont propres à des conditions d'exploitation données d'un aéronef sont chargés dans une table de configuration 60 et utilisés par le module de détection de pannes (style d'affichage, texte des items des procédure, structure des procédures, liens entres procédures, identificateur unique de la tâche). Toutes les données statiques connues à priori sont dans la table de configuration) ; toutes les données décrivant la dynamique d'exécution du système ne sont pas décrites dans la table de configuration, mais font partie d'un méta modèle décrit en commentaire à la figure 4. A partir des données d'entrée du module 10, le module de détection de pannes 20 applique les logiques permettant de déterminer les identificateurs des tâches. La table de configuration peut facilement être mise à jour lors d'une opération de maintenance exploitant ou au cours d'une simple escale , par téléchargement d'une base de données qualifiée D0200 Le chargement s'effectue de manière simple sans nécessité de recompilation de programmes, les paramètres antérieurs étant simplement écrasés par les nouveaux par échange de fichiers sol/bord par protocole FTP ou TFTP au cours des opérations de maintenance centralisée. Les données à charger sont générés par un module XML. Le module d'ordonnancement comprend un modèle de données générique qui n'est pas modifié dans les différentes instanciations d'un système FWS développé pour un aéronef ayant une configuration matérielle et logicielle donnée. Le modèle est constitué de tâches à effectuer par le système en fonction de comportements ou règles prescrits. Les comportements ou règles permettent de traiter les connexions de (données caractéristiques de pannes) et vers (génération des alertes et application des procédures correspondantes) l'extérieur du système. Ces comportements peuvent évoluer d'une version à l'autre. Ils sont stockés dans la table de configuration du système. Les règles sont appliquées directement aux tâches, d'une part pour mettre en oeuvre la logique de gestion des priorités définies dans le système (fonction de Gestion des priorités), d'autre part pour prendre en compte les actions de l'utilisateur sur le modèle de données (fonction de Gestion des tâches). La logique de gestion des priorités peut être définie par exemple à trois niveaux, plus une règle de résolution de conflits en cas d'égalité de priorité, par exemple l'ordre d'arrivée. Le module d'ordonnancement ou séquenceur du FWS reçoit des déclencheurs et applique des comportements qui permettent de traiter les tâches du système. Pour chaque type de panne, le module � Détection panne � vérifie si les conditions de déclenchement de la panne sont réunies et met à jour le répertoire des pannes en conséquence. Le module � Gestion des priorités � active ou désactive les tâches en fonction des mises à jour du répertoire des pannes. Le module � Commande d'interaction avec l'acquisition � met à jour le répertoire des actions dès que l'utilisateur réalise une action sur I'ECP. Le module � Gestion des tâches � utilise ce répertoire des actions pour changer par exemple les états internes de la tâche en cours (changer de page, valider un item...), ou pour changer de tâche en cours. Le Séquenceur gère également les envois au système de notification/alerte (C/W) et les mises à jour de l'interface utilisateur (IHM). L'affichage des informations d'alerte sur l'interface utilisateur (EWD ou Emergency Warning Display) est normalisée (norme ARINC 661). Elle comprend un panneau de contrôle des éléments du CAS (Crew Alert System) et un panneau de contrôle des procédures correspondant à ces CAS. Les tâches peuvent être découpées en sous-tâches. Pour réaliser des procédures à choix multiples, chaque choix est représenté par une sous-tâche ayant la même priorité que la tâche dont elle est issue. Le séquenceur affiche à l'utilisateur les tâches dans l'ordre dans lequel elles doivent être exécutées, compte tenu des niveaux de priorité définis ou résultant de l'ordre d'arrivée. Un processus de contrôle du séquenceur tourne avec une fréquence déterminée de l'ordre de 50ms. Le dimensionnement du système dépend notamment de la puissance du calculateur et de la réactivité du bus. Le processus de contrôle du séquenceur modifie l'état interne des tâches du modèle à partir des entrées utilisateurs et des données de l'aéronef. La figure 3 représente la logique de fonctionnement au niveau d'une tâche selon un mode de réalisation de l'invention. L'entité TaskCategory peut prendre des valeurs différentes, par exemple : EMERGENCY : Tâche urgente (Liée à une panne prioritaire mettant l'avion en danger) - NORMAL : Tâche normale (Liée à une check-list courante correspondant aux actions pilotes d'une phase de vol) ABNORMAL : Tâche anormale (Liée à une panne non prioritaire ne 35 mettant pas l'avion en danger mais devant être traitée) - STATUS : Tâche de mise à jour des états (Liée à un résumé d'une tâche anormale complétée) CONSULTATION : Tâche de consultation (N'importe quelle tâche EMERGENCY, NORMAL OU ABNORMAL, en consultation libre, c'est-à-dire non déclenchée par le système) L'entité TaskState peut prendre par exemple les valeurs suivantes : CLEARED : Tâche active mais cachée à l'utilisateur sur demande utilisateur ACTIVE : Tâche active (panne déclenchée dans le système) IN PROGRESS : Tâche active en cours d'exécution (présentée à l'utilisateur) - COMPLETED : Tâche réalisée CONSULTED : Tâche consultée Comme déjà indiqué, les tâches peuvent comporter des sous-tâches qui 15 comportent leurs propres attributs, notamment leur état et leur lien de dépendance d'une tâche. Chaque tâche est liée à une alerte (CASItem) identifiée par une chaîne de caractères de message. L'affichage des CASItem est paramétrable par une feuille de style qui peut être choisie à un format par défaut ou configurée de 20 manière différente. L'affichage des données dans la feuille de style est paramétrable par l'intermédiaire d'un fichier XML. Chaque tâche est également liée à une procédure (Procedure) identifiée par une ou plusieurs chaînes de caractères. L'affichage des procédures étant paginé, chacune des pages où est affichée une procédure est identifiée par 25 un index (Pagelndex). Plusieurs indicateurs d'état peuvent également être prévus comme attributs d'une procédure, notamment une variable d'état indiquant si tous les items de la procédure ont été vérifiés (allltemsChecked) et si la procédure a été réalisée (isCompleted). La vérification des pages de procédure et, sur chaque page, de chaque item, peut également être suivie 30 par des variables d'état. Sur chaque page de procédure, chaque ligne (Line) peut également être identifiée par une étiquette (label). Chaque item de procédure peut être identifié par son appartenance à une catégorie (ProcedureltemCategory) qui peut prendre par exemple les valeurs suivantes : 35 - ACTION : Item d'action validable par l'utilisateur MEMO : Item de texte - PROC COMPLETED : Item indiquant que la procédure a été réalisée - PREVIOUS PAGE : Item d'action permettant d'accéder à la page précédente NEXT PAGE : Item d'action permettant d'accéder à la page suivante EMPTY : Item vide Le fonctionnement du procédé de gestion des alertes à bord d'un aéronef est illustré par l'application à un cas d'alerte illustré sur la copie d'écran en figure 4. Cet exemple n'est nullement limitatif des modes de réalisation possibles de l'invention : à gauche : ELEC SMK représente une alerte (Cas Item) détectée. - A droite : La procédure correspondant à l'alerte de gauche est présentée au pilote. o Les 2 premières lignes blanches représentent un item mémo (information non interactive) ; o La troisième ligne blanche représente un item action validé par le pilote ; o La ligne bleue encadrée représente l'item courant pouvant être validé ; o Les autres lignes bleues représentent les items actions non encore validés ; o Les lignes bleues avec le IF représentent un choix multiple. La validation d'un de ces items entraînera la sélection de la sous- tâche correspondante. La structuration du système FWS selon l'invention ainsi qu'elle vient d'être décrite permet d'organiser les développements de manière à factoriser une grande partie des lignes de code du logiciel. Les parties qui ne dépendent que de la configuration matérielle des modules extérieurs et de la configuration logicielle commune à un type d'aéronef sans dépendre des spécifications variables de l'avionneur, sont implantées dans le module d'ordonnancement. Les parties qui dépendent étroitement des conditions opérationnelles d'emploi propres à un exploitant, telles que l'attribution de niveaux de priorité à des tâches, le contenu des procédures, les feuilles de style d'affichage ainsi que la logique d'exécution des tâches et de l'affichage, notamment, sont traitées comme des paramètres qui sont stockés dans une table de configuration. Ces parties peuvent être programmées en utilisant un langage de haut niveau, tel que XML (eXtended Mark-up Langage). Un atelier de développement logiciel permet de gérer cette répartition des traitements et des données. La certification peut être obtenue avec une configuration initiale. Il ne sera pas nécessaire de certifier à nouveau les évolutions futures du système FWS avec une table de configuration modifiée, dans la mesure où il peut être prouvé que la modification de la table ne change en rien le comportement du système. Cela sera le cas si l'atelier de ~o développement logiciel est compatible de la norme DO200. Pour effectuer une modification de la table de configuration, il suffit de générer un ou plusieurs fichiers XML qui seront convertis par l'atelier de développement dans la structure de la table de configuration. On utilise généralement deux types différents de fichiers XML, un premier type qui 15 décrit la feuille de style applicable aux données et un deuxième type comprenant la description de toutes les données nécessaires au traitement des tâches par le séquenceur. L'opération de chargement peut alors être effectuée lors d'une simple opération de maintenance d'exploitation lorsque l'avion est immobilisé à une 20 porte en utilisant les outils prévus à cet effet (protocole TFTP, Trivial File Transfer Protocol, ou autre protocole présentant les mêmes procédures d'acquittement des chargements vers le calculateur IMA). Les exemples décrits ci-dessus sont donnés à titre d'illustration de modes de 25 réalisation de l'invention. Ils ne limitent en aucune manière le champ de l'invention qui est défini par les revendications qui suivent. REVENDICATIONS1. Système de gestion des alertes à bord d'un aéronef comprenant un module d'acquisition des données avion (10), un module de détection de pannes (20), un module d'alerte sur les dites pannes (30), un module d'interface utilisateur (40), caractérisé en ce qu'il comprend en outre un module d'ordonnancement de tâches (50) à exécuter pour au moins une alerte et au moins une procédure à exécuter pour ladite alerte, ledit ordonnancement étant paramétrable par une table de configuration (60) modifiable par une opération de maintenance d'exploitation. 2. Système de gestion des alertes à bord d'un aéronef selon la revendication 1 caractérisé en ce que la table de configuration comprend au moins, pour chacune des tâches, l'indication de l'alerte et de la procédure qui la définissent ainsi qu'au moins un paramètre d'ordonnancement de ladite tâche. 3. Système de gestion des alertes à bord d'un aéronef selon la revendication 2 caractérisé en ce qu'un des paramètres d'ordonnancement d'une tâche est un ordre de priorité d'affichage sur le module d'interface. 4. Système de gestion des alertes à bord d'un aéronef selon la revendication 1 caractérisé en ce qu'à chaque tâche est associée une variable d'état, ladite variable étant historisable de manière paramétrable. 5. Système de gestion des alertes à bord d'un aéronef selon la revendication 1 caractérisé en ce qu'il comprend en outre un module de conversion de fichiers XML pour générer la table de configuration. 6. Procédé de gestion des alertes à bord d'un aéronef comprenant une étape d'acquisition des données avion, une étape de détection de pannes, une étape d'alerte sur lesdites pannes, une étape d'interface utilisateur, caractérisé en ce qu'il comprend en outre une étape d'ordonnancement de tâches à exécuter pour au moins une alerte et au moins une procédure à exécuter pour ladite alerte, ledit ordonnancement étant paramétrable par une table de configuration modifiable par une opération de maintenance d'exploitation. 7. Procédé de gestion des alertes à bord d'un aéronef selon la 35 revendication 6 caractérisé en ce que l'étape d'ordonnancement comprendune première sous-étape de définition de l'ordre de priorité d'exécution des tâches et une deuxième sous-étape de modification de l'état des tâches à partir des sorties de l'étape d'acquisition des données avion et de l'étape d'interface utilisateur. 8. Procédé de développement et de maintenance d'un système de gestion des alertes à bord d'un aéronef caractérisé en ce qu'il comprend au moins une étape de définition d'une liste de tâches à exécuter caractérisées par des variables choisies dans le groupe (alerte, procédure, catégorie, priorité, état) et une étape de programmation en langage de haut niveau ~o d'une partie au moins de la logique d'exécution des dites tâches. 9. Procédé de développement et de maintenance d'un système de gestion des alertes à bord d'un aéronef selon la revendication 8 caractérisé en ce qu'il comprend une étape de conversion en langage d'exécution du programme en langage de haut niveau et une étape de chargement d'une 15 partie au moins des sorties de l'étape de conversion dans une table de configuration dudit système à bord de l'aéronef. 10. Procédé de développement et de maintenance d'un système de gestion des alertes à bord d'un aéronef selon la revendication 9 caractérisé en ce que l'étape de chargement est effectuée lors d'une opération de 20 maintenance d'exploitation de l'aéronef.