FR2989808A1

FR2989808A1 - Systeme de gestion d'alertes et de procedures electroniques entierement parametrable destine a un aeronef

Info

Publication number: FR2989808A1
Application number: FR1201200A
Authority: FR
Inventors: Xavier Chazottes; Stephane Bertheau; Michel Mazenoux
Original assignee: Thales SA
Current assignee: Thales SA
Priority date: 2012-04-24
Filing date: 2012-04-24
Publication date: 2013-10-25
Anticipated expiration: 2032-04-24
Also published as: FR2989808B1; RU2623281C2; US20130282207A1; CA2814160C; CA2814160A1; US8948938B2; RU2013118709A

Abstract

Système de gestion d'alertes et de procédures destiné à un aéronef comprenant un noyau logiciel (14) à bord de l'aéronef et un outil de paramétrage (10) du noyau logiciel (14) caractérisé en ce que, l'outil de paramétrage (10) comprend un module de conversion (11), d'un fichier de configuration (12), décrivant un besoin opérationnel du système de gestion d'alertes et de procédures, en une base de données de paramètres binaires (13) apte à paramétrer le noyau logiciel (14), et en ce que le noyau logiciel (14) comprend au moins quatre cellules élémentaires : une première cellule d'acquisition de signaux aéronef, une seconde cellule de caractérisation de variables d'état de l'aéronef,une troisième cellule de calcul d'au moins un évenement unitaire, une quatrième cellule d'ordonnancement des évenements unitaires pour la communication avec l'équipage ;chacune des cellules comprenant un moteur logiciel paramétrable par la base de données (13).

Description

Système de gestion d'alertes et de procédures électroniques entièrement paramétrable destiné à un aéronef 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 aux systèmes de gestion des alertes à bord qui collectent des signaux de l'aéronef, établissent des alertes, liste et gère l'état des procédures à appliquer par l'équipage et organise la communication avec ledit équipage. Un système d'alertes en vol centralisé, FWS (pour 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 définies par les avionneurs et spécialisées par les exploitants. Il est donc important de pouvoir facilement modifier la configuration d'un système de gestion d'alertes et de procédures d'une part, pour un même modèle d'avion, en fonction de la commande de la compagnie aérienne qui l'exploite, ou pour une même compagnie aérienne dans le temps au fil de l'évolution de la réglementation et des retours d'expérience, et d'autre part, pour plusieurs modèles d'avions, lorsque ceux-ci présente une part significative commune, dans les composants, les sous-systèmes ou encore les besoins opérationnels de l'exploitant. Ces conditions ne sont pas remplies par les systèmes de gestion d'alertes et de procédures 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. Une conception et des validations longues, réalisées en fin du cycle de développement d'un aéronef, sont nécessaires pour intégrer au système d'alerte les développements des autres sous-systèmes de l'aéronef ; des mises à jour logicielles régulières doivent être organisées pendant le développement et dans une phase ultérieure d'exploitation commerciale de l'aéronef. Pour résoudre ce problème, l'idée générale de l'invention est de structurer le système de gestion d'alertes et de procédures en isolant d'une part un noyau logiciel générique qui constitue une partie invariante et qui est certifié, et d'autre part une partie variable configurable pour permettre d'adapter le système d'alerte aux évolutions des besoins opérationnels de l'aéronef, en développement ou en exploitation.

On connaît aussi de la demande de brevet déposée par la demanderesse sous le n° de publication FR2935818, un système de gestion d'alertes dont un module d'ordonnancement de taches est modifiable au moyen d'une table de configuration. Le document propose ainsi de factoriser une partie du code de logiciel du système de gestion d'alertes , en rendant paramétrable un module d'ordonnancement de taches. Pourtant, une partie importante du système de gestion d'alertes reste à développer sous la forme d'un code séquentiel monolithique ; l'architecture proposée ne permet pas de s'affranchir des temps de développement logiciel et de certification.

L'invention propose de résoudre ce problème et à cet effet, l'invention a pour objet un système de gestion d'alertes et de procédures destiné à un aéronef comprenant un noyau logiciel à bord de l'aéronef et un outil de paramétrage du noyau logiciel caractérisé en ce que, l'outil de paramétrage comprend un module de conversion, d'un fichier de configuration décrivant un besoin opérationnel du système de gestion d'alertes et de procédures, en une base de données de paramètres binaires apte à paramétrer le noyau logiciel. Le noyau logiciel comprend au moins quatre cellules élémentaires : - une première cellule d'acquisition et de consolidation d'un ensemble de signaux aéronef, - une seconde cellule de caractérisation d'un ensemble de variables d'état de l'aéronef, généré à partir des signaux aéronef ; - une troisième cellule de calcul d'au moins un évenement unitaire, 30 comprenant au moins une alerte ou une procédure, généré à partir des signaux aéronefs consolidés et/ou des variables d'état ; - une quatrième cellule d'ordonnancement des évenements unitaires pour la communication avec l'équipage ; chacune des cellules comprenant un moteur logiciel paramétrable par la 35 base de données de paramètres binaires.

Avantageusement, le fichier de configuration décrit un besoin opérationnel par un ensemble de paramètres structuré conformément à un domaine de configuration prédéterminé, ledit domaine de configuration étant constitué de taches unitaires, comprenant au moins une alerte ou une procédure, chaque tache unitaire étant décrite par des valeurs de paramètres dans une liste prédéterminée comprenant au moins un paramètre du type, alerte, son d'alerte, phase de vol, évenement déclenchant, signal aéronef, contexte, procédure, contenu d'une procédure, item ou menu ; à chaque paramètre étant associé une plage de valeurs autorisée.

Avantageusement, l'outil de paramétrage convertit un fichier de configuration codé en langage XML et conforme au domaine de configuration en un base de données de paramètres binaires apte à paramétrer chacune des cellules élémentaires du noyau logiciel. Avantageusement, les moteurs logiciel des quatre cellules élémentaires sont validés unitairement ; la validation d'un séquencement entre les cellules étant facilité par des interfaces entre cellules de type booléennes, limitant la combinatoire de tests d'assemblage des cellules, indépendement du paramétrage. L'invention porte également sur un procédé de paramétrage d'un système de gestion d'alertes et de procédures destiné à un aéronef ayant les caractéristiques précédemment décrites, caractérisé en ce qu'il comprend une première étape de vérification du domaine de configuration d'un fichier de configuration représentatif d'un besoin opérationnel dudit système de gestion d'alertes et de procédures, et une seconde étape de conversion du fichier de configuration en une base de données de paramètres binaires apte à paramétrer un système de gestion d'alertes et de procédures générique validé pour ledit domaine de configuration. L'invention porte aussi sur un procédé de développement d'un système de gestion d'alertes et de procédures destiné à un aéronef ayant les caractéristiques précédemment décrites, caractérisé en ce qu'il comprend une étape de définition d'un domaine de configuration de taches à éxécuter, ledit domaine de configuration étant apte par paramétrage à couvrir un large spectre de besoins opérationnels du système de gestion d'alertes et de procédures, une étape de programmation des moteurs logiciels de chacune des cellules élémentaires, et une étape de paramétrisation de la logique d'exécution des taches de chacune des cellules élémentaires. L'invention porte enfin sur un procédé de maintenance d'un système de gestion d'alertes et de procédures destiné à un aéronef ayant les 5 caractéristiques précédemment décrites, caractérisé en ce qu'il comprend une étape de conversion d'un fichier de configuration décrivant un besoin opérationnel du système de gestion d'alertes et de procédures en une base de données de paramètres binaire, et une étape de paramétrage du système de gestion d'alertes et de procédures par la base de données de paramètres 10 binaires réalisés lors d'une opération de maintenance de l'aéronef. L'invention sera mieux comprise et d'autres avantages apparaîtront à la lecture de la description détaillée des modes de réalisation donnés à titre d'exemple sur les figures suivantes : 15 - La figure 1 représente les relations d'un système de gestion d'alertes et de procédures avec les autres systèmes embarqués; - Les figures 2a et 2b représentent un exemple d'architecture fonctionnelle simplifiée d'un système de gestion d'alertes et de procédures selon l'invention ; 20 La figure 3 représente un exemple de logique de fonctionnement au niveau d'une tâche selon un mode de réalisation de l'invention. Par souci de clarté, les mêmes éléments porteront les mêmes repères dans les différentes figures. 25 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 A/C Aircraft ou Aéronef ARINC 664p7 Avionics Network 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 integer 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 ou procédures CDS Cockpit Display System ou Système d'affichage du cockpit CASDB Crew Alert System Database CKLDB Check List Database SYSDB System Database CMF/CMS Communication Management Function/System CSCI Computer Software Configuration Item ou Article de configuration logicielle DCA Data concentration application ou Application de concentration de données DFFWS Definition file du FWS ECP Engine & display Control Panel du FWS EWD Engine & 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) 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 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 et de procédures avec les autres systèmes embarqués. Le système FWS est implanté en mode redondé sur deux 5 calculateurs de l'architecture IMA (Avionique modulaire intégrée, pouvant être implantée sur un calculateur) 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 10 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 15 l'électronique de l'avion (ECP) 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; 20 - 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 25 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 »). Dans les systèmes connus, 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 30 étant fournies au coeur de fonction générique FWS. Les logiques d'alertes équipages sont dédiées au déclenchement 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. 2 98980 8 7 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.

Dans les systèmes connus, le coeur FWS est partitionné en trois fonctions de gestion (alertes équipage, états et liste de vérification) et quatre fonctions de gestion des alertes en sortie (zone CAS/CKL gérant les alertes déclenché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. Les figures 2a et 2b représentent un exemple d'architecture fonctionnelle simplifiée d'un système de gestion d'alertes et de procédures selon l'invention. En particulier, la figure 2a décrit un outil de paramétrage 10 comprenant un module de vérification et conversion 11 d'un fichier de configuration 12 en une base de données de paramètres binaires 13. La figure 2b décrit un noyau logiciel générique 14, paramétrable au moyen d'une base de données de paramètres binaires 13, et apte à organiser la communication d'alertes et de procédures avec l'équipage, au moyen d'une interface homme machine (IHM) 15 placée dans le cockpit de l'aéronef. Le noyau logiciel générique 14 constitue le système FWS à bord de l'aéronef, implanté en mode redondé sur les calculateurs 16 de l'architecture IMA. Il recoit par ce biais un ensemble de signaux extérieurs Le système de gestion d'alertes et de procédures selon l'invention est structuré en deux sous-ensembles distincts, un noyau logiciel générique 14 embarqué à bord de l'aéronef et un outil de paramétrage 10 du noyau logiciel générique 14. Cette structure a pour but de rationnaliser les développements entre une partie logicielle stable qui fait l'objet d'une certification conformément aux exigences de certification en vigueur , et notamment la norme D0178C pour la catégorie "code logiciel avionique", et une partie paramétrable dépendante des spécifications variables de l'avionneur ou de l'exploitant, et soumise aussi à la norme D0178C pour la catégorie "fichier de paramètres". Un système FWS selon l'invention peut ainsi être mis à jour lors d'une opération de maintenance ou lors d'une simple escale, par téléchargement d'une base de données de paramètres binaires, par exemple qualifiée selon la norme D0200. Le chargement s'effectue de manière simple sans nécessiter de recompilation de programmes, les paramètres antérieurs étant simplement écrasés par les nouveaux par échange de fichier sol/bord, par exemple par protocole FTP (File Transfer Protocol) ou TFTP (Trivial File Transfert Protocole) au cours des opérations de mise à jour centralisées de développement ou des opérations de maintenance d'exploitation lorsque l'avion est immobilisé à une porte d'un aéroport. Ainsi, le système de gestion d'alertes et de procédures peut être adapté à une évolution du besoin opérationnel, par exemple en raison d'une évolution des spécifications composants ou avionneur, ou en raison d'une évolution des conditions opérationnelles d'utilisation propres à un exploitant, telles que l'attribution de niveaux de priorité à des taches, le contenu des procédures, les feuilles de style d'affichage ou encore la logique d'exécution des taches et de l'affichage sur l'IHM 15. Selon l'invention, l'ensemble des besoins opérationnels du système de gestion d'alertes et de procédures est regroupé dans un fichier de configuration 12. Ce fichier de configuration 12 est convertit par l'outil de paramétrage 10 en une base de données de paramètres binaires 13. Le noyau logiciel générique 14 paramétré au moyen de la base de données 13 permet, à bord de l'aéronef, la gestion des alertes conformément aux besoins opérationnels exprimés dans le fichier de configuration 12.

Pour cela est définit dans une première phase de développement du système de gestion de vol, un domaine de configuration représentatif de la variabilité du besoin opérationnel du système de gestion d'alertes et de procédures électroniques. Selon l'invention, le domaine de configuration est constitué d'un ensemble de taches unitaires ; une tache unitaire, par exemple une alerte ou une procédure à éxécuter, étant décrite par des valeurs de paramètres dans une liste prédéterminée. Dans un mode possible de réalisation de l'invention, la liste des paramètres configurables pour chaque tache unitaire comprend : - la définition des sons d'alertes : type de son, durée, volume sonore, caractère répétitif ; - la définition des phases de vol : arbre de décision binaire, avec les phases de vol et les logiques des noeuds de décision, définition d'une validité de la phase de vol, robuste à une non disponibilité partielle des entrants des 10 logiques des noeuds de décision ; - la définition des alertes : événement déclenchant, moyens d'annonce visuel et audio, priorité, message texte, type d'alerte, phases de vols inhibitrices, contextes inhibiteurs, procédure associée ; - la définition des événements déclenchants : liste des signaux aéronef avec 15 leur loi de déformatage et de consolidation, table séquentielle d'opérations transformant la liste des signaux et des contextes en un événement déclenchant ; - la définition des signaux aéronef : liste des signaux aéronef avec leur loi de déformatage et de consolidation ; 20 - la définition des contextes : liste des signaux aéronef avec leur loi de déformatage et de consolidation, table séquentielle d'opérations transformant la liste des signaux en un contexte ; - la définition des procédures : titre, type, position dans le menu, liste de procedures attachées, liste des procédures auto-complétées, contenu de la 25 procédure ; - la définition du contenu d'une procédure : composition en pages et items ; - la définition d'un item : catégorie, contenu texte, style graphique, page système attachée, événement d'auto-acquittement ; - la définition du menu : nombre de ligne, définition d'un sous-menu ou d'un 30 titre de procédure. Pour chacun des paramètres de la liste, une plage de valeurs est autorisée. Le domaine de configuration a pour but de couvrir un spectre étendu de besoins opérationnels. Pour limiter les efforts de dévelopement logiciel et 35 de certification associée, on cherche à couvrir pour un domaine de configuration plusieurs types aéronefs et les exigences d'un grand nombre d'exploitants ultérieurs de l'aéronef. Selon l'invention, le fichier de configuration 12 décrit le besoin opérationnel du système de gestion d'alertes et de procédures au moyen d'un ensemble de paramètres structuré conformément au domaine de configuration. Ce fichier de paramètre textuel balisé peut être établi en utilisant un langage de haut niveau, tel que XML (eXtended Mark-up Langage). Comme cela est décrit par la suite, le noyau logiciel générique est conçu de façon à pouvoir être paramétré pour un domaine de configuration prédéterminé, tel que décrit ci-dessus. Ainsi, lorsqu'une mise à jour du système de gestion d'alertes et de procédures est nécessaire, le nouveau besoin opérationnel est décrit par un fichier de configuration conforme au domaine de configuration pour lequel le noyau générique a initialement été développé. Le module de conversion transforme ce fichier de configuration en une base de données de paramètres binaires apte à paramétrer le noyau de logiciel générique. Avantageusement, la liste de paramètres du domaine de configuration et leurs plages de variations autorisées sont configurés de façon à permettre de couvrir un spectre étendu de besoin opérationnel, dans le but de limiter l'activité de développement logiciel et de certification à un noyau logiciel générique. La figure 3 représente un exemple d'architecture fonctionnelle du noyau logiciel générique paramétrable selon l'invention. Le noyau logiciel 25 générique comprend quatre cellules élémentaires : - une première cellule 21 d'acquisition et de consolidation d'un ensemble de signaux aéronef transmis au système de gestion d'alertes et de procédures du FWS. Il peut s'agir de données intrinsèques (dysfonctionnement d'un équipement électronique ou d'un moteur, pressions cabine, altitude, 30 vitesse...) ou extrinsèques (sortie du système anticollision, sortie du système météo, message exploitant, message contrôle...). Il peut aussi s'agir de données modifiées par l'équipage en réponse à une alerte pour permette la validation en boucle fermée de l'exécution d'une procédure ; - une seconde cellule 22 de caractérisation d'un ensemble de variables d'état de l'aéronef, tels que par exemple l'état d'une alerte ou l'acquittement automatique de l'item d'une procédure en cours ; - une troisième cellule 23 de calcul d'au moins un évenement unitaire, tel 5 qu'une alerte ou une procédure, généré à partir des signaux aéronefs consolidés et/ou des variables d'état ; - une quatrième cellule 24 d'ordonnancement des évenements unitaires pour la communication avec l'équipage. Il peut s'agir en pratique d'une machine à état apte à mémoriser, prioriser ou décider pour un ensemble d'évenements 10 unitaires de la communication avec l'équipage, par exemple par des alertes sonores ou par l'IHM cockpit. Comme représenté sur la figure 3, chaque cellule élémentaire héberge un sous ensemble de paramètres de configuration de la base de 15 données de paramètres binaires 13 et est animée par un moteur logiciel générique. Les quatre moteurs logiciel des cellules élémentaires constituent la partie invariante du noyau logiciel générique. Chacune des cellules élémentaires a été validée unitairement pour l'ensemble des possibilités de configuration, c'est à dire pour l'ensemble des valeurs possibles des 20 paramètres du domaine de configuration. La validation du séquencement est facilitée par la nature des interfaces entre les cellules qui sont exclusivement booléennes, limitant la combinatoire de tests d'assemblage des cellules, indépendement du paramétrage. Comme représenté sur la figure 3, la première cellule d'acquistion et 25 de consolidation communique un ensemble de signaux booléen à la seconde cellule pour la caractérisation d'un ensemble de variables d'état de l'aéronef. La première cellule et la seconde cellule communiquent un ensemble de signaux booléen à la troisième cellule pour le calcul d'au moins un évenement unitaire. La seconde cellule et la troisième cellule communique 30 un ensemble de signaux booléen à la quatrième cellule pour l'ordonnancement des évenements unitaires pour la communication avec l'équipage. La structuration d'un domaine de configuration prédéterminé, et le découpage en quatre cellules élémentaires paramétrables animées par 35 quatre moteurs logiciels génériques selon l'invention permet avantageusement d'isoler les parties invariantes du système de gestion d'alertes et de procédures. Il devient possible de factoriser l'ensemble des lignes de code du logiciel. Les parties invariantes qui dépendent par exemple de configurations matérielles de composants communs à un ensemble 5 d'aéronefs ou qui dépendent de logiques d'éxécution réglementaires sont isolés des parties variables paramétrables. Les conditions opérationnelles d'emploi propres à un exploitant, l'attribution de niveaux de priorité d'évenement unitaire, 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, 10 notamment, sont traitées comme des paramètres rassemblés dans un fichier de configuration. Dans une première phase du développement, on définit un domaine de configuration d'un ensemble de paramètres représentatifs de la variabilité du besoin opérationnel de différents aéronefs pour la fonction 15 d'alerte. Le noyau logiciel générique, constitué des quatre cellules élémentaires, est conçu et validé pour ce domaine de configuration. La certification du noyau logiciel générique, valable pour l'ensemble du domaine de configuration, couvre un spectre étendu de besoins opérationnels. Il devient possible de paralléliser le développement du système de gestion 20 d'alertes et de procédures avec les taches de développement de l'aéronef, il est aussi possible de faire évoluer le système de gestion d'alertes et de procédures par une simple opération de paramétrage. Les exemples décrits ci-dessus sont donnés à titre d'illustration de modes de réalisation de l'invention. Ils ne limitent en aucune manière le 25 champ de l'invention qui est défini par les revendications qui suivent.

Claims

REVENDICATIONS1. Système de gestion d'alertes et de procédures destiné à un aéronef comprenant un noyau logiciel (14) à bord de l'aéronef et un outil de paramétrage (10) du noyau logiciel (14) caractérisé en ce que, l'outil de paramétrage (10) comprend un module de conversion (11), d'un fichier de configuration (12), décrivant un besoin opérationnel du système de gestion d'alertes et de procédures, en une base de données de paramètres binaires (13) apte à paramétrer le noyau logiciel (14), et en ce que le noyau logiciel (14) comprend au moins quatre cellules élémentaires : - une première cellule (21) d'acquisition et de consolidation d'un ensemble de signaux aéronef, - une seconde cellule (22) de caractérisation d'un ensemble de variables d'état de l'aéronef, généré à partir des signaux aéronef ; - une troisième cellule (23) de calcul d'au moins un évenement unitaire, 15 comprenant au moins une alerte ou une procédure, généré à partir des signaux aéronefs consolidés et/ou des variables d'état ; - une quatrième cellule (24) d'ordonnancement des évenements unitaires pour la communication avec l'équipage ; chacune des cellules (21, 22, 23, 24) comprenant un moteur logiciel 20 paramétrable par la base de données de paramètres binaires (13).
2. Système de gestion d'alertes et de procédures selon la revendication 1, caractérisé en ce que le fichier de configuration (12) décrit un besoin opérationnel par un ensemble de paramètres structuré 25 conformément à un domaine de configuration prédéterminé, ledit domaine de configuration étant constitué de taches unitaires, comprenant au moins une alerte ou une procédure, chaque tache unitaire étant décrite par des valeurs de paramètres dans une liste prédéterminée comprenant au moins un paramètre du type, alerte, son d'alerte, phase de vol, évenement 30 déclenchant, signal aéronef, contexte, procédure, contenu d'une procédure, item ou menu ; à chaque paramètre étant associé une plage de valeurs autorisée.
3. Système de gestion d'alertes et de procédures destiné à un aéronef selon la revendication 2, caractérisé en ce que l'outil de paramétrage (11) convertit un fichier de configuration codé en langage XML et conforme au domaine de configuration en un base de données de paramètres binaires (13) apte à paramétrer chacune des cellules élémentaires (21, 22, 23, 24) du noyau logiciel (14).
4. Système de gestion d'alertes et de procédures destiné à un aéronef selon l'une des revendications 2 ou 3, caractérisé en ce que les moteurs logiciel des quatre cellules élémentaires sont validés unitairement ; la validation d'un séquencement entre les cellules étant facilité par des interfaces entre cellules de type booléennes, limitant la combinatoire de tests d'assemblage des cellules, indépendement du paramétrage.
5. Procédé de paramétrage d'un système de gestion d'alertes et de procédures destiné à un aéronef selon l'une des revendications 2 à 4, caractérisé en ce qu'il comprend une première étape de vérification du domaine de configuration d'un fichier de configuration représentatif d'un besoin opérationnel dudit système de gestion d'alertes et de procédures, et une seconde étape de conversion du fichier de configuration en une base de données de paramètres binaires apte à paramétrer un système de gestion d'alertes et de procédures générique validé pour ledit domaine de configuration.
6. Procédé de développement d'un système de gestion d'alertes et de procédures destiné à un aéronef selon l'une des revendications 2 à 4, caractérisé en ce qu'il comprend une étape de définition d'un domaine de configuration de taches à éxécuter, ledit domaine de configuration étant apte par paramétrage à couvrir un large spectre de besoins opérationnels du système de gestion d'alertes et de procédures, une étape de programmation des moteurs logiciels de chacune des cellules élémentaires, et une étape de paramétrisation de la logique d'exécution des taches de chacune des cellules élémentaires.
7. Procédé de maintenance d'un système de gestion d'alertes et de procédures destiné à un aéronef selon l'une des revendications 2 à 4, caractérisé en ce qu'il comprend une étape de conversion d'un fichier de configuration décrivant un besoin opérationnel du système de gestion d'alertes et de procédures en une base de données de paramètres binaire, et une étape de paramétrage du système de gestion d'alertes et de procédures par la base de données de paramètres binaires réalisés lors d'une opération de maintenance de l'aéronef.10