FR2963447A1 - Procede et dispositif de test d’interfaces d’entree/sortie de modules avioniques de type ima - Google Patents

Abstract

L'invention vise notamment le test d'interfaces d'entrée/sortie de modules avioniques de type IMA dans un dispositif comprenant plusieurs modules, un système comprenant au moins une application étant mis en œuvre par un ensemble de modules informatiques. Cet ensemble comprend ledit module informatique, appelé premier module, et au moins un autre module informatique, appelé au moins un second module. Un test système est associé audit au moins un système pour tester fonctionnellement ledit ensemble de modules informatiques selon ledit système. Ledit au moins un test système comprend au moins un test système élémentaire pour tester fonctionnellement ladite au moins une interface d'entrée/sortie dudit premier module. L'exécution dudit au moins un test système élémentaire est indépendante dudit au moins un second module. Au moins un résultat d'exécution dudit au moins un test système élémentaire est transmis à un ordinateur de maintenance distinct des modules informatiques de ladite pluralité de modules informatiques.

Description

La présente invention concerne la maintenance de modules électroniques et plus particulièrement un procédé et un dispositif de test d'interfaces d'entrée/sortie de modules avioniques de type IMA, notamment lors de leur remplacement. Les systèmes avioniques tels que les systèmes de gestion de carburant et d'atterrissage des aéronefs d'anciennes générations utilisaient leurs propres calculateurs, périphériques, câblage, interfaces d'entrée/sortie, capteurs et actionneurs. A l'inverse, les aéronefs de nouvelles générations utilisent une architecture appelée IMA (sigle d'Integrated Modular Avionic en terminologie anglo-saxonne) selon laquelle les parties matérielles et logicielles ont été distinguées, permettant à plusieurs systèmes avioniques de partager des mêmes éléments matériels. Cette évolution a permis de réduire le nombre d'éléments matériels distincts dans un aéronef et, par conséquent, les coûts de développement et de qualification. A ces fins, de nouveaux équipements ont été développés sous forme de modules, notamment les CPIOM (sigle de Core Processing Input Output Module en terminologie anglo-saxonne) et les 10M (sigle de Input Output Module en terminologie anglo-saxonne). Les 10M comprennent essentiellement des interfaces d'entrée/sortie tandis que les CPIOM comprennent en outre des capacités de traitement, c'est-à-dire d'exécution de composants logiciels. Une telle architecture supporte l'exécution d'applications de plusieurs systèmes indépendants. Les modules IMA fournissent également des services pour les applications hébergées tels que la gestion de données non volatiles, le téléchargement et la mise à jour d'applications logicielles, des fonctions de test appelées BITE (acronyme de Built-In Test Equipment en terminologie anglo-saxonne), le routage d'interfaces d'entrée/sortie et la conversion d'entrées/sorties.

La figure 1 illustre un exemple d'architecture de type IMA et d'équipements connexes mis en oeuvre dans une solution avionique moderne. L'avionique 100 est ici basée sur quatre modules CPIOM 105-1 à 105-4 et un module 10M 110. Ces modules sont interconnectés par des liens de communication de type AFDX (sigle d'Avionic Full-DupleX ethernet switched en terminologie anglo-saxonne) via des commutateurs génériquement référencés 115. Chaque module CPIOM permet de mettre en oeuvre des applications d'un ou plusieurs systèmes avioniques pouvant être identifiés par sa référence ATA (l'ATA, sigle d'Air Transport Association, est un organisme international de normalisation ayant établi une classification par chapitres ATA utilisés pour identifier des parties fonctionnelles d'un aéronef de façon standardisée). L'avionique 100 comprend en outre, ici, un module spécialisé 120 de type LRU (sigle de Line Replaceable Unit en terminologie anglo-saxonne).

A titre d'illustration, les modules 105-1, 105-2 et 120 sont connectés à des capteurs, génériquement référencés 125, et à des actuateurs, génériquement référencés 130. Les liens de communication entre les modules IMA et les capteurs et les actuateurs sont, par exemple, des liens discrets, analogiques ou de type CAN (sigle de ControllerArea Network en terminologie anglo-saxonne). Des concentrateurs, génériquement référencés 135, aussi appelés RDC (sigle de Remote Data Concentrator en terminologie anglo-saxonne), peuvent être utilisés pour connecter des modules IMA et des capteurs. De même, des unités électroniques contrôlées, génériquement référencées 140, aussi appelées REU (sigle de Remote Electronic Unit en terminologie anglo-saxonne), peuvent être utilisés pour connecter des modules IMA et des actuateurs. Les liens de communication entre des modules IMA et des unités de type RDC et/ou REU peuvent être conformes à la norme ARINC 429 (ARINC est une marque). Typiquement, les 10M sont des ressources IMA en charge des conversions nécessaires pour des échanges de données entre des applications qui utilisent un réseau de type AFDX et d'autres équipements qui ne sont pas compatibles avec ce standard, par exemple des équipements utilisant le standard ARINC 429, des capteurs et/ou des actionneurs. La figure 2 illustre un exemple d'architecture d'un 10M. Les 10M n'hébergent généralement pas de composant logiciel fonctionnel, ils permettent seulement de faire des conversions.

Comme représenté, l'IOM 200 comprend une interface d'entrée/sortie AFDX 205, une fonction de conversion 210 et des interfaces d'entrée/sortie spécifiques, par exemple une interface d'entrée/sortie 215 de type CAN, une interface d'entrée/sortie 220 de type analogique, une interface d'entrée/sortie 225 de type discret et une interface d'entrée/sortie 230 de type ARINC 429. L'IOM 200 peut en outre comprendre une fonction de contrôle 235 pouvant intégrer une fonction BITE. La figure 3 illustre un CPIOM 300 comprenant ici une carte 305 de calcul connectée à une carte 310 de communication AFDX, une carte 315 d'alimentation et d'interfaces d'entrée/sortie et deux cartes 315-1 et 315-2 d'interfaces d'entrée/sortie. Ces cartes sont ici reliées les unes aux autres via une interface PCI 325 (sigle de Peripheral Component Interconnect en terminologie anglo-saxonne). Ce module peut échanger des données avec des modules et/ou des équipements extérieurs via l'interface 330 comprenant ici une interface AFDX, une interface conforme au standard ARINC 429, une interface analogique, une interface discrète et une interface de type CAN. Le CPIOM 300 comprend en outre une fonction BITE 335. II est observé ici que si la fonction BITE permet de conduire des tests du module lui-même, elle permet également de tester un système mis en oeuvre au moins partiellement par ce module. La fonctionnalité BITE est généralement réalisée par des composants matériels et logiciels des modules. Les interfaces d'entrée/sortie d'un module sont typiquement pilotées, selon leur nature, par des composants logiciels hébergés sur le module lui-même, notamment en ce qui concerne les CPIOM ou sur un autre calculateur, en particulier en ce qui concerne les 10M. Chaque module possède en général un ensemble de tests interactifs, visant distinctement le module et son interface, permettant à un opérateur de maintenance de contrôler le module durant une opération de maintenance à l'aide d'une fonction BITE qui permet de tester un équipement lorsqu'il est en fonction. Les possibles défaillances et le processus de détection de celles-ci sont distribués aussi bien au niveau applicatif que sur la plateforme qui héberge les applications. Ainsi, à titre d'illustration, la fonction BITE peut être découpée en sous-fonctions, notamment système (System BITE ou SB), application (Application BITE ou AB) et ressources (Resource BITE, RB ou RBITE). Concernant le RB, l'activité de surveillance est typiquement réalisée par des fonctions exécutées en permanence par le système d'exploitation utilisé par le module et ses pilotes (appelés drivers en terminologie anglo-saxonne). Quand une défaillance est détectée, le RB est averti. Il filtre alors la défaillance détectée et, le cas échéant, transmet un message à un ordinateur central de gestion de messages de maintenance, appelé CMS (sigle de Centralized Maintenance System en terminologie anglo-saxonne). Il y a généralement un RB par module. L'AB et le SB traitent les conséquences fonctionnelles et opérationnelles des pannes ou des défaillances détectées. L'AB est en charge de la surveillance des parties fonctionnelles et opérationnelles des partitions, une partition d'un ou de plusieurs modules étant typiquement allouée à un système avionique. Il y a un AB par partition qui reporte au SB. Le SB permet de récupérer les informations provenant des différents AB d'un même système et, le cas échéant, de les transmettre au CMS. Des tests système (system test) et des tests application (application test) sont associés au SB et à l'AB, respectivement.

Souvent, ces fonctionnalités ne sont pas sous la responsabilité de la ressource (ATA 42) mais des applications avioniques (ATA XX) hébergées par la ressource. Par conséquent, les opérateurs de maintenance ne sont pas les mêmes, un opérateur de maintenance d'un ATA donné ne pouvant intervenir sur un autre ATA.

Le RB comprend généralement, en particulier, un mode interactif permettant à un opérateur de maintenance d'effectuer des tests lorsque l'aéronef est au sol. Dans ce mode, un opérateur de maintenance (ATA 42) peut effectuer un test du module (module test) pour vérifier son bon fonctionnement, en particulier les bus numériques connectés au calculateur. Le but de ce test est de vérifier l'intégrité matérielle du module, c'est-à-dire de détecter les erreurs internes.

Ce mode permet également à un opérateur d'effectuer des tests logiques d'interfaces du module (module interface test) afin de contrôler des interfaces d'entrée/sortie prévues pour être testées grâce, par exemple, à un mécanisme de réaction (couramment appelé mécanisme de feedback). Cependant, de nombreuses interfaces d'entrée/sortie ne peuvent pas être testées pour des raisons de sécurité (certaines interfaces d'entrée/sortie ne peuvent être activées ou désactivées sans risque pour l'aéronef ou du personnel au sol, par exemple des vannes de carburant ou des commandes moteur) ou parcequ'elles ne sont pas pourvues d'un mécanisme de réaction. En effet, la ressource ATA 42, c'est-à-dire la ressource informatique qui est utilisée par les autres systèmes et applications avioniques (ATA XX) ne doit pas émettre de stimuli sur des interfaces d'entrée/sortie alors qu'elle ne connaît pas les équipements auxquels elles sont interfacées. Si un opérateur souhaite s'assurer du bon fonctionnement de toutes les interfaces d'entrée/sortie, il doit effectuer les tests système (System tests) relatifs aux applications avioniques concernées (ATA XX). De tels tests doivent être effectués par des opérateurs de maintenance habilités (généralement différents des opérateurs ATA 42). Il est observé ici que pour chaque application système hébergée par un module IMA, il existe potentiellement un ensemble d'interfaces d'entrée/sortie critiques dont la non disponibilité peut avoir des conséquences sur la sécurité de fonctionnement de l'aéronef. Or, lors d'une opération de maintenance visant à remplacer un module IMA dans un aéronef, une broche d'un des connecteurs de celui-ci peut se casser et cette broche peut faire partie de la liste des interfaces d'entrée/sortie jugées critiques par une des applications système hébergées par le module mais pas nécessairement par l'application système qui était la cause de la défaillance qui a été à l'origine du remplacement de l'équipement.

Comme décrit précédemment, les tests interactifs d'un module, exécutés par une procédure d'installation lors de sa mise en place, ne couvrent pas l'ensemble de ses interfaces d'entrée/sortie. Il est donc possible que le module remplacé soit considéré comme étant opérationnel malgré une broche cassée. Ainsi, lorsqu'un module est remplacé suite à la détection d'une défaillance, les tests effectués via l'interface du RB devraient être complétés par des tests système réalisés au niveau des applications système pour vérifier toutes les interfaces d'entrée/sortie. Ces tests système sont des tests conçus pour et par les applications avioniques qui utilisent le module (ATA 42) afin de tester le système dans sa globalité. Cependant, le temps d'exécution des tests système est généralement de plusieurs minutes. Ainsi, pour des raisons de respect de disponibilité de l'aéronef, seul le test système associé à la source de la défaillance est généralement exécuté. Il n'y a donc souvent pas de vérification des autres interfaces utilisées par d'autres systèmes utilisant le module IMA remplacé car il n'est généralement pas possible d'effectuer tous les tests système de tous les systèmes avioniques qui utilisent le module remplacé (ceci nécessiterait plusieurs heures et souvent la maintenance ne dispose que d'un temps limité appelé TAT, acronyme de Turn Around Time en terminologie anglo-saxonne, pour effectuer le remplacement d'un élément). L'invention permet de résoudre au moins un des problèmes exposés précédemment. L'invention a ainsi pour objet un procédé de test d'au moins une interface d'entrée/sortie d'un module informatique de type IMA comprenant une pluralité d'interfaces d'entrée/sortie dans un dispositif comprenant une pluralité de modules informatiques de type IMA, au moins un système comprenant au moins une application étant mis en oeuvre par un ensemble de modules informatiques de ladite pluralité de modules informatiques, ledit ensemble comprenant ledit module informatique, appelé premier module, et au moins un autre module informatique, appelé au moins un second module, au moins un test système étant associé audit au moins un système pour tester fonctionnellement ledit ensemble de modules informatiques selon ledit système, ledit au moins un test système comprenant au moins un test système élémentaire pour tester fonctionnellement ladite au moins une interface d'entrée/sortie dudit premier module, le procédé comprenant une étape d'exécution dudit au moins un test système élémentaire, ladite étape d'exécution dudit au moins un test système élémentaire étant indépendante dudit au moins un second module, et une étape de transmission d'au moins un résultat d'exécution dudit au moins un test système élémentaire à un ordinateur de maintenance distinct des modules informatiques de ladite pluralité de modules informatiques.

Le procédé selon l'invention permet ainsi de tester une interface d'entrée/sortie d'un module selon un système partiellement mis en oeuvre par ce module, sans tester les autres modules utilisés par ce système, afin de cibler les tests et, par conséquent, limiter le temps nécessaire à l'exécution de tests liés à des systèmes hébergés par des ensembles de modules. Une application particulièrement avantageuse de l'invention vise le test d'un calculateur, dans un aéronef, suite au changement de ce calculateur, pour limiter son temps d'installation. Le procédé selon l'invention contribue ainsi à la réduction du temps d'immobilisation d'un aéronef au sol ainsi qu'à la simplification des tâches des opérateurs de maintenance.

Selon un mode de réalisation particulier, le procédé comprend en outre une étape d'exécution d'au moins un second test système élémentaire, distinct dudit au moins un test système élémentaire, appelé premier test système élémentaire, ledit au moins un second test système élémentaire permettant de tester au moins une seconde interface d'entrée/sortie dudit premier module, distincte de ladite au moins une interface d'entrée/sortie, appelée au moins une première interface, ledit au moins un second test système élémentaire appartenant à un second test système, distinct dudit au moins un test système, appelé au moins un premier test système, ledit second test système étant associé à un second système comprenant au moins une application, distinct dudit au moins un système, appelé au moins une premier système, ledit second système étant mis en oeuvre par un second ensemble de modules informatiques, distinct dudit ensemble de modules informatiques, appelé premier ensemble, comprenant au moins ledit premier module et au moins un autre module informatique de ladite pluralité de modules informatiques, ledit second test système permettant de tester fonctionnellement ledit second ensemble de modules informatiques selon ledit second système, ladite étape d'exécution dudit au moins un second test système élémentaire étant indépendante dudit au moins un autre module informatique dudit second ensemble, et une étape de transmission d'au moins un résultat d'exécution dudit second test système élémentaire audit ordinateur de maintenance. Le procédé selon l'invention permet ainsi de tester l'intégrité d'un module selon les systèmes hébergés par ce module, sans tester ces systèmes en eux-mêmes, c'est-à-dire sans tester les parties de ces systèmes hébergés par d'autres modules. De façon avantageuse, ladite étape d'exécution dudit au moins un second test système élémentaire est appelée suite à l'exécution dudit premier test système élémentaire. Il est ainsi possible d'enchaîner un ensemble de tests système élémentaires afin de tester automatiquement un module hébergeant plusieurs parties de systèmes différents. Le procédé comprend en outre, de préférence, une étape de test logique d'interface d'au moins une interface d'entrée/sortie dudit module informatique, ladite étape d'exécution dudit au moins un test système élémentaire étant appelée par ladite étape de test logique. Il est ainsi possible, pour tester des interfaces d'entrée/sortie de modules, de combiner des tests logiques couramment mis en oeuvre avec des tests système élémentaires conformément à l'invention afin d'accroître la surface de test des modules testés. De façon avantageuse, le procédé comprend en outre, de préférence, une étape d'autorisation d'exécution dudit test système élémentaire selon ledit au moins un système, ledit test système élémentaire étant exécuté en réponse à ladite étape d'autorisation. Il est ainsi vérifié qu'un test système élémentaire peut être effectué conformément aux conditions liées au système associé.

Ledit test système élémentaire est, de préférence, exécuté dans un environnement propre audit au moins un système afin que le test système élémentaire soit exécuté dans un environnement aussi proche que possible de celui dans lequel sont exécutées les applications du système.

Selon un mode de réalisation particulier, le procédé comprend en outre une étape d'initialisation dudit test système élémentaire, ladite étape d'initialisation étant exécutée en réponse à une commande d'un opérateur saisie via ledit ordinateur de maintenance. Une telle étape d'initialisation permet, par exemple, de placer le module testé en mode interactif.

Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de vérification d'au moins une condition initiale, ladite étape d'exécution dudit au moins un test système élémentaire étant exécutée en réponse à ladite étape de vérification d'au moins une condition initiale. Il est ainsi possible de vérifier que des conditions sont vérifiées avant de lancer des tests système élémentaires. Le procédé selon l'invention peut ainsi être mis en oeuvre sans danger pour l'aéronef et les personnes situées à l'intérieur ou à proximité de celui-ci. De façon avantageuse, le procédé comprend en outre une étape préliminaire de décomposition dudit test système en une pluralité de tests élémentaires, ladite pluralité de tests élémentaires comprenant ledit au moins un test système élémentaire. Ainsi, les tests système élémentaires dérivant des tests système, leur développement est limité. L'invention a également pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé décrit précédemment lorsque ledit programme est exécuté sur un ordinateur, un dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé décrit précédemment ainsi qu'un aéronef comprenant ce dispositif. Les avantages procurés par ce programme d'ordinateur, ce dispositif 30 et cet aéronef sont similaires à ceux évoqués précédemment.

D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, au regard des dessins annexés dans lesquels : - la figure 1 illustre un exemple d'architecture de type IMA et d'équipements connexes mis en oeuvre dans une solution avionique moderne ; - les figures 2 et 3 illustrent un exemple d'architecture d'un 10M et d'un CPIOM, respectivement ; - la figure 4, comprenant les figures 4a et 4b, illustre le périmètre de couverture de tests d'interfaces d'entrée/sortie dans quatre modules mettant en oeuvre quatre systèmes avioniques lorsqu'un module interface test et des tests système sont exécutés et lorsqu'un module interface test et des tests système élémentaires sont exécutés, respectivement ; - les figures 5 à 8 illustrent quatre modes de réalisation de tests d'interfaces entrée/sortie d'un module de type IMA conformément à l'invention ; - la figure 9 illustre un exemple de diagramme de séquence lors de l'exécution d'un test système élémentaire nécessitant la vérification de conditions initiales, conformément au quatrième mode de réalisation décrit en référence à la figure 8 ; et, - la figure 10 illustre un exemple d'architecture matérielle adaptée à 20 mettre en oeuvre certaines étapes de l'invention. L'invention vise le test d'un module de type IMA comprenant des interfaces d'entrée/sortie utilisées par plusieurs applications, certaines interfaces d'entrée/sortie étant considérées comme critiques vis-à-vis de la sécurité de fonctionnement du dispositif comprenant ce module, typiquement un 25 aéronef, en particulier après que le module ait été remplacé. A ces fins, l'invention met en oeuvre des tests système dont l'exécution est limitée dans le temps tout en respectant des contraintes de sécurité de systèmes avioniques, comprenant une ou plusieurs applications, hébergés au moins partiellement par un module. Plus précisément, lors de la 30 procédure d'installation du module, l'invention vise à ne stimuler que les interfaces d'entrée/sortie des systèmes avioniques hébergés par le module, qui ne sont pas couvertes par des tests interactifs, sans stimuler les entrés/sorties des autres modules utilisés par ces mêmes systèmes avioniques. Il est également possible, pour réduire le temps de maintenance, de ne tester que les entrées/sorties critiques du module. L'invention permet ainsi à un opérateur de maintenance en charge d'effectuer des procédures de pose et dépose d'un module de n'avoir qu'un seul test interactif à exécuter, ce test couvrant la partie matérielle du module ainsi que ses interfaces d'entrée/sortie jugées critiques. De façon générale, l'invention consiste à ajouter au périmètre de tests d'intégrité d'un module, c'est-à-dire aux module test vérifiant les fautes internes du calculateur et module interface test vérifiant les interfaces d'entrée/sortie testables, un ensemble de tests complémentaires permettant d'assurer, lors de l'exécution du test d'intégrité du module, une couverture complète des aspects de sécurité. Ces tests complémentaires représentent un sous-ensemble du périmètre de tests effectués par des tests système des applications avioniques hébergées. Ces tests correspondent uniquement aux interfaces d'entrée/sortie utilisées par les applications sur le module testé ou uniquement à celles jugées critiques par le concepteur système et non couvertes par les tests interactifs du module. Ainsi, de nouveaux types de tests sont définis pour tester les interfaces d'entrée/sortie ne pouvant être testées qu'à l'aide des applications système. De tels tests peuvent être effectués dans des temps inférieurs et avec des contraintes moindres que les tests système standard. Ils sont, de préférence, développés avec l'aide des ingénieurs système des ATA concernés (ATA XX) qui utilisent la ressource ATA 42. Cependant, pour ne pas entraver le processus de développement des applications, il n'est, de préférence, pas envisagé de développement spécifique relatif à ces nouveaux types de tests. Une solution avantageuse consiste alors à utiliser les tests système existants, développés avec les applications avioniques concernées, pour tester leurs propres interfaces d'entrée/sortie. Ces tests système existants sont ici décomposés en tests élémentaires, par exemple par module, par niveau de criticité et/ou par interface d'entrée/sortie, pour permettre leur intégration avec des tests d'intégrité réalisés au niveau de I'ATA 42 au sein d'un module.

Ces nouveaux types de tests, pouvant être appelés mini tests système (mini-ST) ou tests système élémentaires, permettent de tester un nombre restreint d'interfaces d'entrée/sortie selon les caractéristiques des applications. De façon avantageuse, les tests système sont décomposés en autant de tests système élémentaires qu'il y a de modules sur lesquels est hébergée l'application considérée et en autant de niveaux de criticité que définis par les développeurs de l'application correspondante. Ces tests système élémentaires peuvent être intégrés à l'interface de test des modules ou appelés de façon autonome par un opérateur de maintenance via cette interface. Quelque soit l'implémentation choisie, ces tests système élémentaires doivent, pour être exécutés, répondre aux mêmes contraintes que les module test et module interface test, c'est-à-dire, en particulier, pouvoir être exécutés par un opérateur de maintenance, depuis un ordinateur central de gestion de messages de maintenance (CMS), lorsque l'aéronef est au sol. En s'interfaçant avec les procédures existantes de création des tests système, en ajoutant une étape consistant à décomposer ces tests, par exemple par criticité et/ou module, le surcoût de développement de ces tests système élémentaires est faible. Du coté de l'ATA 42, il est nécessaire de prendre en compte ces nouveaux types de tests pour les mettre en oeuvre. Pour répondre aux contraintes de coût et de sécurité ainsi qu'à celles liées aux procédures visant l'ATA 42 et les applications concernées, plusieurs solutions sont possibles. La figure 4, comprenant les figures 4a et 4b, illustre le périmètre de couverture de tests d'interfaces d'entrée/sortie dans quatre modules référencés 400-1 à 400-4 mettant en oeuvre quatre systèmes avioniques, comprenant chacun une ou plusieurs applications, lorsqu'un module interface test et des tests système sont exécutés et lorsqu'un module interface test et des tests système élémentaires sont exécutés, respectivement. Chaque croix représente ici une interface d'entrée/sortie. Le module 400-1 comprend un ensemble d'interfaces d'entrée/sortie dont certaines peuvent être testées par le module interface test associé et d'autres peuvent être testées par des tests système ou des tests système élémentaires. Ainsi, comme illustré sur la figure 4a, la référence 405-1 désigne la couverture de test des interfaces d'entrée/sortie du module 400-1 par le module interface test associé. La référence 410-1 vise la couverture de test des interfaces d'entrée/sortie du module 400-1 par des tests système d'un premier système avionique mis en oeuvre par les modules 400-1 à 400-4. Cependant, comme décrit précédemment, les interfaces d'entrée/sortie 410-1 ne peuvent pas être testées par les tests système indépendamment des interfaces d'entrée/sortie des modules 400-2 à 400-4 utilisées par ce premier système avionique. Ainsi, lorsque les tests système du premier système avionique sont exécutés, la couverture de test des interfaces d'entrée/sortie comprend des interfaces d'entrée/sortie des modules 400-1, 400-2, 400-3 et 400-4, comme illustré par la référence 415-1.

De façon similaire, la couverture de test des interfaces d'entrée/sortie des modules 400-2, 400-3 et 400-4 par les module interface test qui leur sont associés est représentée par les références 405-2, 405-3 et 405-4, respectivement. De même, la couverture de test des interfaces d'entrée/sortie utilisées par un second, un troisième et un quatrième systèmes avioniques mis en oeuvre par les modules 400-1 à 400-4, par des tests système associés, est représentée par les références 415-2, 415-3 et 415-4, respectivement. Ainsi, comme illustré, un nombre important d'interfaces d'entrée/sortie n'est pas testé par les module interface test alors que l'utilisation de tests système permet de tester toutes les interfaces d'entrée/sortie.

Cependant, comme décrit précédemment, l'exécution de tests système requiert un temps important et nécessite généralement l'intervention d'opérateurs de maintenance spécialisés pour, par exemple, actionner des vannes ou effectuer des vérifications. En outre, de tels tests ont pour objet de tester des interfaces d'entrée/sortie de tous les modules mettant en oeuvre le système avionique correspondant, sans qu'il soit possible de tester un seul module. Sachant qu'un système avionique peut être mis en oeuvre par plus de quatre modules et qu'un module peut héberger de nombreux systèmes avioniques, le temps de test des interfaces d'entrée/sortie d'un module augmente d'autant. La décomposition de tests système en tests élémentaires comprenant des tests système élémentaires permet de tester les interfaces d'entrée/sortie associées à un système avionique d'un seul module, comme illustré sur la figure 4b. La référence 405'-1 désigne la couverture de test des interfaces d'entrée/sortie du module 400-1 par le module interface test. La référence 420-11 vise la couverture de test des interfaces d'entrée/sortie du module 400-1 par des tests système élémentaires d'un premier système avionique mis en oeuvre par les modules 400-1 à 400-4. Ces tests système élémentaires, dérivés des tests système 415'-1, sont ici associés au module 400-1. Par conséquent, la couverture de tests des interfaces d'entrée/sortie par ces tests système élémentaires est limitée au module 400-1 alors même que le système avionique correspondant est mis en oeuvre par les modules 400-1 à 400-4. De façon similaire, les références 420-12, 420-13 et 420-14 illustrent la couverture de tests des interfaces d'entrée/sortie du module 400-1 par des tests système élémentaires d'un second, troisième et quatrième systèmes avioniques mis en oeuvre par les modules 400-1 à 400-4.

Les interfaces d'entrée/sortie visées par les références 420-11 à 420-14 sont testées lorsque le module interface test du module 400-1 est exécuté ou par un opérateur de maintenance à travers cette interface de test. Ainsi, la couverture de test des interfaces d'entrée/sortie du module 400-1 par le module interface test, de façon directe ou indirecte, comprend l'ensemble des interfaces d'entrée/sortie référencées 405'-1 et 420-11 à 420-12, c'est-à-dire l'ensemble des interfaces d'entrées/sorties référencées 425-1, soit, selon cet exemple, toutes les interfaces d'entrée/sortie du module 400-1. Il est observé ici que toutes les interfaces d'entrée/sortie du module 400-1 sont testées sans qu'il soit nécessaire de tester des interfaces 30 d'entrée/sortie des modules 400-2, 400-3 et/ou 400-4. Il existe plusieurs modes de réalisation possible pour mettre en oeuvre des tests système élémentaires. Cependant, quelque soit le mode de réalisation envisagé, il est avantageux d'éviter de complexifier le travail de développement des systèmes avioniques. Par conséquent, la création des fichiers permettant de configurer des tests système élémentaires est, de préférence, réalisée à partir de fichiers de configuration de tests système, par exemple de fichiers XML (sigle d'eXtensible Markup Language en terminologie anglo-saxonne). Selon un premier mode de réalisation, le module test interface demande, au cours de son exécution, aux systèmes avioniques concernés (ATA XX), le résultat des tests système élémentaires qui leurs sont associés.

Les ATA XX effectuent ainsi eux mêmes ces tests système élémentaires. Les résultats sont alors ajoutés par le module test aux résultats des tests d'interfaces d'entrée/sortie effectués par le module interface test. En d'autres termes, lorsqu'un module interface test est appelé, le module sur lequel il est exécuté demande à tous les systèmes avioniques pour lesquels ce module fourni des interfaces d'entrée/sortie les résultats des tests système élémentaires associés à ces interfaces d'entrée/sortie. Pour pouvoir les fournir, chaque système avionique effectue, sur demande du module, le test de ses interfaces d'entrée/sortie grâce à une base de données de tests système élémentaires pré-configurés (c'est-à-dire des sous-tests des tests système). A la fin de l'exécution du module interface test, le module testé concatène les résultats provenant des différents tests système élémentaires des différents systèmes avioniques mis en oeuvre avec ceux du module interface test. Les résultats concaténés sont alors transmis au CMS ou à un dispositif équivalent.

Un tel mode de réalisation est décrit en référence à la figure 5. Lorsqu'un aéronef est au sol, un opérateur de maintenance peut, depuis un ordinateur de maintenance, par exemple le CMS 500, placé en mode interactif, lancer un module interface test (MIT) à partir d'une interface homme-machine (IHM) de cet ordinateur (étape 505). La requête correspondante est transmise au module 510 visé par le test. A partir d'une table de configuration, le module 510 détermine les interfaces d'entrée/sortie utilisées par chaque partition, c'est-à-dire les interfaces d'entrée/sortie allouées à chaque système avionique, parmi toutes les interfaces d'entrée/sortie 515 du module. Le module 510 adresse alors une requête, par exemple de façon séquentielle, à chaque partition pour l'exécution des tests système élémentaires permettant de tester les interfaces d'entrée/sortie correspondantes. Ainsi, le module 510 commence par adresser une première requête (étape 520) à la partition associée à un premier système avionique, ici l'ATA XX, référencée 525, indiquant, de préférence, les interfaces d'entrée/sortie devant être testées. Il est observé que si certaines interfaces d'entrée/sortie ne doivent pas ou ne peuvent pas être testées, notamment pour des raisons de sécurité, en fonction de l'état de l'aéronef, il suffit que le test système élémentaire correspondant prenne cette donnée en considération (les concepteurs du système avionique, qui écrivent les tests système élémentaires sont les mieux placés pour connaître la testabilité ou non d'une interface d'entrée/sortie) et prévienne le module testé que cette interface d'entrée/sortie n'est pas testable. En réponse à la requête d'exécution de tests système élémentaires, si des interfaces d'entrée/sortie de la première partition 525 peuvent être testées, cette dernière retourne un accusé réception d'autorisation confirmant la possibilité d'exécuter le test d'interfaces d'entrée/sortie (étape 530), c'est-à-dire un message de type OK. Alternativement, si les entrées/sorties de la première partition 525 ne peuvent pas être testées, le message retourné est de type NOK. La première partition peut également autoriser le test de seulement certaines interfaces d'entrée/sortie. La librairie transmise peut alors ne comprendre que les tests système élémentaires autorisés ou comprendre tous les tests système élémentaires, à charge pour le module testé de n'exécuter que ceux autorisés. Si des interfaces d'entrée/sortie de la première partition 525 peuvent être testées, la première partition 525 retrouve le ou les tests système élémentaires et les exécute. Comme indiqué précédemment, ces tests système élémentaires sont typiquement des sous-tests des tests système classiques. A ces fins, des données peuvent être échangées entre le module testé 510 et la première partition 525 (étape 535), notamment pour fournir des résultats de tests système élémentaires lorsque tous les tests système élémentaires associés à la première partition 525 n'ont pas été exécutés. Après que le ou les tests système élémentaires autorisés de la première partition aient été exécutés, les résultats correspondants sont transmis au module testé 510 (étape 540) qui les ajoute aux résultats du module interface test. Comme indiqué ci-dessus, ces résultats peuvent également être transmis au fur et à mesure de l'exécution des tests système élémentaires. Le processus est alors répété pour les partitions suivantes, notamment, ici, les partitions liées, ici, aux systèmes ATA YY et ATA ZZ. Après avoir lancé l'exécution des tests système élémentaires associés aux partitions du module testé, le module interface test transmet au CMS (étape 545) ses résultats de tests comprenant en outre les résultats de tests issus des partitions, c'est-à-dire des tests système élémentaires exécutés.

Ce mode de réalisation permet d'obtenir un résultat de test complet et de ségréguer les tâches exécutées, le module testé exécutant le module interface test (ATA 42) et chaque ATA étant en charge d'exécuter les tests système élémentaires. Par ailleurs, les ressources utilisées pour exécuter les tests, notamment les ressources CPU (sigle de Central Processing Unit en terminologie anglo-saxonne), sont celles de la partition ATA XX dont les entrées/sorties sont testées. Il n'est donc pas nécessaire de prévoir, dans le module testé, de ressources particulières. Selon un second mode de réalisation, les tests système élémentaires sont créés, par les développeurs des applications avioniques, sous forme de librairies. Ces dernières sont alors appelées par le module testé en plus du module test et du module interface test. Ce mode de réalisation est ainsi proche du premier mode de réalisation décrit précédemment cependant, le module test demande aux systèmes ATA XX les librairies des tests système élémentaires qu'il exécute lui-même pour compléter son module interface test.

Ce mode de réalisation est illustré sur la figure 6. A nouveau, lorsqu'un aéronef est au sol, un opérateur de maintenance peut, depuis un ordinateur de maintenance tel qu'un CMS 600, placé en mode interactif, lancer un module test à partir d'une IHM de cet ordinateur (étape 605). La requête correspondante est transmise au module 610 visé par le test. A partir d'une table de configuration, le module 610 détermine les interfaces d'entrée/sortie utilisées par chaque partition, c'est-à- dire les interfaces d'entrée/sortie allouées à chaque système avionique, parmi toutes les interfaces d'entrée/sortie 615 du module. Le module 610 adresse alors une requête, par exemple de façon séquentielle, à chaque partition pour obtenir l'autorisation de tester les interfaces d'entrée/sortie associées et obtenir une librairie correspondant aux tests système élémentaires permettant de tester ces interfaces d'entrée/sortie. Ainsi, le module 610 commence par adresser une première requête (étape 620) à la partition associée à un premier système, ici l'ATA XX, référencée 625, indiquant, de préférence, les interfaces d'entrée/sortie devant être testées. En réponse à cette requête, la partition retourne un message autorisant le test d'interfaces d'entrée/sortie (étape 630), c'est-à-dire un message de type OK, ainsi que la librairie correspondant aux tests système élémentaires à exécuter. Alternativement, si les interfaces d'entrée/sortie de la première partition 625 ne peuvent pas être testées, le message retourné est de type NOK.

Si des interfaces d'entrée/sortie de la première partition 625 peuvent être testées et que le module testé a reçu une librairie correspondant aux tests système élémentaires à exécuter, cette dernière est exécutée par le module testé. Comme indiqué précédemment, ces tests système élémentaires sont typiquement des sous-tests des tests système classiques.

Après que les tests système élémentaires de la première partition aient été exécutés, les résultats correspondants sont ajoutés aux résultats du module interface test. Un message de fin d'exécution de la librairie reçue est alors, de préférence, transmis à la première partition 625 (étape 635). Le processus est alors répété pour les partitions suivantes, notamment les partitions liées aux systèmes ATA YY et ATA ZZ. Après avoir lancé l'exécution des librairies correspondant aux tests système élémentaires associés aux partitions du module testé, le module interface test transmet au CMS (étape 640) ses résultats de tests comprenant les résultats de tests issus des partitions, c'est-à-dire des tests système élémentaires. Ce mode de réalisation permet d'obtenir un résultat de test complet et de ségréguer les tâches exécutées, le module testé exécutant le module interface test (ATA 42) et chaque ATA étant en charge d'autoriser l'exécution de tests système élémentaires. Par ailleurs, ce mode de réalisation permet une gestion dynamique des tests des interfaces d'entrée/sortie. Un troisième mode de réalisation, dérivé du second mode de réalisation décrit précédemment, consiste à pré-charger les librairies correspondant aux tests système élémentaires dans le module à tester pour pouvoir être exécutées comme module interface test, c'est-à-dire sans interagir avec les applications ayant fournies les librairies. Ainsi, lorsqu'un module interface test est demandé, le module testé lance toutes les librairies concernant les interfaces d'entrée/sortie à tester. Les librairies sont directement implémentées dans le module, ce qui évite tous les problèmes de communication entre le module à tester et les applications. Ces librairies ont été préalablement créées par les ATA XX et chargées dans les modules dans une table dédiée.

Ce mode de réalisation est illustré sur la figure 7. A nouveau, lorsqu'un aéronef est au sol, un opérateur de maintenance peut, depuis un ordinateur de maintenance tel qu'un CMS 700, placé en mode interactif, lancer un module test à partir d'une IHM de cet ordinateur (étape 705). La requête correspondante est transmise au module 710 visé par le test. A partir d'une table de configuration, le module 710 détermine les interfaces d'entrée/sortie utilisées par chaque partition, c'est-à-dire les interfaces d'entrée/sortie allouées à chaque système avionique, parmi toutes les interfaces d'entrée/sortie 715 du module. Le module 710 adresse alors une requête, par exemple de façon séquentielle, à chaque partition pour obtenir l'autorisation de tester les interfaces d'entrée/sortie associées. Ainsi, le module 710 commence par adresser une première requête (étape 720) à la partition associée à un premier système, ici l'ATA XX, référencée 725, indiquant, de préférence, les interfaces d'entrée/sortie devant être testées. En réponse à cette requête, la partition retourne un message autorisant le test d'interfaces d'entrée/sortie (étape 730), c'est-à-dire un message de type OK. Alternativement, si les interfaces d'entrée/sortie de la première partition 725 ne peuvent pas être testées, le message retourné est de type NOK. La partition peut également retourner un message autorisant le test de seulement certaines interfaces d'entrée/sortie. Si des interfaces d'entrée/sortie de la première partition 725 peuvent être testées, le module testé retrouve une librairie correspondant aux tests système élémentaires à exécuter dans une table dédiée référencée ici 735. Cette librairie est alors exécutée par le module testé selon les autorisations données par la partition. Comme indiqué précédemment, ces tests système élémentaires sont typiquement des sous-tests des tests système classiques.

Après que les tests système élémentaires autorisés de la première partition aient été exécutés, les résultats correspondants sont ajoutés aux résultats du module interface test. Un message de fin d'exécution de la librairie reçue est alors, de préférence, transmis à la première partition 725 (étape 735). Le processus est alors répété pour les partitions suivantes, notamment les partitions liées, ici, aux systèmes ATA YY et ATA ZZ. Après avoir lancé l'exécution des librairies correspondant aux tests système élémentaires associés aux partitions du module testé, le module interface test transmet au CMS (étape 745) ses résultats de tests comprenant les résultats de tests issus des partitions, c'est-à-dire des tests système élémentaires. Ce mode de réalisation permet d'obtenir un résultat de test complet et de ségréguer les tâches exécutées, le module testé exécutant le module interface test (ATA 42) et chaque ATA étant en charge d'autoriser l'exécution de tests système élémentaires. Par ailleurs, le pré-chargement des librairies dans le module testé diminue les problèmes de communication et de cohérence des données entre les partitions systèmes des ATA XX et le module testé.

Alors que les trois modes de réalisation décrits précédemment permettent de tester des interfaces d'entrée/sortie d'un module à partir d'un ordinateur de maintenance, elles ne permettent pas de tester des conditions initiales avant l'exécution de tests système élémentaires. De telles conditions initiales peuvent notamment concerner des conditions ne pouvant être vérifiées que par un opérateur, par exemple, une condition connue sous l'expression « Warning : nobody next to sterring » indiquant un danger pour des personnes situées à proximité de surfaces mobiles. De telles conditions initiales sont typiquement décrites, à l'aide de balises particulières (par exemple la balise <_INIT>), pour chaque système avionique, dans des fichiers au format XML qui permettent d'effectuer des tests système en mode interactif, c'est-à-dire déclenchés par un opérateur de maintenance. Ces fichiers sont généralement fournis par des sous-traitants travaillant au développement de fonctions avioniques et chargés dans le CMS.

Lors de tests système, le CMS utilise ces fichiers. Si des balises prédéterminées sont identifiées, les pré-conditions correspondantes doivent être vérifiées pour exécuter les tests. Un quatrième mode de réalisation permet de vérifier de telles conditions initiales avant l'exécution de tests d'interfaces d'entrée/sortie dans un module. Selon ce mode de réalisation, l'ordinateur qui permet à un opérateur de maintenance de lancer des procédures de maintenance, par exemple un CMS, est directement utilisé pour lancer des tests système élémentaires. Conformément à la logique mise en oeuvre dans les trois modes de réalisation décrits précédemment, l'interface de test utilisé ici fait appel à un module interface test et à des tests système élémentaires issus de tests système. Ainsi, les interfaces d'entrée/sortie d'un module sont testées physiquement et fonctionnellement grâce au module interface test et aux tests système élémentaires des systèmes avioniques (ATA XX) qui utilisent le module à tester.

La figure 8 illustre schématiquement ce quatrième mode de réalisation.

Lorsqu'un aéronef est au sol, un opérateur de maintenance peut, depuis un ordinateur de maintenance tel qu'un CMS 800, placé en mode interactif, utiliser l'IHM de cet ordinateur pour lancer des tests. Le CMS 800 comprend ici une interface 805 vers les systèmes avioniques, c'est-à-dire vers les partitions des modules de type IMA, ainsi qu'une mémoire où sont notamment stockées des instructions 810 permettant de commander les tests à exécuter par les modules, c'est-à-dire, en particulier, des tests système élémentaires. Ainsi, par exemple, un opérateur de maintenance peut, à partir du CMS 800, adresser une requête (étape 815) à une première partition 820 du module 825 à tester. La requête comprend ici des instructions pour exécuter des tests système élémentaires préalablement chargés dans la première partition 820, ces tests système élémentaires permettant de tester des interfaces d'entrée/sortie du module testé 825, utilisées par la première partition 820, parmi toutes ses interfaces d'entrée/sortie 830. Les résultats d'exécution de ces tests système élémentaires sont transmis par la première partition 820 au CMS 800 (étape 835) qui peut alors les afficher. De façon similaire, l'opérateur de maintenance peut adresser des requêtes similaires aux autres partitions du module testé 825 afin de tester d'autres interfaces d'entrée/sortie de ce module. Ainsi, les résultats d'exécution des tests système élémentaires sont communiqués au CMS puis affichés au fur et à mesure de l'exécution des tests système élémentaires.

Il est également possible d'afficher les résultats de tests lorsque tous les tests ont été effectués. Cependant, une telle solution ne présente pas de réels avantages car si une panne est détectée, une détection système par système autorise une meilleure réactivité pour l'analyse des défaillances. Comme décrit précédemment, les scénarii de tests interactifs peuvent être stockés dans le CMS au format XML. Ces fichiers peuvent contenir différentes commandes, telles que les commandes START, INIT, NEXT et WAIT qui sont identifiées à l'aide de balises prédéterminées et envoyées à la fonctionnalité BITE du module à tester. Il est observé ici que ces fichiers sont définis par les développeurs des ATA XX en suivant des consignes de I'ATA 42 car lorsqu'un opérateur de maintenance lance un de ces tests, il lance un test ATA 42 et non pas un test ATA XX en tant que tel. Par conséquent, la configuration de ces fichiers XML doit notamment prendre en compte le fait de pouvoir convertir des résultats ATA XX en ATA 42 avant de les afficher sur le CMS. La figure 9 illustre un exemple de diagramme de séquence lors de l'exécution d'un test système élémentaire nécessitant la vérification de conditions initiales, conformément au quatrième mode de réalisation décrit précédemment. Plus précisément, la figure 9 illustre des échanges de messages, de requêtes et de résultats entre des systèmes 900 d'un aéronef permettant de définir un statut, un opérateur de maintenance 902, une IHM 904 d'un CMS utilisé, une application ATA XX 906, une interface d'entrée/sortie 908 d'un module mettant en oeuvre cette application et un capteur ou un actionneur 910. Après qu'un test ait été sélectionné par un opérateur de maintenance 902 à travers une IHM 904 du CMS utilisé (étape 912), des informations relatives à ce test sélectionné sont, de préférence, affichées (étape 914). Comme décrit précédemment, les données de configuration de tests sont, par exemple, définies dans un fichier de configuration au format XML. Le premier test système élémentaire du test sélectionné est alors identifié pour être exécuté (référence 916). A nouveau, des informations concernant ce test système élémentaire sont, de préférence, affichées (étape 918). Une phase d'initialisation de ce test système élémentaire (référence 920) est alors lancée. Durant cette phase, une première étape a pour objet de placer le module testé en mode de test interactif (étape 922). Si une ou plusieurs pré-conditions sont requises pour effectuer le test système élémentaire identifié, c'est-à-dire si le fichier de configuration indique une telle contrainte, par exemple à l'aide de balises prédéterminées, l'IHM 904 l'indique à l'opérateur de maintenance 902 (étape 924). Selon la nature des pré-conditions, celles-ci sont validées ou non (étapes 926 et 928) par l'opérateur de maintenance par analyse visuelle, par exemple s'il s'agit de l'absence de personnel aux abords de surfaces mobiles, ou par interrogation d'un système de l'aéronef, par exemple s'il s'agit de l'état arrêté ou éteint d'un calculateur. La validation (ou l'invalidation) est transmise par l'opérateur de maintenance 902 à l'IHM 904 (étape 930). Si les pré-conditions ne sont pas valides, il est mis fin à l'exécution du test système élémentaire identifié et, le cas échéant, le test système élémentaire suivant est identifié pour être traité de la même façon.

Le test système élémentaire suivant peut viser une interface d'entrée/sortie différente de celle testée précédemment, associée au même système avionique (même ATA XX), ou une interface d'entrée/sortie différente d'un système avionique différent. Si, au contraire, les pré-conditions sont valides, le test système élémentaire est exécuté. A ces fins, des stimuli sont générés par l'application 906 visée par le test et transmis à l'interface d'entrée/sortie 908 du module testé (étape 932). Parallèlement, l'application 906 se place dans un mode de surveillance et de détection de faute (étape 934). Les stimuli transmis à l'interface d'entrée/sortie 908 du module testé sont alors retransmis, sous forme de commandes, à un actionneur ou un capteur 910 (étape 936) qui exécute la ou les commandes reçues (étape 938) et retourne un résultat à l'interface d'entrée/sortie 908 du module testé qui le retransmet lui-même à l'application 906 qui, à son tour, le retransmet à l'IHM 904 (étapes 940, 942 et 944) qui peut ainsi afficher le résultat d'exécution du test système élémentaire identifié (étape 946). Le test système élémentaire suivant est alors, le cas échéant, identifié pour être traité de la même façon. A nouveau, le test système élémentaire suivant peut viser une interface d'entrée/sortie différente de celle testée précédemment, associée au même système avionique (même ATA XX), ou une interface d'entrée/sortie différente d'un système avionique différent.

Un tel mode de réalisation permet un test exhaustif des interfaces d'entrée/sortie considérées comme critiques dans un module, sans impact pour la fonction qui héberge les applications des ATA XX (ATA 42), et prenant en compte des conditions initiales. En outre, un tel mode de réalisation n'exige pas de ressource de calcul supplémentaire au niveau du module testé et peu de ressource au niveau de l'ordinateur central de gestion des messages de maintenance (ici le CMS). Des estimations ont montré que le ratio de gain de temps des tests système élémentaires par rapport aux tests système était de l'ordre de cinq.

Quelque soit le mode de réalisation, si des tests système élémentaires ne révèlent pas de faute, les interfaces d'entrée/sortie testées peuvent être considérées comme fonctionnant normalement. Par contre, si une faute est détectée, l'interface d'entrée/sortie considérée du module est défaillante (il y a donc une faute ATA 42) et/ou un équipement connecté à cette interface d'entrée/sortie est défectueux (ce qui correspond à une faute du système avionique correspondant, faute ATA XX). Selon le cas, les responsabilités ne sont pas les mêmes car en présence d'une faute d'un système avionique, l'opérateur de maintenance a révélé une panne cachée qui était vraisemblablement présente avant le remplacement du module ATA 42, mais qui n'est pas de sa responsabilité. Elle doit être corrigée par un opérateur de maintenance du système avionique en cause. Par conséquent, lors de la procédure de remplacement d'un module ATA 42, il pourrait être conseillé d'effectuer des tests système élémentaires deux fois, une fois avant le changement et une fois après la pose du nouveau module pour identifier l'origine de la panne du système avionique, c'est-à-dire déterminer si elle a été introduite ou non par l'opérateur de maintenance. Ainsi, non seulement l'invention permet d'améliorer les tests effectués relatifs à un module changé mais elle permet également de diagnostiquer des pannes cachées qui pourraient avoir des impacts sur la sécurité. Par conséquent ceci apporte aussi un meilleur diagnostique fonctionnel des modules mis en oeuvre.

La figure 10 illustre un exemple d'architecture matérielle d'un module de type IMA, adaptée à mettre en oeuvre certaines étapes de l'invention. Le dispositif 1000 comporte ici un bus de communication 1005 auquel sont reliés : - une ou plusieurs unités centrales de traitement ou microprocesseurs 1010 (CPU) ; - une mémoire morte 1015 (ROM, acronyme de Read Only Memory en terminologie anglo-saxonne) pouvant comporter des programmes (prog, prog1 et prog2) nécessaires à la mise en oeuvre de l'invention ; - une mémoire vive ou mémoire cache 1020 (RAM, acronyme de Random Access Memory en terminologie anglo-saxonne) comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution des programmes précités ; et - une interface de communication 1050 adaptée à transmettre et à recevoir des données.

Le dispositif 1000 dispose également, de préférence, des éléments suivants d'un disque dur 1035 pouvant comporter les programmes précités ainsi que des informations traitées ou à traiter selon l'invention et d'un lecteur de cartes mémoires 1040 adapté à recevoir une carte mémoire 1045 et à y lire ou à y écrire des données traitées ou à traiter selon l'invention.

Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le dispositif 1000 ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément du dispositif 1000 directement ou par l'intermédiaire d'un autre élément du dispositif 1000. Le code exécutable de chaque programme permettant au dispositif programmable de mettre en oeuvre les processus selon l'invention, peut être stocké, par exemple, dans le disque dur 1035 ou en mémoire morte 1015. Selon une variante, la carte mémoire 1045 peut contenir des informations, notamment des informations à traiter selon l'invention, ainsi que le code exécutable des programmes précités qui, une fois lu par le dispositif 1000, est stocké dans le disque dur 1035.

Selon une autre variante, le code exécutable des programmes et les informations à traiter selon l'invention pourront être reçus, au moins partiellement, par l'intermédiaire de l'interface 1050, pour être stocké de façon identique à celle décrite précédemment.

De manière plus générale, le ou les programmes ainsi que les informations à traiter selon l'invention pourront être chargés dans un des moyens de stockage du dispositif 1000 avant d'être exécutés. L'unité centrale 1010 va commander et diriger l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur 1035 ou dans la mémoire morte 1015 ou bien dans les autres éléments de stockage précités. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 1035 ou la mémoire morte 1015, sont transférés dans la mémoire vive 1020 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention. L'architecture du dispositif illustré sur la figure 10 peut également être utilisée dans un ordinateur de maintenance permettant à un opérateur de maintenance de lancer des tests interactifs dans un module de type IMA. Cependant, le dispositif dispose en outre, de préférence, d'une ou plusieurs unités d'affichage permettant de visualiser des données et pouvant servir d'interface graphique avec un utilisateur qui pourra interagir avec des programmes selon l'invention, à l'aide d'un clavier et d'une souris ou d'un autre dispositif de pointage tel qu'un écran tactile ou une télécommande. Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente.

Claims (12)

1. REVENDICATIONS1. Procédé de test d'au moins une interface d'entrée/sortie d'un module informatique de type IMA (510, 610, 710, 825) comprenant une pluralité d'interfaces d'entrée/sortie (515, 615, 715, 830) dans un dispositif comprenant une pluralité de modules informatiques de type IMA, au moins un système comprenant au moins une application étant mis en oeuvre par un ensemble de modules informatiques de ladite pluralité de modules informatiques, ledit ensemble comprenant ledit module informatique, appelé premier module, et au moins un autre module informatique, appelé au moins un second module, au moins un test système étant associé audit au moins un système pour tester fonctionnellement ledit ensemble de modules informatiques selon ledit système, ce procédé étant caractérisé en ce que ledit au moins un test système comprend au moins un test système élémentaire pour tester fonctionnellement ladite au moins une interface d'entrée/sortie dudit premier module, et en ce qu'il comprend une étape d'exécution dudit au moins un test système élémentaire, ladite étape d'exécution dudit au moins un test système élémentaire étant indépendante dudit au moins un second module, et une étape de transmission (545, 640, 745, 830) d'au moins un résultat d'exécution dudit au moins un test système élémentaire à un ordinateur de maintenance distinct des modules informatiques de ladite pluralité de modules informatiques.
2. 2. Procédé selon la revendication 1 comprenant en outre une étape d'exécution d'au moins un second test système élémentaire, distinct dudit au moins un test système élémentaire, appelé premier test système élémentaire, ledit au moins un second test système élémentaire permettant de tester au moins une seconde interface d'entrée/sortie dudit premier module, distincte de ladite au moins une interface d'entrée/sortie, appelée au moins une première interface, ledit au moins un second test système élémentaire appartenant à un second test système, distinct dudit au moins un test système, appelé au moins un premier test système, ledit second test système étant associé à un second système comprenant au moins une application, distinct dudit au moins un système, appelé au moins un premier système, ledit second système étant mis en oeuvre par un second ensemble de modules informatiques, distinct dudit ensemble de modules informatiques, appelé premier ensemble, comprenant au moins ledit premier module et au moins un autre module informatique de ladite pluralité de modules informatiques, ledit second test système permettant de tester fonctionnellement ledit second ensemble de modules informatiques selon ledit second système, ladite étape d'exécution dudit au moins un second test système élémentaire étant indépendante dudit au moins un autre module informatique dudit second ensemble, et une étape de transmission (545, 640, 745, 830) d'au moins un résultat d'exécution dudit second test système élémentaire audit ordinateur de maintenance.
3. 3. Procédé selon la revendication 2 selon lequel ladite étape d'exécution dudit au moins un second test système élémentaire est appelée suite à l'exécution dudit premier test système élémentaire.
4. 4. Procédé selon l'une quelconque des revendications 1 à 3 comprenant en outre une étape de test logique d'interface d'au moins une interface d'entrée/sortie dudit module informatique, ladite étape d'exécution dudit au moins un test système élémentaire étant appelée par ladite étape de test logique.
5. 5. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape d'autorisation (530, 630, 730, 930) d'exécution dudit test système élémentaire selon ledit au moins un système, ledit test système élémentaire étant exécuté en réponse à ladite étape d'autorisation.
6. 6. Procédé selon la revendication 5, ledit test système élémentaire étant exécuté dans un environnement propre audit au moins un système.
7. 7. Procédé selon l'une quelconque des revendications 1 à 3 comprenant en outre une étape d'initialisation (920) dudit test système élémentaire, ladite étape d'initialisation étant exécutée en réponse à une commande d'un opérateur saisie via ledit ordinateur de maintenance.
8. 8. Procédé selon la revendication 7 comprenant en outre une étape de vérification (926, 928) d'au moins une condition initiale, ladite étape d'exécution dudit au moins un test système élémentaire étant exécutée en réponse à ladite étape de vérification d'au moins une condition initiale.
9. 9. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape préliminaire de décomposition dudit test système en une pluralité de tests élémentaires, ladite pluralité de tests élémentaires comprenant ledit au moins un test système élémentaire.
10. 10. Programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications précédentes lorsque ledit programme est exécuté sur un ordinateur.
11. 11. Dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 9.
12. 12. Aéronef comprenant le dispositif selon la revendication 11.15