FR2990529A1 - Procede et dispositif de capture du besoin pour un systeme de maintenance centralisee pour aeronef - Google Patents

Abstract

La présente invention propose un dispositif de capture du besoin pour un système de maintenance centralisée (CMS) pour aéronef. Le dispositif est composé d'un moyen de capture et de paramétrage des différentes caractéristiques du système de maintenance centralisée. Il permet aux différents acteurs de la mise au point du système CMS de définir l'ensemble des données spécifiques à leur domaine dans un cadre commun. Des profils utilisateurs sont définis pour chacun des utilisateurs leur donnant des possibilités de configuration propres à leur domaine. Après validation des paramètres saisis, un fichier de configuration (CMS) est généré.

Description

PROCEDE ET DISPOSITIF DE CAPTURE DU BESOIN POUR UN SYSTEME DE MAINTENANCE CENTRALISEE POUR AERONEF L'invention concerne le domaine des systèmes de 5 maintenance pour aéronef et plus particulièrement un procédé et un dispositif de capture du besoin pour un tel système. La maintenance centralisée d'un aéronef a pour 10 fonction principale de faire, en temps réel ou en fin de vol, un diagnostic de la situation générale de l'aéronef à partir d'une synthèse des messages de panne reçus des différents équipements de l'aéronef. 15 La maintenance remplit également d'autres fonctions telles que la corrélation des messages de panne reçus avec les alarmes reçues au niveau du poste de pilotage, la conduite des tests particuliers sur les équipements menés à la demande par un opérateur ou 20 la confection de rapports à destination des équipes de maintenance au sol, rapports renfermant un historique des messages de panne émis par les différents équipements de l'aéronef et des alarmes présentées à l'équipage ainsi que la synthèse des messages de panne 25 faite en dernier ressort. Plus généralement, les rapports contiennent toutes les informations sur les états de fonctionnement des équipements, susceptibles de faciliter le travail de l'équipe de maintenance au sol. 30 Classiquement, de part sa fonctionnalité, le système de maintenance centralisé est connecté à plusieurs dizaines d'équipements de l'aéronef, chacun pouvant potentiellement générer des dizaines voire des centaines de messages de pannes.

Le développement et la maintenance d'un tel système est complexe et coûteux car il dépend non seulement des spécifications techniques des équipements des aéronefs mais également des habitudes 10 et procédures opérationnelles des avionneurs et exploitants. Il y a une forte adhérence de la fonction à la définition système de l'avion. La mise au point est 15 longue et complexe due au très grand nombre d'équipements connectés à traiter (plus de 100 équipements par avion) et à la diversité des protocoles. L'élongation est importante pour l'intégration système et la maturation des 20 performances de diagnostic. De plus cette mise au point nécessite l'intervention de personnels de cultures différentes, que ce soit le fournisseur d'équipement (Member 25 system), le concepteur du système de maintenance ou le concepteur de l'aéronef. La difficulté de cette multiplicité et de cette diversité est que les informations de maintenance 30 doivent être capturées et formalisées de façon non ambigüe, complète et cohérente.

Jusqu'à présent la capture des informations est réalisée pour la plus grande partie au travers des documents de spécification des systèmes de l'aéronef.

Aucun formalisme n'est appliqué pour garantir l'homogénéité, la cohérence et la complétude des informations. De plus cette phase de capture est longue, 10 itérative et complexifiée par le grand nombre d'équipements à gérer et la diversité des acteurs participant à la mise au point du système. Les défauts non détectés lors de cette phase vont 15 venir perturber et rallonger les activités d'intégration, et nécessiter de nouvelles itérations de capture pour obtenir une définition complète, juste et non ambigüe des données du système. 20 Des solutions existent qui permettent de faciliter la saisie des informations par des outils informatiques mais aucun ne propose de l'intégrer dans une solution plus large intégrant un dispositif de saisie, des mécanismes de vérification des données, et 25 implémentant un processus qui va adapter le niveau d'information partagé et définir l'ensemble des informations qui pourront être renseignées par les divers concepteurs du système de maintenance. 30 Il existe alors le besoin d'une solution globale qui permette de capturer de manière complète les besoins de maintenance d'un aéronef. La présente invention répond à ce besoin.

Un objet de la présente invention est d'offrir un dispositif et un procédé pour définir et capturer de manière itérative et complète les besoins de maintenance d'un aéronef et de valider la cohérence des données capturées par le dispositif.

Avantageusement la présente invention permet que les caractéristiques des messages de maintenance soient saisies plus rapidement et de façon non ambigüe et que la cohérence et la validité des messages de maintenance soient assurées automatiquement par la centralisation de l'ensemble des informations. Un autre objet de la présente invention est de permettre la collecte des informations par un 20 processus basé sur la gestion de profils utilisateurs sur lesquels l'utilisateur a la maîtrise. Avantageusement, le partage des informations entre les différents utilisateurs impliqués dans la 25 mise au point du système de maintenance centralisé (CMS) est garanti. Avantageusement, la présente invention garantit la complétude et l'exactitude de la capture du besoin 30 pour la maintenance centralisée d'un aéronef.

Un autre objet de la présente invention est de fournir un système adapté à l'utilisateur, qu'il soit équipementier ou intégrateur avion.

Avantageusement, la présente invention offre une interface homme-machine (IHM) de saisie qui permet une prévisualisation du contenu des pages IHM du système. Avantageusement, la présente invention assure la 10 production de bases de données de configuration exploitables par le système de maintenance centralisée. Avantageusement, la présente invention s'applique 15 de manière dynamique à tout nouvel environnement de CMS. Avantageusement, la présente invention s' implémentera dans le contexte de l'industrie 20 aéronautique. Pour obtenir les résultats recherchés, un dispositif, un procédé et un produit programme d'ordinateur sont proposés. 25 En particulier, un dispositif de capture de be- soin pour un système de maintenance centralisée (CMS) pour aéronef comprend : 30 un module de saisie de paramètres relatifs à des domaines de configuration du CMS ; un module de vérification couplé au module de saisie pour vérifier la conformité des paramètres saisis aux domaines de configurations du CMS ; un module de génération couplé au module de saisie pour générer des fichiers de capture du be- soin; et un module de stockage pour stocker les fichiers de capture du besoin générés. Différentes variantes d'implémentations sont décrites. 15 Différents aspects et avantages de l'invention vont apparaitre en appui de la description d'un mode préféré d'implémentation de l'invention mais non limitatif, avec référence aux figures ci-dessous : 20 La Figure 1 montre les briques fonctionnelles d'un dispositif pour capture du besoin d'un CMS selon les principes de l'invention ; La figure 2 montre les étapes opérées par la méthode 25 de l'invention pour générer un fichier de configuration CMS. La figure 1 illustre un environnement informa 30 tique (100) permettant d'implémenter le 10 dispositif et d'opérer le procédé de l'invention pour capturer le besoin d'un système de maintenance centralisée ou CMS. La figure 1 montre un exemple des modules fonctionnels dans une implémentation préférentielle de l'invention, sans être limitatif et permettant à l'homme du métier d'implémenter des variantes. Le système 100 est composé d'un dispositif de saisie 101 apte à recueillir des données pour capturer 10 le besoin d'un CMS. Le système comprend un module de stockage 106 pour stocker les données relatives à la définition des domaines de configuration du CMS ou « Domaine Specific Language CMS» (DSL CMS) 107 et une base de données 15 108 des fichiers de capture du besoin 112. Le DSL CMS 107 exprime de manière formelle les différents domaines CMS, leurs éléments de configuration et la description des items de 20 configuration. Le dispositif comprend avantageusement un module de vérification 104 dont le rôle est de vérifier que l'ensemble des paramètres 102 saisis est conforme au 25 DSL CMS 107, en termes de structure, de domaine de variation et de cohérence des valeurs. Un module 105 de génération d'un fichier de capture de besoin 112 est couplé au module de 30 vérification 104. Le contenu et la structure du fichier 112 sont garantis conformes à la saisie et au DSL CMS 107. Un medium d'interaction 110 permet à l'utilisateur 109 de saisir les paramètres 102. Le medium d'interaction 110 peut être par exemple un clavier d'ordinateur, un système de reconnaissance vocal, un écran tactile, ou tout autre medium d'interaction transformant une action de l'utilisateur en commande du dispositif de saisie 101. Une interface homme-machine (IHM) 103 permet à un utilisateur 109 de modifier des paramètres 102 du CMS conformément au DSL CMS 107, et/ou de consulter et modifier une capture de besoin préalablement établie. Un medium d'affichage 111 permet à l'utilisateur 109 d'appréhender la valeur et la structure des paramètres 102 et d'avoir connaissance des informations préalablement saisies. Le medium d'affichage 111 peut être par exemple un écran d'ordinateur, une tablette graphique, un dispositif tactile ou audio, ou tout autre medium permettant à l'utilisateur de connaître le contenu de la base de données 108. Le module de stockage 106 peut être une mémoire intégrée à un ordinateur 100, mais dans une variante d'implémentation elle peut être externalisée. Cette 25 mémoire permet le stockage de la définition du domaine de configuration 107 et de la base de données 108. La mémoire 106 peut être réalisée par exemple par un disque dur, une mémoire FLASH, un stockage USB, un CD-ROM, etc. Le DSL CMS 107 et la base de données 108 30 peuvent également être stockés dans des mémoires différentes. L'ordinateur 100 et la mémoire 106 communiquent pour permettre les échanges de données entre le module de saisie 101 et la mémoire. La connexion entre ordinateur et mémoire peut être filaire (e. g. par bus électronique, câble USB, câble Ethernet, etc.) ou sans fil (e. g. Wifi, Bluetooth, etc.). Les domaines de configurations DSL CMS sont avantageusement répartis en 6 familles : - Member Systems : Définition des informations caractérisant les Member Systems connectés au système CMS - Interfaces systèmes : Définition des liens entre le système CMS et tous les Member Systems connectés ainsi que les interfaces avec les systèmes fournissant les données d'état de l'aéronef - Filtrage/Corrélation : Définition des règles associées aux fonctions de filtrage et de corrélation - IHM : Définition des pages IHMs du système CMS et de ses member Systems et de la navigation entre les pages. - Interaction member Systems : Définition des possibilités de dialogue entre l'opérateur de maintenance et les member Systems. - Logiques CMS : Définition des logiques propres à la fonction CMS, permettant d'adapter le système aux spécificités de l'aéronef dans lequel il est embarqué. La définition des données de chaque domaine de configuration est basée : sur un ensemble de guides d'élaboration qui est un ensemble de règles permettant de définir la nature et les contraintes associées chacune des données. Ces guides permettent à l'utilisateur de mieux percevoir le besoin de capture et d'améliorer la justesse et la cohérence des informations qu'il va renseigner ; et sur un langage formel, spécifique au domaine de maintenance. L'utilisation du formalisme va assurer l'homogénéité des informations renseignées par tous les utilisateurs. Le tableau suivant fournit un exemple préférentiel des définitions des six domaines de configuration. Ce tableau et son contenu sont donnés uniquement à titre d'exemple et non comme étant limitatif. Domaine de Elément de con- figuration Description des items de configuration configuration Member Systems Topologie aéro- - Identification non ambigüe des tous les Member Systems connectés au CMS nef - Définition du code ATA associé - Identifications des systèmes d'alimentation électriques connectés aux member systems 20 Domaine de Elément de con- figuration Description des items de configuration configuration Caractéristiques intrinsèques Pour chaque member System : - identification de ses ca- ractéristiques en termes de protocole de communication : A624 A664, A624 A429, A604 BOFR, A604 StdA, or Type 3 - identification de ses élé- ments constitutifs (LRUs) : identifiants, noms, codes ATA associés Messages de - Définition des caractéristiques des messages de pannes propres à chaque Member system (voir détail dans tableau suivant) pannes - Définition de l'effet cockpit associé (FDE) : code et des- cription - Texte descriptif pour aider l'opérateur à comprendre la panne Interfaces Topologie aéro- - Liste de liens existants entre tous les équipements con-nectés à la CMS ou aux member systems nef Interfaces - Description fonctionnelle des interfaces - Définition des ports de communication et des adresses IP CMS logics CMS logics - Logiques de calculs propres au domaine de maintenance - Activation des logiques selon les caractéristiques de l'aéronef ACARS triggers - Définition des évènements déclencheurs de la transmission d'information de l'aéronef vers une base au sol logics Domaine de Elément de con- Description des items de configuration configuration figuration Filtrage et Filtrage des - Règles de filtrage appliquées sur les messages de pannes particuliers ou sur tous les mes-sages de pannes d'un member Corrélation messages de system, soit en temps réel, au pannes moment de leur apparition soit en temps différé pour réaliser du post traitement Filtrage des - Règles de filtrage appli- messages CAS quées sur les messages CAS, soit en temps réel, au moment de leur apparition soit en temps différé pour réaliser du post traitement Corrélation - Règles statiques permettant de réaliser une corrélation entre des messages de panes et des messages CAS - Règles de corrélation dyna- miques : - Temporelles entre des messages CAS et des messages de panne - Temporelles entre des messages de panne IHM Description - Description des pages IHM du système de maintenance & Navigation - Description des pages IHMs liées à chaque member system - Définition de la navigation entre les pages de l'IHM Option des rapports - Choix des options d'affichage des rapports de pannes présentés à l'opérateur Interactions Interactions - Définition des actions per-mettant à l'opérateur d'interagir avec les member Systems / member sys- tems Le tableau suivant illustre des exemples d'items configurables relatifs aux messages de pannes selon 5 leur type.

Type de message Caractéristiques configurables Discret - Nom du discret (cohérent des interfaces définies pour l'aéronef) - Type : Soit relatif à l'apparition d'une panne, soit relatif à une réponse d'un équipement dans le cadre d'un test de- mandé par l'opérateur - Valeur attendue : Valeur binaire corres- pondant au type d'évènement défini - Temps de confirmation nécessaire avant de déclarer la valeur attendue comme apparue BOFR - Filtrage : S'il est actif, le message sera filtré lorsque l'opérateur réalise un test sur l'équipement - Caractéristiques du label portant le message (Numéro/Masque/Valeur) A604 StdA - Type : caractérise la catégorie du mes- sage parmi plusieurs possibles : Flight Deck Effect reported/no Flight Deck Ef- fect reported/Classl, Class2,/Class3 A624 - Mode de panne : information sur le sta- tut de panne, indiquant si l'origine est liée à un redémarrage du système et ses conditions de redémarrage (Automatique, Manuel, Interne, Externe...) - Classe de la panne ; Permet de catégori- ser une panne selon sa gravité en termes d'effect cockpit visible - Origine de la panne : Identification de une à trois origines les plus probables de la panne. Elles permettront de guider l'opérateur lorsqu'il devra établir un diagnostic global. Le dispositif 100 de capture du besoin est conçu pour générer un fichier de configuration CMS 112 à 5 partir d'un ensemble de données 102 préalablement saisis par les différents contributeurs 109. Avantageusement, les utilisateurs 109 sont le fournisseur de Member System, le concepteur aéronef et 10 le concepteur du système de maintenance. Des profils utilisateurs spécifiques à chaque utilisateur sont définis dans leur rôle, leurs activités dans le développement du système. 15 Avantageusement, la gestion de profils utilisa- teurs permet : de garantir l'homogénéité et la complétude des informations nécessaires à la description du système 20 - de faciliter le travail de chaque contributeur en lui fournissant une IHM adaptée à son besoin et en le guidant, en lui fournissant des directives à chaque étape de la saisie, et en lui fournissant pour chacun des paramètres une plage 25 d'utilisation autorisée de permettre le partage des informations en les centralisant dans un même outil, partagé par les utilisateurs.

Le fichier de configuration CMS généré 112 décrit l'ensemble des données de maintenance. Sa structure et sa syntaxe répondent à un langage descriptif formel (DSL) qui permet d'assurer le caractère complet et non ambigu des informations collectées. Son contenu porte 10 l'ensemble des concepts du domaine de maintenance nécessaires à la réalisation du système CMS. Avantageusement, Ce fichier pourra être implémenté sous forme textuel balisé, programmé en utilisant un langage haut niveau de type XML (eXtended Mark-Up Langage). 15 Le rôle du module 104 de vérification est de vérifier la cohérence et la conformité de l'ensemble des saisies de l'opérateur, en regard du DSL CMS 107, ainsi que la complétude et la non-contradiction des sai- 20 sies. L'interface de saisie (IHM) comprend avantageusement différents champs pour saisir les paramètres du CMS conformément à un domaine de 25 configuration et être guidé dans cette saisie. L'interface permet aussi à un utilisateur de consulter et éditer une configuration prédéfinie. La Figure 2 montre les étapes 200 opérées par la 30 méthode de l'invention pour générer un fichier de configuration CMS dans une implémentation préférentielle, telle que sur un dispositif 100. Différents acteurs sont identifiés pour réaliser la capture des données, un concepteur aéronef, un concepteur du système de maintenance et un fournisseur 5 de member system. Dans une première étape 201, le procédé permet au concepteur de l'aéronef de définir la topologie aéronef qui est utilisée pour la capture des autres informations nécessaires à la maintenance centralisée. 10 Après cette étape, la capture des différentes informations peut être réalisée en parallèle (étapes 210 à 215). Les différents fournisseurs de member system définissent les messages de pannes 210 de leur 15 système. Une étape de validation 220 pour chacun des member system est réalisée. Après validation, des règles de filtrage sont définies à l'étape 230 et des règles de corrélation sont définies à l'étape 240. A l'étape 211 les interfaces entre chaque member 20 system et la maintenance centralisée sont décrites. Ces interfaces sont définies de manière préférentielle par le concepteur du système de maintenance. A l'étape 212, les pages IHM du member system sont définies. Ces pages sont définies de manière 25 préférentielle par le fournisseur de member system. A l'étape 213, les différentes interactions entre la maintenance centralisée et le member system sont définies, permettant à l'opérateur de maintenance d'interagir avec le système.

A l'étape 214, l'IHM de la CMS est définie de manière préférentielle par le concepteur de l'aéronef. A l'étape 215, les logiques CMS sont définies de manière préférentielle par le concepteur de l'aéronef.

L'étape suivante 250 consiste à configurer les évènements déclencheurs de transmission de l'information de maintenance au sol. A la fin des étapes 240, 211, 212, 213, 214 et 250, une étape de validation 260 est réalisée.

Quand la validation est correcte, un fichier de configuration CMS est généré à l'étape 270. En résumé, les avantages majeurs de la présente invention sont : - Un élargissement de l'aspect configuration des équipements connectés avec le système de maintenance, par : - la gestion d'équipements de nature différente ; - une prise en charge de divers protocoles de communication. - Une notion de processus qui est élargie par : - la définition d'acteurs et de rôles spécifiques au domaine et détaillés pour la maintenance (Concepteur de l'aéronef/ Fournisseur de member systems/ Concepteur du système de maintenance) ; - la définition d'un cadre de travail collaboratif entre tous les acteurs au sein d'un atelier commun, cadre qui : - identifie les prérequis entre les phases ; - permet de paralléliser un certain nombre d'activités et assure l'indépendance des acteurs ; - définit des points de rencontres nécessaires pour la poursuite des activités de capture un diagramme de séquences du processus de capture, enrichi avec les liens vers les acteurs ; l'ajout de notion de centralisation de toutes les données nécessaires à la conception d'un système CMS qui permet : aux fournisseurs de Member systems de valider plus rapidement leur équipement dans la suite avionique ; de vérifier la complétude des informations relayées par tous les équipements par rapport à la topologie de l'avion pour identifier au plus tôt les manques, les incohérences ou les redondances ; - La configurabilité des logiques de calcul de la fonction maintenance par la définition des paramètres 25 intervenant dans les algorithmes de calcul des phases de maintenance et commandes ; - L'ajout de la configuration des évènements déclencheurs de transmission de l'information de 30 maintenance au sol, pour permettre à l'opérateur de maintenance de préparer ses procédures de maintenance sans attendre l'atterrissage de l'avion ; - La configuration des fonctions de filtrage et de corrélation qui : - permet d'éviter le reporting de pannes en cascades qui rendent ensuite une investigation difficile ; - privilégie l'identification des pannes primaires en éliminant les pannes secondaires, 10 résultantes des effets des premières ; Une modélisation des actions interactives, de dialogue de l'opérateur vers les équipements qui : - s'appuie sur un langage formel 15 spécifique ; - prend en charge trois types d'actions personnalisables (tests interactifs pour confirmation de panne, récupération de données enregistrées d'un 20 système, récupération et présentation des données courantes d'un système) ; - permet à chaque fournisseur d'équipement de personnaliser son IHM dans la structure et la navigation.

25 Ainsi la présente description illustre une implémentation préférentielle de l'invention, mais n'est pas limitative. Un exemple a été choisi pour permettre une bonne compréhension des principes de 30 l'invention, et une application concrète, mais il 2 99052 9 20 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 être électronique, magnétique, optique, électromagnétique ou être un support de diffusion de type infrarouge. De tels supports sont par exemple, des mémoires à semi-conducteur (Random Access Memory RAM, Read-Only Memory ROM), des bandes, des disquettes ou disques magnétiques ou optiques (Compact 15 Disk - Read Only Memory (CD-ROM), Compact Disk - Read/Write (CD-R/W) and DVD).

Claims (9)

1. REVENDICATIONS1. Un dispositif de capture de besoin pour un système de maintenance centralisé (CMS) pour aéronef, le dispositif comprenant : - un module de saisie de paramètres relatifs à des domaines de configuration du CMS ; - un module de vérification couplé au module de saisie pour vérifier la conformité des paramètres saisis aux domaines de configurations du CMS ; un module de génération couplé au module de saisie pour générer des fichiers de capture du besoin; et - un module de stockage pour stocker les fichiers de capture du besoin générés.
2. 2. Le dispositif selon la revendication 1 comprenant en outre un module de définition des domaines de configuration.
3. 3. Le dispositif selon la revendication 1 ou 2 comprenant en outre un module de gestion de profils utilisateurs couplé au module de saisie.
4. 4. Le dispositif selon l'une quelconque des revendications 1 à 3 où le module de saisie comprend en outre une Interface Homme-Machine.
5. 5. Le dispositif selon l'une quelconque des revendications 1 à 4 où le module de saisie comprend en outre des moyens d'interaction avec un utilisateur.
6. 6. Le dispositif selon l'une quelconque des revendications 1 à 5 où le module de stockage 106 comprend un premier module 107 pour stocker les données relatives à la définition des domaine de configuration et un second module 108 pour stocker les fichiers de capture du besoin générés.
7. 7. Le dispositif selon l'une quelconque des revendications 1 à 6 comprenant six domaines de configuration pour définir : - des informations caractérisant les Member Systems connectés au système CMS ; - des liens entre le système CMS et tous les Member Systems connectés et les interfaces avec les systèmes fournissant les données d'état de l'aéronef ; - des règles associées aux fonctions de filtrage et de corrélation ; - des pages IHMs du système CMS et de ses Member Systems et de la navigation entre les pages ; - des possibilités de dialogue entre l'opérateur de maintenance et les Member Systems ; et - des logiques propres à la fonction CMS.
8. 8. Un procédé exécuté sur un ordinateur pour capturer le besoin pour un système de maintenance centralisée (CMS) pour aéronef, comprenant les étapes de : - définir des domaines de configuration du CMS ; - définir des profils utilisateurs pour chaque domaine de configuration définis ; saisir selon les profils utilisateurs des paramètres relatifs aux domaines de configuration du CMS ; vérifier pour chaque profil utilisateur la conformité des paramètres saisis aux domaines de configurations du CMS ; et - générer un fichier de configuration de maintenance centralisée (CMS) en réponse à l'étape de vérification.
9. 9. Un produit programme d'ordinateur, ledit programme d'ordinateur comprenant des instructions de code permettant d'effectuer les étapes du pro- cédé selon la revendication 8, lorsque ledit programme est exécuté sur un ordinateur.