FR2959578A1 - Verification d'un systeme de communication d'un aeronef en developpement - Google Patents

Abstract

L'invention concerne un procédé et un dispositif de vérification d'un système de communication (3) comprenant une pluralité de modules (7) adaptés pour être installés dans un aéronef en développement (5), ledit dispositif de vérification comportant : - des moyens (11) pour construire une base de données (17) d'identification et de synchronisation dudit système de communication (3), ladite base de données définissant contractuellement des interfaces entre ladite pluralité de modules à partir des demandes de modification par rapport à une définition technique initiale, - des moyens (11) pour définir dans ladite base de données (17), des signaux configurés pour être échangés entre ladite pluralité de modules (7) via une pluralité de liens (3) interconnectant lesdites interfaces, lesdits signaux étant définis pour être synchronisés entre eux ainsi qu'avec la matérialisation physique desdits liens, et - des moyens (11) pour vérifier avant une évaluation d'un test de maturation du système de communication (3), une cohérence d'interface pour tous lesdits signaux de ladite base de données (17).

Description

VÉRIFICATION D'UN SYSTÈME DE COMMUNICATION D'UN AÉRONEF EN DÉVELOPPEMENT

DOMAINE TECHNIQUE La présente invention concerne le domaine de tests de maturation dans le développement d'un aéronef et plus particulièrement, la synchronisation et la vérification d'un système de communication de l'aéronef en développement avant les tests de maturation. ÉTAT DE LA TECHNIQUE ANTÉRIEURE Un aéronef est muni d'un système de communication pour assurer la communication entre une pluralité d'équipements. Ces équipements comportent par exemple, un système de commande et d'affichage dans la cabine de pilotage, un système de commande de moteur, un système des trains d'atterrissage, un système de surveillance, etc.. Tous ces équipements ou systèmes nécessitent de communiquer entre eux pour assurer la commande et la sécurité de l'aéronef. Chaque équipement est configuré pour engendrer et/ou recevoir une pluralité de signaux en fonction de son état de configuration. Par exemple, le système des trains d'atterrissage est configuré pour déclencher certains signaux en rapport avec l'état de l'aéronef au sol lorsqu'une pression sur les roues est détectée. En revanche, d'autres signaux en relation avec une phase de vol de l'aéronef sont déclenchés lorsqu'aucune pression n'est détectée sur les roues.

En outre, en fonction de la configuration ou la phase du vol de l'aéronef, certains signaux peuvent être inhibés pendant que d'autres sont activés. Par exemple, au moment de l'atterrissage, les signaux non pertinents par rapport à cet événement sont inhibés afin de ne pas déranger ou distraire les pilotes.

Par ailleurs, en plus de l'accroissement de la complexité des systèmes aéronautiques, de nouvelles fonctions apparaissent constamment comme par exemple, l'aide à la navigation aéroportuaire, et la prévention des obstacles (sol, nuages, etc.) rajoutant de nombreux échanges d'informations entre les équipements. Ainsi, à chaque étape de développement de l'aéronef, des tests en laboratoire, des tests fonctionnels de simulation, des premiers tests sur l'aéronef, et des tests de certification sont réalisés afin d'évaluer le niveau de maturité des différents équipements fonctionnels ou physiques et le bon échange des signaux entre les différents équipements. Or, les différents équipements de l'aéronef peuvent être développés dans des lieux géographiques différents et par des équipes ayant des activités de plus en plus spécialisées. Ceci peut compliquer la coordination entre toutes ces différentes équipes. En particulier, différents équipements fonctionnels ou physiques développés par différentes équipes peuvent présenter des problèmes d'interfaces qui n'aident pas à assurer une cohérence des échanges d'informations entre tous ces équipements lors des tests de maturation. Au départ, les tests peuvent être préparés à partir des hypothèses non totalement figées, fournies par les différentes équipes. Cependant, d'autres fonctions plus précises continuent à être développées, éventuellement générant de grosses modifications par rapport aux définitions initiales. Ceci peut rendre très difficile d'assurer à grande échelle le bon échange d'un très grand nombre de signaux et la bonne synchronisation entre tous les équipements lors des tests de maturation de l'aéronef en développement. Ainsi, certains problèmes peuvent entraver la bonne réalisation des tests de maturation et peuvent nécessiter l'exécution de modifications coûteuses avant de pouvoir refaire les tests dans de bonnes conditions. Par exemple, certaines interfaces peuvent ne pas communiquer entre elles à cause des problèmes de cohérence entre les définitions fonctionnelle et physique des interfaces et/ou des signaux. Il peut aussi exister des problèmes de logiciels qui ne dialoguent pas entre eux en raison des écarts par rapport à ce qui était prévu au départ. On peut aussi avoir des problèmes pour certains harnais de câblages qui ne correspondent pas au modèle prévu. Ceci peut nécessiter la modification, voire le remplacement, des harnais en question. En outre, des connexions erronées entre les interfaces lors de l'installation des harnais peuvent endommager certains éléments des équipements au moment des tests. Par ailleurs, des modifications techniques tardives peuvent engendrer des incompatibilités entre les interfaces des équipements.

Tous ces problèmes peuvent avoir un impact sur le développement de l'aéronef en termes de calendrier et de coûts. L'objet de la présente invention est de proposer un dispositif et un procédé de vérification d'un système de communication remédiant aux inconvénients précités, en particulier en permettant de vérifier la cohérence des échanges d'informations entre tous les systèmes de l'aéronef en développement.

EXPOSÉ DE L'INVENTION La présente invention est définie par un procédé de vérification d'un système de communication comprenant une pluralité de modules adaptés pour être installés dans un aéronef en développement, le procédé comportant les étapes suivantes : - construire une base de données d'identification et de synchronisation dudit système de communication, ladite base de données définissant contractuellement des interfaces entre ladite pluralité de modules à partir des demandes de modification par rapport à une définition technique initiale, - définir dans ladite base de données, des signaux configurés pour être échangés entre ladite pluralité de modules via une pluralité de liens interconnectant lesdites interfaces, lesdits signaux étant définis pour être synchronisés entre eux ainsi qu'avec la matérialisation physique desdits liens, et - vérifier avant une évaluation d'un test de maturation 30 du système de communication, une cohérence d'interface pour tous lesdits signaux de ladite base de données. Le procédé permet de donner une visibilité globale très en amont de l'évaluation des tests de maturation tout en permettant de coordonner et d'harmoniser les différents modules. Ceci permet d'assurer à une grande échelle le bon échange d'un très grand nombre de signaux (de l'ordre d'un million ou de plusieurs millions et qui peuvent être de natures très différentes) entre tous les modules de l'aéronef et l'adéquation avec les liens physiques associés. Par conséquent, il permet de fortement réduire les risques d'endommagement d'équipements de l'aéronef lors des tests ainsi que de respecter le calendrier de réalisation de l'aéronef. En effet, l'étape de vérification permet de vérifier avant de réaliser tout test de maturation qu'il n'y a pas d'incompatibilité entre les interfaces et permet d'identifier les écarts et/ou problèmes éventuels. Le procédé permet alors de synchroniser les développements des modules, qui ont des cycles très différents, permettant ainsi l'élaboration de spécifications cohérentes entre les modules. Avantageusement, la base de données comporte une 25 identification de synchronisation des signaux entre lesdits modules. Ceci permet de synchroniser la pluralité des modules avec l'étape des tests de maturation correspondant. 30 Avantageusement, ladite identification de synchronisation définit une cohérence fonctionnelle entre lesdits signaux, et une coordination entre les signaux et des liens physiques configurés pour transporter lesdits signaux. Ceci permet de réaliser un bon dialogue entre les 5 modules et une bonne communication des signaux sur les harnais de câblage. Avantageusement, les liens physiques comportent des câbles comprenant chacun une pluralité de connecteurs correspondant à ladite pluralité de liens 10 interconnectant lesdites interfaces, et la base de données comporte une identification de brochage et une correspondance entre chaque signal et le connecteur configuré pour transmettre ledit signal. Ainsi, la cohérence de brochage indique sur quel 15 connecteur se trouvent les messages et permet donc de garantir une bonne communication entre les modules. Avantageusement, les signaux sont définis en s'assurant que chaque signal possède les mêmes caractéristiques entre un module émetteur et un module 20 récepteur. Ceci permet de garantir un bon dialogue et aucune perte de messages entre les modules. Avantageusement, le procédé comporte une mise à jour continuelle de la base de données pour inclure 25 toute évolution fonctionnelle et/ou physique des interfaces et signaux. Ceci permet d'avoir une traçabilité des modifications tout en tenant compte des demandes tardives d'évolution du système. Ainsi, on peut 30 minimiser les modifications de dernières minutes qui peuvent être génératrices de surcoût, de retards, et de manque de qualité. Avantageusement, le procédé comporte une construction successive de ladite base de données correspondant à des étapes de tests de maturations successives, chaque test de maturation, comprenant de manière évolutive un ensemble de fonctions à tester où chaque fonction est configurée pour déclencher un ensemble de signaux représentatifs de ladite fonction.

Chaque ensemble de fonctions à tester définit un standard d'aéronef. Ceci permet d'identifier les besoins de l'ensemble des tests de maturation de l'aéronef en affectant les différents moyens de test mis en jeu pour chacun des standards.

Lesdits tests de maturation peuvent comporter : des tests fonctionnels, des tests de simulations, et des tests sur l'aéronef. Avantageusement, chaque test de maturation consiste à vérifier les signaux échangés entre les différents modules, et à évaluer le bon fonctionnement des différents modules de l'aéronef. L'invention vise également un dispositif de vérification d'un système de communication comprenant une pluralité de modules adaptés pour être installés dans un aéronef en développement, ledit dispositif de vérification comportant : - des moyens pour construire une base de données d'identification et de synchronisation dudit système de communication, ladite base de données définissant contractuellement des interfaces entre ladite pluralité de modules à partir des demandes de modification par rapport à une définition technique initiale, - des moyens pour définir dans ladite base de données, des signaux configurés pour être échangés entre ladite pluralité de modules via une pluralité de liens interconnectant lesdites interfaces, lesdits signaux étant définis pour être synchronisés entre eux ainsi qu'avec la matérialisation physique desdits liens, et - des moyens pour vérifier, avant une évaluation d'un test de maturation du système de communication, une cohérence d'interface pour tous lesdits signaux de ladite base de données.

BRÈVE DESCRIPTION DES DESSINS La Fig. 1 représente un dispositif de vérification pour vérifier un système de communication d'un aéronef en développement avant des tests de maturation, selon l'invention ; La Fig. 2 illustre un exemple du procédé de vérification du système de communication, selon l'invention ; La Fig. 3 illustre un exemple d'un tableau d'analyse de cohérence, selon l'invention ; et La Fig. 4 illustre l'ensemble des étapes couvertes par la vérification et les tests de maturation du système de communication, selon l'invention.

EXPOSÉ DÉTAILLÉ DE MODES DE RÉALISATION PARTICULIERS La Fig. 1 illustre de manière schématique un dispositif de vérification 1 qui peut être utilisé pour vérifier un système de communication d'un aéronef en développement 5 avant les tests de maturation, selon l'invention. On notera que la Fig. 1 est également une illustration du procédé de vérification, selon l'invention. Le système de communication 3 comprend une 10 pluralité de modules ou systèmes avioniques 7 adaptés pour être installés dans un aéronef en développement 5. En général, un aéronef peut comporter une soixantaine de systèmes comportant des modules 7 reliés entre eux par des harnais de câblage. Par souci de 15 simplification, la Fig. 1 illustre seulement trois modules 7 configurés pour être reliés entre eux par des liens 9 servant de support de communication. Chacun des modules 7 comporte au moins une interface de connexion munie d'une pluralité de points de contact permettant 20 l'interconnexion entre les différents modules 7 aux moyens des liens physiques. Le dispositif 1 de vérification comporte des moyens de traitement 11 comprenant des moyens de stockage 13 et des moyens de calcul 15 configurés pour 25 identifier, synchroniser et vérifier la cohérence des interfaces entre les modules 7 du système de communication 3, avant les tests de maturation.

Les tests de maturation sont préparés à partir d'une définition technique initiale des fonctions ou caractéristiques de l'aéronef en développement 5. Cependant, ces caractéristiques évoluent et deviennent de plus en plus précises au cours du développement de l'aéronef conformément à des demandes de modification ou d'évolution CN (Change Notes) établies par les différentes équipes développant les différents modules 7.

Ainsi, selon la phase de développement de l'aéronef, on réalise des tests de maturation de plus en plus sophistiqués. Ces tests peuvent comporter des tests fonctionnels, des tests de simulations, et des tests sur l'aéronef comme par exemple, la mise sous tension (power on), le premier vol, ou la certification de l'aéronef. A l'étape El, les moyens de traitement 11 sont adaptés pour construire une base de données 17 d'identification et de synchronisation du système de communication 3, qui peut être stockée dans les moyens de stockage 13. On identifie les fonctions à tester et on affecte les différents moyens de tests mis en jeu pour chacun des tests de maturation.

Plus particulièrement, les moyens de traitement 11 sont adaptés pour définir contractuellement dans la base de données 17, les interfaces entre la pluralité de modules 7 de l'aéronef en développement 5, en utilisant les demandes de modification CN par rapport à la définition technique initiale.

Cette première étape permet de définir clairement les besoins des moyens de tests et de donner une visibilité sur le développement et l'interdépendance des différents modules 7. De plus, elle permet de coordonner la conception, la configuration, et l'ensemble des moyens de test sur les modules 7 afin de garantir la cohérence de la définition technique pour chaque moyen de test donné. A l'étape E2, les moyens de traitement 11 sont adaptés pour définir dans la base de données 17, des signaux configurés pour être échangés entre la pluralité de modules 7 via une pluralité de liens 9 interconnectant les interfaces. Les signaux sont définis pour être synchronisés entre eux ainsi qu'avec la fabrication ou la matérialisation physique de ces liens 9. Plus particulièrement, les moyens de traitement 11 sont adaptés pour construire dans la base de données 17 une identification de synchronisation des signaux définissant une cohérence fonctionnelle entre les différents signaux, ainsi qu'une coordination entre les signaux et les liens physiques devant être fabriqués pour transporter ces signaux entre les différents modules 7.

Les liens physiques devant être fabriqués comportent des câbles comprenant chacun une pluralité de connecteurs correspondant à la pluralité de liens 9 interconnectant les interfaces. Ainsi, on définit dans la base de données 17 une identification de brochage et une correspondance entre chaque signal et le connecteur configuré pour transmettre ce signal.

Plus particulièrement, les moyens de traitement 11 sont adaptés pour implémenter dans la base de données 17, les demandes de modification CN afin d'engendrer comme résultat, des paramètres ou identifiants des signaux AC ICD (Aircraft Inter Communication Data). Ces identifiants AC ICD définissent les informations logiques des signaux ainsi que la correspondance entre les signaux et les liens physiques à installer entre les modules 7. Autrement dit, un identifiant AC ICD qui résulte de la base de données 17, identifie le signal et le connecteur devant transporter ce signal ainsi que les modules 7 émetteur et récepteur du signal. Avantageusement, les signaux sont définis en s'assurant que chaque signal possède les mêmes caractéristiques entre le module émetteur et le module récepteur. On notera qu'un signal peut être un état binaire ou une mesure analogique (par exemple, une tension, une température, une fréquence, etc.). Les caractéristiques d'un signal comportent la longueur du message, le format, le média utilisé (discret, analogique, bus CAN, ARINC, AFDX, etc.). Ainsi, la possession des mêmes caractéristiques entre l'émetteur et le récepteur garantit un bon échange et aucune perte de messages. Par ailleurs, on notera qu'une mise à jour continuelle de la base de données 17 est réalisée pour inclure toute évolution fonctionnelle et/ou physique des interfaces et signaux selon l'évolution des demandes de modifications.

Ainsi, la deuxième étape permet de coordonner de manière évolutive la définition fonctionnelle ou logique avec la définition physique de l'installation du système de communication 3. Elle permet aussi d'établir un cadencement qui sert de référentiel à équipes développant les différents

E3, les moyens de traitement 11 sont utiliser des programmes informatiques pour vérifier avant la réalisation des tests de maturation du système de communication 3, la cohérence d'interface pour tous les signaux de la base de données 17. Autrement dit, on vérifie la cohérence de contenu, de synchronisation, et d'interface pour 15 tous les signaux de la base de données 17 en utilisant les identifiants des signaux AC ICD. Cette troisième étape permet de définir la cohérence technique à atteindre à chaque jalon du développement de l'aéronef et d'établir un procédé 20 industriel permettant de satisfaire les caractéristiques techniques tout en tenant compte des paramètres calendaires du développement de l'aéronef. Ainsi, la présente invention permet d'associer entre elles les fonctions qui doivent être testées, les 25 demandes de modifications CN permettant d'obtenir la définition technique de l'aéronef en développement 5 assurant ces fonctions, et le timing des tests de maturation afin de synchroniser l'ensemble des opérations permettant de livrer cette définition 30 technique de l'aéronef ainsi que d'identifier tout écart par rapport à ce qui était prévu afin de garantir toutes les modules 7. A l'étape configurés pour de vérification une bonne communication entre les modules 7 au moment des tests de maturation. On notera que la base de données 17 est construite de manière successive pour correspondre à l'évolution des tests de maturations successives en identifiant les demandes de modifications pertinentes pour chaque étape de tests de maturation. En effet, chaque étape de tests de maturation comprend de manière évolutive un ensemble de fonctions à tester où chaque fonction est configurée pour déclencher un ensemble de signaux représentatifs de cette fonction. Ainsi, la base de données 17 devient de plus en plus grande après chaque étape des tests de maturation. Les tests de maturation consistent alors à vérifier le bon échange des signaux entre les différents modules 7, et à évaluer le bon fonctionnement des différents modules 7 ou équipements de l'aéronef en développement 5. La Fig. 2 est un schéma illustrant un exemple 20 particulier du procédé de synchronisation du système de communication, selon l'invention. Initialement, il s'agit d'identifier une liste de fonctions à tester définissant chaque étape de tests de maturation (ou standard) 21 de l'aéronef en 25 développement 5. Les principaux étapes de tests comportent un standard préliminaire SO pour des tests sur simulateurs, un premier standard S1 pour une mise en tension de l'aéronef (Power On A/C), un deuxième standard S2 pour le premier vol (First Flight), et un 30 troisième standard S3 pour la certification.

Ainsi, des premières étapes de tests SO peuvent être simulées sur des Bancs d'intégration fonctionnelle FIB (Functional Integrated Test Benches) pour simuler des tests fonctionnels des cabines, des trains d'atterrissage, etc.. D'autres étapes de tests S1, S2, S3 peuvent être réalisées sur l'aéronef ou plus généralement sur plusieurs numéros de série d'aéronefs, comme par exemple, la mise sous tension de l'aéronef S1, le premier vol S2, ou la certification de l'aéronef S3. Ensuite, il s'agit de définir le contenu technique exigé à chaque étape de tests de maturation et de veiller à la bonne synchronisation. Pour cela, cette phase consiste à définir la liste des demandes de modifications CN 23 requises définissant l'évolution des caractéristiques techniques des différents éléments de l'aéronef en développement 5 pour réaliser les fonctions à tester et pour implémenter les CN 23. On identifie la priorité des demandes de modifications CN par rapport au planning de l'étape des tests de maturation 21. La phase d'implémentation consiste à intégrer les demandes de modifications CN dans un document d'interfaces des systèmes SID (System Interface Document) 25 et dans des diagrammes fonctionnels FD (Functional Diagrams) 27. Les SID et FD correspondent à la définition fonctionnelle de l'aéronef en développement 5. Plus particulièrement, le SID décrit le type d'information logique (état logique, tension, température, fréquence,...) et le type de média (signal discret, analogique, bus CAN, Arinc, AFDX). Les FD définissent des correspondances entre les signaux et les harnais de câblage à fabriquer. Les SID et FD sont utilisés pour construire la base de données 17 d'identification et de synchronisation.

Plus particulièrement, cette base de données 17 est construite à partir d'une interdépendance entre plusieurs processus comportant des données de communication inter-systèmes ISCD (Inter System Communication Data) 29, un document d'exigence de câblage SWRD (Wiring Requirement Document) 31, et un module intégré avionique IMA (Integrated Module Avionic) 33. Le processus ISCD a pour objectif de s'assurer la bonne communication entre l'ensemble des systèmes ou modules 7 de l'aéronef en développement 5 (environ une soixantaine de systèmes) sachant que les informations logiques des signaux sont décrites dans le document d'interfaces des systèmes SID. Le livrable majeur de l'ISCD est l'identifiant 35 aéronef AC ICD.

Le processus SWRD permet d'établir des plans qui serviront à réaliser le câblage qui sera installé dans l'aéronef. Le livrable principal du processus SWRD est le diagramme fonctionnel FD qui est également importé dans les données ISCD et est donc une entrée pour la réalisation de l'identifiant AC ICD. Enfin, le processus IMA assure une communication intelligente entre les modules 7 ou systèmes en s'appuyant sur deux types d'équipements, les modules concentrateurs de données cRDC et les modules intégrateurs de traitement de données CPIOM. Ces équipements cRDC et CPIOM assurent les conversions des signaux d'un protocole à un autre et réalisent des fonctions de traitement. Pour définir la configuration des cRDC et CPIOM, le processus IMA a besoin des données fournies par les processus ISCD et SWRD. Ainsi, pour la configuration de l'IMA, les demandes de modifications CN sont aussi intégrées lors de la phase d'implémentation au niveau de l'IMA. Les trois processus ISCD, SWRD et IMA sont étroitement liés et interdépendants. La particularité du processus ISCD est qu'il intègre les données des deux autres processus SWRD et IMA. Il fournit des AC ICD qui permettent la spécification des communications entre les modules 7 et la spécification des bancs de tests. En effet, les identifiants AC ICD contiennent la partie logique des signaux (en provenance du SID) et la partie physique (c'est-à-dire, sur quel harnais, venant des FD). En particulier, les AC ICDs contiennent la localisation de l'information pour chaque pin de chaque connecteur (pin allocation) fournie par l'IMA et le SWRD. L'interdépendance entre les processus ISCD, SWRD et IMA permet d'assurer la cohérence technique simultanée entre ces trois processus. A titre d'exemple, pour un processus SWRD qui fournit environ 1400 FD, le processus ISCD collecte 850 SID et l'ensemble de ces fichiers permettent de définir 1200 AC ICD. De plus, parmi les modules 7 ou systèmes s'appuyant sur le processus ISCD, on trouve des systèmes dits intégrateurs comme par exemple, le système d'alarme FWS (Flight Warning System) et le système d'affichage de la cabine d'équipage CDS (Cockpit Display System). Ce sont des systèmes majeurs, qui concentrent un très grand nombre de signaux d'aéronef.

Après la construction de la base de données 17 définissant les informations logiques et physiques des signaux et la synchronisation des signaux entre eux et avec les harnais à fabriquer, il s'agit maintenant de vérifier qu'il n'y a pas d'incompatibilité entre les interfaces des différents modules 7 pour chaque étape des tests de maturation. Pour cela, on peut utiliser un outil informatique de vérification de cohérence 37 du type CCT (Consistency Check Tool) pour vérifier l'incohérence entre les interfaces pour tous les signaux. Le nombre de vérifications peut être de l'ordre de plusieurs dizaines de millions. Les incohérences par rapport à la définition technique sont identifiées et analysées en utilisant les identifiants AC ICD. Les résultats d'analyse peuvent être synthétisés dans un tableau d'analyse 39 de cohérence ou d'incompatibilité. La Fig. 3 illustre un exemple d'un tableau d'analyse de cohérence pour les tests de maturation de simulation (standard SO). Ce tableau 39 comporte une première colonne cl indiquant un numéro d'incohérence, une deuxième colonne c2 indiquant le module émetteur, une troisième colonne c3 indiquant le module récepteur, une quatrième colonne c4 indiquant la description du problème de communication, une cinquième colonne c5 indiquant l'impact de ce problème, et enfin une sixième colonne c6 indiquant l'analyse ou le statut du problème. Cette analyse permet d'identifier et de découvrir chaque incohérence afin de décider s'il est acceptable ou non avant que les tests de maturation débutent.

Par exemple, la première ligne indique que le module émetteur est le WIPS (Wing Ice Protection System) et le module récepteur est le CDS. La description du problème indique un rallongement de la longueur du message WIPS par rapport aux hypothèses prises par CDS. L'impact de ce problème indique qu'il n'existe pas de message reçu à ce stade et que la compatibilité avec l'interface du CDS sera réalisée lors de la définition du CDS pour les tests de maturation S1. L'analyse du problème indique qu'il n'y a pas d'affichage du signal WIPS avant la définition du standard S1 du CDS. La deuxième ligne indique que le module émetteur est le WIPS et le module récepteur est le FWS. La description du problème indique un rallongement de la longueur du message émis par WIPS. L'impact de ce problème indique qu'il existe une liste de signaux qui ne seront pas reçus par le FWS. L'analyse du problème indique qu'il n'y a aucun impact car les alarmes en provenance du WIPS ne sont pas définies dans le standard SO et peuvent être introduites et éventuellement corrigées pour le standard S1. Ainsi, la phase de vérification permet de s'assurer de la cohérence des interfaces entre les modules 7, avant l'échange des signaux lors des tests de maturation.

La Fig. 4 est un schéma illustrant l'ensemble des étapes couvertes par la vérification et les tests de maturation du système de communication. Dans ce cas, il s'agit de définir aussi la maquette numérique DMU (Design Mock-Up) 41. La DMU est établie à partir d'un document d'exigence d'installation des équipements EIRD (Equipement Installation Requirement Document) et d'un document d'exigence d'installation des systèmes SIRD (System Installation Requirement Document) 43. Afin de définir le contenu technique exigé à chaque étape de tests de maturation, les demandes de modifications CN sont intégrées lors de la phase d'implémentation dans les EIRD et SIRD pour l'installation, en plus de leurs intégrations au niveau des FD pour la partie physique, au sein des SID pour la partie logique, et au niveau de l'IMA. On notera que les identifiants AC ICD livrés principalement par l'ISCD, servent comme spécifications pour l'implantation des logiciels avioniques, comme entrée pour configurer les bancs de tests 45 qui sont adaptés pour utiliser ces logiciels, et enfin pour l'assemblage final de l'aéronef FAL (Final Assembly Line) 47.

La DMU permet de faire designer l'ensemble des éléments constitutifs de l'aéronef en développement et de les installer ensemble sans accrochage (clash). Cette étape peut s'effectuer en CAO avec par exemple, un logiciel d'application tridimensionnel de type CATIA. Une fois l'installation finalisée, les plans des pièces 49 peuvent être réalisés pour fabriquer l'ensemble des pièces élémentaires et les sous-ensembles 51 de l'aéronef. En outre, les FD permettent de réaliser les plans de câblage 53 pour fabriquer les harnais 55. Ainsi, l'ensemble des pièces 51 et harnais 55 seront assemblés lors de l'assemblage final 47 de l'aéronef FAL. Comme précédemment, après la vérification 37 des cohérences et éventuellement la correction des interfaces ou connexions entre les modules du système de communication, on peut procéder dans de bonnes conditions aux tests de maturation sur des bancs de test 45 ou sur l'aéronef 57 selon la phase de développement de l'aéronef.

Claims (10)

1. REVENDICATIONS1. Procédé de vérification d'un système de communication (3) comprenant une pluralité de modules (7) adaptés pour être installés dans un aéronef en développement (5), caractérisé en ce que ledit procédé comporte les étapes suivantes : - construire une base de données (17) d'identification et de synchronisation dudit système de communication (3), ladite base de données définissant contractuellement des interfaces entre ladite pluralité de modules (7) à partir des demandes de modification par rapport à une définition technique initiale, - définir dans ladite base de données (17), des signaux configurés pour être échangés entre ladite pluralité de modules (7) via une pluralité de liens (9) interconnectant lesdites interfaces, lesdits signaux étant définis pour être synchronisés entre eux ainsi qu'avec la matérialisation physique desdits liens, et - vérifier, avant une évaluation d'un test de maturation du système de communication (3), une cohérence d'interface pour tous lesdits signaux de ladite base de données (17).
2. 2. Procédé selon la revendication 1, caractérisé en ce que la base de données (17) comporte une identification de synchronisation des signaux entre lesdits modules.30
3. 3. Procédé selon la revendication 2, caractérisé en ce que ladite identification de synchronisation définit une cohérence fonctionnelle entre lesdits signaux, et une coordination entre les signaux et des liens physiques configurés pour transporter lesdits signaux.
4. 4. Procédé selon la revendication 3, caractérisé en ce que les liens physiques comportent des câbles comprenant chacun une pluralité de connecteurs correspondant à ladite pluralité de liens interconnectant lesdites interfaces, et en ce que la base de données (17) comporte une identification de brochage et une correspondance entre chaque signal et le connecteur configuré pour transmettre ledit signal.
5. 5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que les signaux sont définis en s'assurant que chaque signal possède des mêmes caractéristiques entre un module émetteur et un module récepteur.
6. 6. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce qu'il comporte une mise à jour continuelle de la base de données (17) pour inclure toute évolution fonctionnelle et/ou physique des interfaces et signaux.
7. 7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce qu'il comporte une construction successive de ladite base de données(17) correspondant à des étapes de tests de maturation successives, chaque test de maturation comprenant, de manière évolutive, un ensemble de fonctions à tester où chaque fonction est configurée pour déclencher un ensemble de signaux représentatifs de ladite fonction.
8. 8. Procédé selon la revendication 7, caractérisé en ce que lesdits tests de maturation comportent : des tests fonctionnels, des tests de simulations, et des tests sur l'aéronef.
9. 9. Procédé selon la revendication 7 ou 8, caractérisé en ce que chaque test de maturation consiste à vérifier les signaux échangés entre les différents modules, et à évaluer le bon fonctionnement des différents modules de l'aéronef.
10. 10. Dispositif de vérification d'un système de communication (3) comprenant une pluralité de modules (7) adaptés pour être installés dans un aéronef en développement (5), caractérisé en ce que ledit dispositif de vérification comporte : - des moyens (11) pour construire une base de données (17) d'identification et de synchronisation dudit système de communication (3), ladite base de données définissant contractuellement des interfaces entre ladite pluralité de modules à partir des demandes de modification par rapport à une définition technique initiale, - des moyens (11) pour définir dans ladite base de données (17), des signaux configurés pour êtreéchangés entre ladite pluralité de modules (7) via une pluralité de liens (3) interconnectant lesdites interfaces, lesdits signaux étant définis pour être synchronisés entre eux ainsi qu'avec la matérialisation physique desdits liens, et - des moyens (11) pour vérifier avant une évaluation d'un test de maturation du système de communication (3), une cohérence d'interface pour tous lesdits signaux de ladite base de données (17).10