FR2973131A1 - Procede et dispositif de detection d'incompatibilites d'interfaces logiques d'equipements de systemes embarques - Google Patents

Abstract

L'invention a notamment pour objet la détection d'incompatibilité entre des équipements d'un système embarqué. Une interface logique associée à un équipement comprend au moins une entrée tandis qu'une interface logique associée à un autre équipement comprend au moins une sortie. L'entrée et la sortie sont connectées. Après avoir obtenu (505) un niveau de définition minimal de données associé à l'entrée et un niveau de définition de données associé à la sortie, ledit niveau de définition minimal de données associé à l'entrée est comparé (515) avec ledit niveau de définition de données associé à la sortie. Suite à cette comparaison, si ledit niveau de définition minimal de données associé à l'entrée est inférieur audit niveau de définition de données associé à la sortie, une alarme indiquant une incompatibilité de ces deux équipements est générée (545).

Description

La présente invention concerne la compatibilité de calculateurs et d'applications logicielles dans un système embarqué et plus particulièrement un procédé et un dispositif de détection et de signalisation d'incompatibilités d'interfaces logiques d'équipements d'un système embarqué, notamment de calculateurs et d'applications logicielles embarqués dans des aéronefs.

Les aéronefs modernes comprennent de plus en plus de systèmes électroniques et informatiques pour améliorer leurs performances et assister le pilote ainsi que les membres d'équipage lors de leurs missions. Ainsi, par exemple, les commandes de vol électriques permettent de réduire la complexité mécanique de la transmission des commandes aux actuateurs et donc la masse associée à ces commandes. De même, la présentation d'informations pertinentes permet au pilote d'optimiser les trajectoires de vol et de répondre rapidement à tout incident détecté. De telles informations sont notamment la vitesse, la position, le cap, des données de météorologie et de navigation. L'ensemble de ces systèmes électroniques et informatiques est généralement appelé l'avionique. Pour des raisons de fiabilité, l'avionique a souvent été répartie de façon fonctionnelle par modules spécifiques, aussi appelé LRU (sigle de Line Replaceable Unit en terminologie anglo-saxonne). Selon cette architecture, un mode de transmission point à point est utilisé entre chaque module. Ainsi, par exemple, les commandes de vol sont gérées dans un dispositif particulier tandis que l'alimentation électrique est gérée dans un autre. Une fonction spécifique est ainsi associée à chaque module. Par ailleurs, chaque module supportant une fonction critique est, de préférence, redondant de telle sorte que la défaillance d'un module n'entraîne pas la perte de la fonction associée. L'exploitation d'un aéronef utilisant un module redondant lorsque le module principal est défaillant peut nécessiter une opération de maintenance.

Afin d'améliorer les fonctionnalités des aéronefs, réduire le poids des équipements électroniques grâce à une plus grande intégration, réduire les coûts grâce à l'utilisation de modules génériques, et faciliter les opérations de maintenance, l'avionique est maintenant de plus en plus intégrée selon une architecture appelée IMA (sigle d'lntegrated Modular Avionics en terminologie anglo-saxonne). Selon cette architecture, les fonctionnalités des systèmes avioniques utilisent autant que possible des ressources génériques de calcul et d'entrées/sorties dans lesquels elles sont implémentées. Ces ressources sont réparties dans des équipements électroniques qui comprennent chacun de nombreux modules logiciels. Un système de ségrégation ou de partitionnement permet d'isoler chacune des fonctionnalités de telle sorte que la défaillance d'une fonction n'ait pas d'influence sur une autre. A titre d'illustration, la demande de brevet FR 2 903 511 décrit une telle architecture.

Au sein de chaque équipement électronique de l'aéronef, des modules logiciels sont chargés et mis à jour par un opérateur qui se trouve à bord de l'aéronef pour effectuer ces opérations. Le rôle de l'opérateur est notamment de lancer le chargement de ces modules ou de ces mises à jour et de vérifier que la configuration sélectionnée a été convenablement chargée dans l'équipement électronique. Suite à l'occurrence d'une panne d'un module embarqué, matériel ou logiciel, des opérateurs de maintenance sont souvent conduits à remplacer l'équipement électronique comprenant ce module, dans sa globalité, pour réparer la panne. Lors de ces opérations, il arrive fréquemment que l'équipement de remplacement, provenant d'un stock de rechanges, ait une version (aussi appelée Part Number en terminologie anglo-saxonne) différente de celle de l'équipement remplacé (équipement en panne). Le remplacement ne peut donc être effectué dans l'aéronef sans vérification de compatibilité avec les autres équipements avec lesquels cet équipement doit communiquer.

A ces fins, les opérateurs de maintenance utilisent des informations de compatibilité et de configurations autorisées des divers équipements, appelées informations de mixabilité (ou mixability en terminologie anglo- saxonne), dans une documentation de maintenance du constructeur, par exemple dans une documentation appelée IPC (sigle d'lllustrated Parts Catalog en terminologie anglo-saxonne). Lorsque la configuration résultant de la combinaison de la version de l'équipement de remplacement avec les versions d'autres équipements, communiquant avec cet équipement de remplacement, n'est pas définie dans les documentations utilisées, les opérateurs de maintenance doivent faire appel au constructeur pour autoriser ou non la configuration inconnue. Ainsi, il existe un besoin de vérifier que la configuration d'équipements d'un aéronef, en particulier suite au remplacement de l'un d'eux, est conforme aux configurations autorisées. Une telle vérification a pour objet de garantir que, suite à une opération de remplacement, un équipement non autorisé n'est pas installé par erreur et que cette erreur ne peut pas engendrer de pannes, de par l'incompatibilité de cet équipement de remplacement avec ceux présents dans l'aéronef. Concernant les dispositifs physiques, en particulier pour les connecteurs, il existe des mécanismes de détrompage empêchant une connexion ou une installation d'un équipement non conforme. Cependant, un tel problème de vérification de configuration concerne également le téléchargement par erreur, dans un ou plusieurs calculateurs embarqués, d'une version d'applications logicielles non attendues ou non conformes à la configuration, c'est-à-dire, par exemple, au téléchargement d'une application logicielle dont la version est incompatible avec celles d'autres applications logicielles installées ou d'autres équipements.

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é pour ordinateur de détection d'incompatibilité entre au moins deux équipements d'un système embarqué, ce procédé étant caractérisé en ce que, une interface logique associée à l'un desdits au moins deux équipements comprenant au moins une entrée et une interface logique associée à l'autre desdits au moins deux équipements comprenant au moins une sortie, ladite au moins une entrée étant connectée à ladite au moins une sortie, le procédé comprend les étapes suivantes, - obtention d'un niveau de définition minimal de données associé à ladite au moins une entrée dudit un desdits au moins deux équipements et d'un niveau de définition de données associé à ladite au moins une sortie dudit autre desdits au moins deux équipements ; - comparaison dudit niveau de définition minimal de données associé à ladite au moins une entrée dudit un desdits au moins deux équipements avec ledit niveau de définition de données associé à ladite au moins une sortie dudit autre desdits au moins deux équipements ; et, - en réponse à ladite étape de comparaison, si ledit niveau de définition minimal de données associé à ladite au moins une entrée dudit un desdits au moins deux équipements est inférieur audit niveau de définition de données associé à ladite au moins une sortie dudit autre desdits au moins deux équipements, génération d'une alarme indiquant une incompatibilité desdits au moins deux équipements. Le procédé selon l'invention permet ainsi de déterminer de façon simple, rapide et automatique l'incompatibilité entre des équipements d'un système embarqué à partir de données caractéristiques de leurs interfaces, pouvant être aisément obtenues, notamment lorsque les équipements sont opérationnels. Selon un mode de réalisation particulier, ladite étape d'obtention comprend l'obtention, pour chaque équipement dudit système embarqué dont l'incompatibilité avec un autre équipement est analysée, d'un niveau de définition minimal de données associé à chaque entrée de l'équipement considéré, ladite étape de comparaison étant effectuée pour chaque niveau de définition minimal obtenu. Le procédé selon l'invention permet ainsi de déterminer l'incompatibilité d'un équipement avec plusieurs autres auxquels il est relié selon des données caractéristiques de leurs interfaces.

De façon avantageuse, ladite étape d'obtention comprend en outre l'obtention, pour chaque équipement dudit système embarqué transmettant au moins une donnée à un desdits équipements dont l'incompatibilité avec un autre équipement est analysée, d'un niveau de définition de données associé à au moins une sortie de l'équipement considéré pour faciliter la détermination de l'incompatibilité entre les équipements considérés. Selon un mode de réalisation particulier, le procédé comprend en outre une étape de sélection d'équipements dudit système embarqué dont l'incompatibilité avec d'autres équipements est analysée, ladite sélection étant déterminée selon un niveau de criticité des équipements dudit système embarqué. L'incompatibilité des équipements est ainsi déterminée de façon optimale.

Le procédé comprend en outre, de préférence, une étape de transmission d'un identifiant dudit un desdits au moins deux équipements et dudit autre desdits au moins deux équipements si ledit niveau de définition minimal de données associé à ladite au moins une entrée dudit un desdits au moins deux équipements est inférieur audit niveau de définition de données associé à ladite au moins une sortie dudit autre desdits au moins deux équipements. Le procédé selon l'invention permet ainsi d'identifier aisément les équipements incompatibles. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de transmission d'au moins ladite alarme générée à un système de traitement de l'information centralisé distinct dudit système embarqué. Le procédé selon l'invention permet ainsi de détecter à distance des problèmes d'incompatibilité d'équipements d'un système embarqué. Le procédé comprend en outre, de préférence, une étape préalable de transmission d'au moins une requête, ledit niveau de définition minimal de données associé à ladite au moins une entrée dudit un desdits au moins deux équipements et ledit niveau de définition de données associé à ladite au moins une sortie dudit autre desdits au moins deux équipements étant obtenu en réponse à ladite requête. Le procédé selon l'invention permet ainsi de déterminer l'incompatibilité entre des équipements d'un système embarqué sur demande.

De façon avantageuse, lesdites étapes d'obtention, de comparaison et de génération d'une alarme en réponse à ladite étape de comparaison sont effectuées de façon périodique selon un état associé audit système embarqué. Le procédé selon l'invention permet ainsi de déterminer l'incompatibilité entre des équipements d'un système embarqué de façon automatique et régulière. Toujours selon un mode de réalisation particulier, ledit niveau de définition minimal de données associé à ladite au moins une entrée dudit un desdits au moins deux équipements et ledit niveau de définition de données associé à ladite au moins une sortie dudit autre desdits au moins deux équipements sont reçus sous forme de trames de type UDP. 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 et un aéronef comprenant un tel dispositif. Les avantages procurés par ce programme d'ordinateur, ce dispositif et cet aéronef sont similaires à ceux évoqués précédemment. D'autres avantages, buts et caractéristiques de la présente invention 20 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, comprenant les figures la et 1 b, illustre, de façon partielle, un système embarqué d'un aéronef ; - la figure 2 illustre de façon schématique un équipement ainsi 25 qu'une liste correspondante de versions de définition de données d'entrée et de sortie de cet équipement ; - la figure 3 illustre schématiquement certaines étapes mises en oeuvre dans un équipement pour générer et transmettre une liste de versions de définition pour des données d'entrée et de sortie d'un équipement ; 30 - la figure 4, comprenant les figures 4a et 4b, illustre des exemples de trame UDP pouvant être utilisées pour transmettre une liste de versions de définition pour des données d'entrée et de sortie d'un équipement, via un réseau de communication ; - la figure 5 illustre des étapes d'un exemple d'algorithme selon l'invention pour déterminer si la configuration d'un système embarqué est admissible ou, au contraire, si elle n'est pas correcte ; - la figure 6 illustre un exemple de mise en oeuvre de l'algorithme décrit en référence à la figure 5 ; et, - la figure 7 illustre un exemple de dispositif de traitement d'informations adapté à mettre en oeuvre, au moins partiellement, l'invention.

De façon générale, l'invention a pour objet la détection et la signalisation d'incompatibilités de modules, matériels ou logiciels, d'un système embarqué, notamment dans des aéronefs. Cette détection et signalisation d'incompatibilités utilise ici la détection d'incompatibilités entre des interfaces logiques de calculateurs et/ou d'applications logicielles, génériquement appelés équipements dans la suite de la description. De tels équipements peuvent appartenir à l'avionique, à un système du monde ouvert ou à tout autre domaine de sécurité de l'aéronef. Il est tout d'abord observé qu'une incompatibilité entre des équipements résulte des interfaces entre ces équipements. En d'autres termes, si des équipements deviennent incompatibles, c'est que les informations échangées entre ces équipements ont évolué. Par conséquent, la maîtrise des interfaces entre des équipements permet de maîtriser les incompatibilités entre ces équipements. En effet, il est admis ici qu'une évolution interne d'un équipement ayant une répercussion sur un équipement qui lui est lié suppose que cette évolution interne se propage d'une façon ou d'une autre par les sorties de l'équipement qui a évolué. Par ailleurs, il est observé que depuis de nombreuses années, certains constructeurs d'aéronefs portent une attention particulière sur les évolutions des équipements. Ainsi, tout au long du développement des équipements embarqués, ainsi que pour toute modification de ces équipements après l'entrée en service d'un aéronef, les évolutions des interfaces mécaniques, physiques et logiques entre calculateurs et/ou applications logicielles sont étudiées et agréées. Les agréments entre des équipements émetteurs de données et d'autres équipements consommateurs de données peuvent notamment être contractualisés dans un document souvent appelé SID (sigle de System Interface Description en terminologie anglo-saxonne).

En outre, une description technique des données échangées, comprenant typiquement une description des sorties physiques (par exemple les formats des connecteurs) et des sorties logiques (par exemple un type tel qu'un entier, booléen ou flottant, des valeurs minimum, maximum, une résolution et un mode de codage), est mémorisée dans une base de données centralisée. Cette dernière est, de préférence, utilisée pour stocker des informations relatives à toutes les sorties de tous les équipements embarqués dans les aéronefs d'un programme donné. Une telle base de données peut également contenir les liens entre les équipements producteurs de données et les équipements consommateurs de ces données, représentant des abonnements, c'est-à-dire le résultat de la contractualisation de l'interface à travers le SID d'un équipement aux sorties d'un autre. Typiquement, les évolutions des caractéristiques des sorties d'un équipement entraînent une renégociation du contrat d'entente sur l'interface entre les équipements (nouvelle édition du SID et capture des caractéristiques modifiées dans la base de données centralisée). En outre, pour fixer les définitions des interfaces des équipements, typiquement des calculateurs, afin, notamment, de permettre à des fournisseurs de ces équipements de travailler avec des spécifications d'entrées stables, les évolutions des caractéristiques des sorties des équipements et des abonnements sont, de préférence, orchestrées de manière synchronisée : les évolutions sont groupées pour être traitées par lots (traitement batches). En d'autres termes, tous les équipements concernés par un changement de niveau de définition, appelé TRAITEMENT dans la suite de la description, évoluent ensemble à un même moment. Des extraits de la base de données centralisée après finalisation des modifications des interfaces (caractéristiques des informations émises et abonnements) sont obtenus après chaque TRAITEMENT. Ces extraits de la base de données, pour un équipement donné, définissant à la fois ses sorties et ses entrées, sont appelés ICD (sigle d'Interface Control Document en terminologie anglo-saxonne) et sont archivés après chaque TRAITEMENT. Il y a, par exemple, un TRAITEMENT par mois pour un programme donné de développement d'un aéronef. Ces TRAITEMENTS sont typiquement numérotés de façon incrémentale, par exemple de 001 à 999. Ainsi, un TRAITEMENT (ou TRT) représente un niveau (ou une version) de définition d'une interface d'une ou de plusieurs entrées et/ou sorties. Des concepteurs peuvent ainsi fixer une spécification d'interfaces d'un équipement (pour un standard donné de cet équipement, définissant un niveau de développement de celui-ci) en livrant à leur fournisseur l'ICD à un niveau de version donné, représentatif des caractéristiques des données calculées et émises en relation avec les fonctions implémentées dans l'équipement (selon son standard).

La figure 1, comprenant les figures la et 1 b, illustre une partie d'un système embarqué d'un aéronef, comprenant ici quatre équipements. Comme illustré sur la figure la, le système embarqué 100 comprend un premier équipement référencé 105-1 consistant ici en un système de contrôle et d'affichage (aussi appelé CDS, sigle de Control and Display System en terminologie anglo-saxonne) au standard (noté STD) Cl b, recevant des données d'un deuxième équipement référencé 105-2 consistant ici en un système d'information de type ADIRU (acronyme d'Air Data Inertial Reference Unit en terminologie anglo-saxonne) au standard A4 et d'un troisième équipement référencé 105-3 consistant ici en un système de gestion de vol (aussi appelé FMS, sigle de Flight Management System en terminologie anglo-saxonne) au standard F12. Comme illustré, le système de gestion de vol 105-3 reçoit des données de l'ADIRU 105-2 et d'un quatrième équipement référencé 105-4 consistant ici en un système de gestion radio (aussi appelé RMP, sigle de Radio Management Panel en terminologie anglo-saxonne) au standard Rm20.

Les équipements 105-1 à 105-4 ont défini et agréé leurs interfaces à un TRAITEMENT donné, c'est-à-dire à un niveau de définition donnée, ici le TRAITEMENT No. 030 (TRT_030). Ainsi, si le FMS 105-3 évolue pour implémenter une nouvelle fonction pour laquelle il a besoin de nouvelles informations en provenance de l'ADIRU 105-2, les équipements 105-2 et 105-3 doivent convenir d'une nouvelle interface qui peut être finalisée au cours d'un TRAITEMENT ultérieur, par exemple le TRAITEMENT No. 035 (TRT_035). Dans ce cas, si l'interface de sortie de l'ADIRU 105-2 vers le CDS 105-1 et l'interface de sortie du FMS 105-3 vers le CDS 105-1 ne sont pas affectées par l'implémentation des nouvelles fonctions dans les équipements 105-3 et 105-2, le CDS 105-1 est compatible avec les interfaces de sortie des équipements 105-2 et 105-3 du nouveau TRAITEMENT No. 035. En référence à la figure 1 b, représentant un système embarqué 100' similaire (au standard des équipements près) au système embarqué 100 de la figure la, il est considéré que l'ADIRU 105'-2, au standard A5, tombe en panne et est remplacé par un équipement équivalent mais au standard A4 dont l'interface de sortie correspondant au TRAITEMENT No. 030 ne donne pas accès à des informations nécessaires au fonctionnement du FMS 105'-3 au standard F13. Ainsi, la configuration résultante comprenant le FMS 105'-3 au standard F13 et un ADIRU équivalent à l'ADIRU 105'-2 mais au standard A4 n'est pas correcte. Si, au contraire, le FMS 105'-3 au standard F13, bien qu'ayant besoin des informations de l'ADIRU 105'-2 au standard A5 avec une interface de sortie correspondant au TRAITEMENT No. 035 est capable, suite à l'absence des informations introduites dans ce TRAITEMENT, de passiver ou réduire les nouvelles fonctions à un mode sécurisé acceptable d'un point de vue opérationnel, la configuration résultante comprenant le FMS 105'-3 au standard F13 et un ADIRU équivalent à l'ADIRU 105'-2 mais au standard A4 est admissible. Pour déterminer si une configuration est admissible ou, au contraire, n'est pas correcte, chaque équipement pouvant être mis en cause définit, pour chacun de ses standards, la référence de TRAITEMENT minimal nécessaire, c'est-à-dire le niveau minimal de définition, qu'il attend pour chacune de ses entrées (données venant d'autres équipements). Il est admis ici que si un équipement d'un standard donné défini ses entrées relatives à un autre équipement selon une référence de TRAITEMENT donné, un standard supérieur de cet équipement doit définir ses entrées relatives à cet autre équipement selon une référence de TRAITEMENT donné qui ne peut être antérieur à la référence de TRAITEMENT liée au standard donné. En d'autres termes, les retours en arrière (pour des références TRAITEMENT, ou niveau de définition) sont ici exclus. Ainsi, conformément à l'invention, il est nécessaire d'obtenir, pour chaque équipement concerné, une liste visant des références de TRAITEMENT minimal pour chacune des données d'entrée et de références de TRAITEMENT pour chacune des données de sortie de l'équipement. Néanmoins, il est observé ici qu'en pratique, il n'est généralement pas nécessaire de recourir à plusieurs références de TRAITEMENT pour des données de sortie. Ainsi, typiquement, une seule référence de TRAITEMENT est utilisée pour l'ensemble des sorties d'un équipement. La figure 2 illustre de façon schématique un équipement 200 ainsi que la liste 205 correspondante de références de TRAITEMENT minimal pour les données d'entrée et de références de TRAITEMENT pour les données de sortie de cet équipement. L'équipement 200, dénommé équipement « EQPMT(X) », au standard XXX, comprend ici quatre entrées référencées 210-1 à 210-4 ainsi 25 qu'une sortie référencée 215. Comme indiqué, l'entrée 210-1 correspond à une sortie d'un équipement de type ADIRU dont la référence de TRAITEMENT minimal est 030 (ADIRU TRTInmin = 030). De même, l'entrée 210-2 correspond à une sortie d'un équipement de type FMS dont la référence de TRAITEMENT minimal est 30 035 (FMS TRTINmin = 035). De façon similaire encore, les entrées 210-3 et 210-4 correspondent chacune à une sortie d'un équipement EQPMTA et EQPMTB dont la référence de TRAITEMENT minimal est aaa et bbb, respectivement (EQPMTA_TRTINmin = aaa et EQPMTB TRTINmin = bbb). L'unique sortie 215 de l'équipement 200 correspond ici à une référence de TRAITEMENT égale à 040 (EQPMT(X)_TRTOUT = 040).

La liste 205 comprend la référence de TRAITEMENT de sortie de l'équipement 200 ainsi que la référence de TRAITEMENT minimal de chacune de ses entrées (EQPMT(X)_TRTOUT = 040, EQPMTA_TRTINmin = aaa, EQPMTB TRTINmin = bbb, ADIRU TRTInmin = 030, FMS TRTINmin = 035). Comme décrit ci-dessous, une telle liste peut être transmise via un réseau de communication, par exemple un réseau de type AFDX (sigle d'Avionics Full DupleX en terminologie anglo-saxonne), sous la forme de trames. Selon un mode de réalisation particulier, une application est en charge de déterminer toutes ou une partie des listes visant les références de TRAITEMENT minimal pour les données d'entrée et les références de TRAITEMENT pour les données de sortie des équipements du système embarqué. Ces listes sont avantageusement construites à partir des données issues d'une base de données centralisée telle que celle décrite précédemment.

Alternativement, selon un autre mode de réalisation, une fonction est mise en oeuvre dans chaque équipement concerné pour générer une liste telle que celle décrite en référence à la figure 2. Des étapes d'une telle fonction sont décrites en référence à la figure 3. Après avoir reçu une requête (étape 300) pour émettre une liste visant les références de TRAITEMENT minimal pour les données d'entrée et les références de TRAITEMENT pour les données de sortie de l'équipement, une telle liste, notée liste TRT, est construite (étape 305). Les informations utilisées pour construire cette liste peuvent être obtenues de façon locale dans une mémoire de l'équipement considéré ou à partir d'une base de données centralisée telle que celle décrite précédemment. Lorsque la liste est construite, elle est transmise, via un réseau de communication tel qu'AFDX, à une application de gestion de compatibilité d'équipements (étape 310). De façon avantageuse, une fonction de décompte du temps est ensuite initialisée (étape 315). Une telle fonction de décompte permet, le cas échéant, de transmettre, de façon périodique (selon les paramètres de la fonction de décompte du temps), une liste visant les références de TRAITEMENT minimal pour les données d'entrée et les références de TRAITEMENT pour les données de sortie de l'équipement considéré. Il est observé que cette fonction est initialisée lorsque la fonction présentée sur la figure 3 est exécutée (étape non représenté). Si aucune requête pour émettre une liste visant les références de TRAITEMENT minimal pour les données d'entrée et les références de TRAITEMENT pour les données de sortie de l'équipement n'est reçu (étape 300), l'état de l'aéronef est, de préférence, déterminé (étape 320). En effet, si, par exemple, l'aéronef est en vol, il est peu probable qu'un équipement ait été changé. Par conséquent, il peut s'avérer inutile de vérifier la configuration des équipements. Si l'aéronef est dans un état particulier, par exemple, au sol, un autre test est effectué (étape 325) pour déterminer si le délai visé par la fonction de décompte est atteint. Dans l'affirmative, les étapes de construction et de transmission de la liste visant les références de TRAITEMENT minimal pour les données d'entrée et les références de TRAITEMENT pour les données de sortie de l'équipement considéré ainsi que l'étape d'initialisation de la fonction de décompte du temps (étapes 305 à 315) sont effectuées. La liste générée visant les références de TRAITEMENT minimal pour les données d'entrée et les références de TRAITEMENT pour les données de sortie de l'équipement considéré peut notamment être transmise via un réseau de communication, notamment sous la forme d'une ou plusieurs trames UDP (sigle de UserDatagram Protocol en terminologie anglo-saxonne). Selon un mode d'implémentation particulier, la ou les trames représentant la liste considérée peut consister en une ou plusieurs trames dont la zone de données utiles, appelée payload en terminologie anglo-saxonne, est organisée de façon prédéterminée. Selon ce mode de réalisation, illustré sur la figure 4a, la zone de données utiles comprend un ensemble de champ, chaque champ, ayant une adresse prédéterminée dans la trame, correspondant à une référence de TRAITEMENT d'une entrée ou d'une sortie prédéfinie. Comme illustré sur la figure 4a, la trame UDP 400 comprend un en-tête 405 et une zone 410 de données utiles. Typiquement, l'en-tête 405 comprend un champ de port source 415 indiquant le port depuis lequel la trame est envoyée, un champ de port destination 420 indiquant le port auquel la trame est envoyée, un champ longueur 425 qui indique la longueur totale de la trame UDP et un champ somme de contrôle 430 (ou CRC, sigle de Cyclic Redundancy Check en terminologie anglo-saxonne) permettant de contrôler l'intégrité de la trame. Le port source peut notamment être utilisé pour identifier l'équipement ayant transmis la trame et donc déterminer l'équipement auquel se rapporte les indications fournies dans la zone de données utiles, notamment les références de TRAITEMENT.

La zone 410 de données utiles comprend ici un premier champ 435 indiquant la référence du TRAITEMENT associé à la sortie « Output » de l'équipement considéré, par exemple, en référence à la figure 2, la valeur 040. De façon similaire, la zone 410 de données utiles comprend ici un deuxième et un troisième champs 440 et 445 indiquant les références du TRAITEMENT minimal exigé par les entrées associées aux équipements « ADIRU » et « FMS », respectivement, par exemple, en référence à la figure 2, les valeurs 030 et 035, respectivement. Ainsi, conformément à ce mode de réalisation, l'adresse, dans la trame, à laquelle se trouve une référence de TRAITEMENT d'une entrée ou d'une sortie est prédéterminée et ne varie pas au cours de l'exécution de l'application de gestion d'incompatibilité. Selon un autre mode d'implémentation particulier, la ou les trames représentant la liste considérée peut consister en une ou plusieurs trames dont la zone de données utiles (payload) comprend une série de chaînes de caractères (par exemple des caractères ASCII) fournissant les noms d'équipements desquels des données sont reçues (ou les noms de leurs sorties en cause) ainsi que les valeurs des références de TRAITEMENT associées. Le nom d'un équipement est, de préférence, celui qui doit être affiché par un système central d'alarme. Selon ce mode de réalisation, illustré sur la figure 4b, la zone de données utiles comprend un ensemble de paires de champs, chaque paire de champs comprenant un nom d'équipement ou de sortie et une référence de TRAITEMENT associée. Comme illustré sur la figure 4b, la trame UDP 400' comprend un en-tête 405' et une zone 410' de données utiles. Comme l'en-tête 405 décrite en référence à la figure 4a, l'en-tête 405' comprend typiquement un champ de port source 415' indiquant le port depuis lequel la trame est envoyée, un champ de port destination 420' indiquant le port auquel la trame est envoyée, un champ longueur 425' qui indique la longueur totale de la trame UDP et un champ somme de contrôle 430' (CRC) permettant de contrôler l'intégrité de la trame. La zone 410' de données utiles comprend ici une première paire de champs dont le premier champ 450-1 indique le nom EQPMT(1) d'un équipement particulier et la référence TRT(1) du TRAITEMENT associé à cet équipement. A titre d'illustration, en référence à la figure 2, l'équipement EQPMT(1) peut être le FMS dont la référence TRT(1) du TRAITEMENT associé est la valeur 035. De façon similaire, la zone 410' de données utiles comprend une ième paire de champs dont le premier champ 450-i indique le nom EQPMT(i) d'un équipement particulier et la référence TRT(i) du TRAITEMENT associé à cet équipement. A nouveau, à titre d'illustration, en référence à la figure 2, l'équipement EQPMT(i) peut être l'ADIRU dont la référence TRT(1) du TRAITEMENT associé est la valeur 030. Bien que non représentée ici, la zone 410' de données utiles 25 comprend en outre, de préférence, une référence à la sortie de l'équipement considéré ainsi que la référence de TRAITEMENT associé. Il est observé que l'ordre des paires de champs peut être quelconque. Il existe d'autres modes de réalisation pour transmettre une liste 30 visant les références de TRAITEMENT minimal pour les données d'entrée et les références de TRAITEMENT pour les données de sortie d'un équipement donné. Ainsi, par exemple, une telle liste peut être transmise sous forme de MIB SNMP (sigle de Management Information Bases / Simple Network Management Protocol en terminologie anglo-saxonne) et l'application réalisant l'acquisition de ces trames peut en demander l'envoi à travers une requête SNMP.

Comme décrit précédemment, de telles trames comprenant des listes visant les références de TRAITEMENT minimal pour les données d'entrée et les références de TRAITEMENT pour les données de sortie des équipements d'un système embarqué sont avantageusement émises selon une périodicité minimum, par exemple au moins toutes les minutes, dans au moins un état prédéterminé, par exemple lorsque l'aéronef comprenant ce système embarqué est au sol. Les listes émises comprenant des listes visant les références de TRAITEMENT minimal pour les données d'entrée et les références de TRAITEMENT pour les données de sortie d'équipements d'un système embarqué sont reçues par une application, un calculateur ou un équipement particulier, appelé application de gestion d'incompatibilités d'équipements dans la suite de la description, pour déterminer si la configuration, au moins partielle, du système embarqué est admissible ou, au contraire, si elle n'est pas correcte. Des étapes mises en oeuvre par cette application de gestion d'incompatibilités d'équipements pour déterminer si la configuration du système embarqué est admissible ou, au contraire, si elle n'est pas correcte sont illustrées sur la figure 5. Comme illustré, une première étape (étape 500), optionnelle, a pour objet d'émettre une requête pour recevoir, en réponse, des listes visant les références de TRAITEMENT minimal pour les données d'entrée et les références de TRAITEMENT pour les données de sortie des équipements devant être analysés d'un système embarqué. Les équipements analysés sont, par exemple, des équipements ayant un niveau de DAL (acronyme de Design Assurance Level en terminologie anglo-saxonne) supérieur ou égale à un seuil prédéterminé, par exemple C (pannes dont la criticité des conséquences est supérieure ou égale à « majeure ») et/ou des équipements transmettant des données à de tels 17 équipements. A ces fins une étape de sélection (non représentée) des équipements à analyser peut être effectuée, cette sélection étant, de préférence, basée sur un niveau de criticité de l'équipement. Les listes visant les références de TRAITEMENT minimal pour les données d'entrée et les références de TRAITEMENT pour les données de sortie des équipements devant être analysés sont reçues (étape 505), par exemple sous forme de trames, en réponse à une requête préalable ou de façon spontanée (notamment lorsque la gestion de la transmission de ces listes est gérée, au moins partiellement, par chacun des équipements ou par une application tiers). Pour chaque équipement devant être analysé, la référence de TRAITEMENT minimal associé à chaque entrée de cet équipement est comparée avec la référence de TRAITEMENT associé à la sortie de l'équipement dont proviennent les données reçues par l'entrée considérée. En d'autres termes, le niveau de définition minimal associé à chaque entrée de cet équipement est comparé avec le niveau de définition associé à la sortie de l'équipement dont proviennent les données reçues par l'entrée considérée. A titre d'illustration, en référence à la figure 2, la référence de TRAITEMENT de la sortie de l'ADIRU est comparée avec la référence de TRAITEMENT minimal (030) de l'entrée correspondante de l'équipement 200 et la référence de TRAITEMENT de sortie du FMS est comparée avec la référence de TRAITEMENT minimal (035) de l'entrée correspondante de ce même équipement. A ces fins, les variables i et j sont initialisées à la valeur zéro (étape 510). La variable i représente ici un index sur les équipements devant être analysés tandis que la variable j représente un index sur chaque entrée d'un équipement considéré. Dans une étape suivante (étape 515), la référence de TRAITEMENT minimal de l'entrée considérée, c'est-à-dire l'entrée ayant l'index j, de l'équipement analysé, c'est-à-dire de l'équipement ayant l'index i, notée EQPMT(i)_TRTINmin(j), est comparée avec la référence de TRAITEMENT de la sortie de l'équipement dont proviennent les données reçues par l'entrée considérée, notée EQPMT(EQPMT(i)_TRTINminO))_TRTOUT. Un test est alors effectué pour déterminer si l'entrée ayant l'index] de l'équipement ayant l'index i est compatible avec la sortie de l'équipement dont proviennent les données reçues par cette entrée (étape 520). En d'autres termes, un test est effectué pour déterminer si la référence de TRAITEMENT minimal de l'entrée ayant l'index ] de l'équipement ayant l'index i (EQPMT(i)_TRTINmin(j)) est inférieure ou égale à la référence de TRAITEMENT de la sortie de l'équipement dont proviennent les données reçues par l'entrée considérée (EQPMT(EQPMT(i)_TRTINmin(j))_TRTOUT). Si l'entrée ayant l'index ] de l'équipement ayant l'index i est compatible avec la sortie de l'équipement dont proviennent les données reçues par cette entrée, la valeur de l'index] est incrémentée de un (étape 525) et un test est effectué (étape 530) pour déterminer si l'index j a atteint sa valeur maximale (j jmax), c'est-à-dire si toutes les entrées de l'équipement ayant l'index i ont été analysées. Dans la négative, l'algorithme reboucle à l'étape 515 pour analyser l'entrée correspondant au nouvel index]. Si, au contraire, l'index j a atteint sa valeur maximale, l'index i est incrémenté de un et l'index] est réinitialisé à la valeur zéro (étape 535). Un test est alors effectué (étape 540) pour déterminer si l'index i a atteint sa valeur maximale (i Imax), c'est-à-dire si tous les équipements devant être analysés l'ont été. Dans la négative, l'algorithme reboucle à l'étape 515 pour analyser chaque entrée de l'équipement correspondant au nouvel index i. Si, au contraire, l'index i a atteint sa valeur maximale, il est mis fin au 25 processus. Si l'entrée ayant l'index j de l'équipement ayant l'index i n'est pas compatible avec la sortie de l'équipement dont proviennent les données reçues par cette entrée (étape 515), un signal d'alarme est généré (étape 545). De façon avantageuse, un tel signal d'alarme est transmis à un système centralisé 30 d'alarme chaque fois et aussi longtemps qu'il existe une entrée d'un équipement qui n'est pas compatible avec la sortie de l'équipement dont proviennent les données reçues par l'entrée considérée, c'est-à-dire dès et tant qu'il existe un couple de valeurs (i, j) tel que EQPMT(i)_TRTINmin(j) < EQPMT(EQPMT(i)_TRTINmin(j))_TRTOUT. L'alarme produite peut, par exemple, consister en un message du type « AIRCRAFT CONFIGURATION POTENTIAL INCOMPATIBILITY ».

Selon un mode de réalisation particulier, une identification des équipements en cause est transmise (étape 550) au système centralisé d'alarme pour permettre l'affichage de ces informations et faciliter la tâche de l'opérateur de maintenance. Ces équipements sont l'équipement correspondant à l'index i ainsi que l'équipement dont les données de sortie sont reçues par l'entrée considérée. Il convient de noter que plusieurs problèmes d'incompatibilité peuvent être détectés et que, par conséquent, plusieurs couples d'équipements en cause peuvent être indiqués aux opérateurs de maintenance. De façon avantageuse, des informations complémentaires sont également transmises au système centralisé d'alarme (étape 555). De telles informations ont, par exemple, pour objet de permettre l'identification de l'instant d'apparition de l'incompatibilité et permettre de corréler cet évènement avec d'autre manipulations effectuées au sein de l'aéronef auquel appartient le système embarqué considéré.

Toujours selon un mode de réalisation particulier, des informations équivalentes à celles transmises lors des étapes 545, 550 et/ou 555 sont également transmises (étapes 560) à un centre des opérations de la compagnie aérienne exploitant l'aéronef. Ces informations sont transmises via des moyens de communication standard pour permettre d'anticiper l'intervention de correction. L'algorithme reboucle alors à l'étape 515 pour analyser les entrées et/ou les équipements suivants. Il est observé ici que si l'exemple donné en référence à la figure 5 vise à transmettre des alarmes et des informations associées dès qu'une incompatibilité est identifiée, il est également possible d'analyser l'ensemble des équipements devant l'être afin de ne transmettre, le cas échéant, les alarmes et les informations associées qu'après la phase d'analyse.

La ou les alarmes ainsi générées permettent notamment aux pilotes et/ou aux opérateurs de maintenance de détecter qu'une erreur d'installation d'équipements, c'est-à-dire de changement de calculateurs et/ou de téléchargement d'applications logicielles, a été commise. L'aéronef peut alors facilement être reconfiguré dans une configuration approuvée pour le vol en éliminant l'erreur (retrait de l'équipement provoquant l'incompatibilité). Comme observé précédemment, l'analyse des équipements peut se limiter, par exemple, aux équipements ayant un niveau de DAL supérieur ou égal à C. Alternativement, l'analyse des équipements peut se limiter, par exemple, aux équipements ayant un niveau de DAL supérieur ou égal à c ainsi qu'aux équipements fournissant des informations à des équipements mettant en oeuvre des fonctions utilisant ces informations et ayant un niveau de DAL supérieur ou égal à C. La figure 6 illustre un exemple de mise en oeuvre de l'algorithme 15 décrit en référence à la figure 5. La figure 6 représente une partie 600 d'un système embarqué comprenant plusieurs équipements dont les équipements 605-1, 605-2 et 605-3 devant être surveillés. Ces équipements sont ici des calculateurs de type ADIRU, CDS et FMS, respectivement. Le système comprend en outre un 20 équipement 610 de type FWS (sigle de Flight Warning System en terminologie anglo-saxonne), une application centralisée de surveillance d'équipement, notée LIINDA (acronyme de Logical Interface INcompatibility Detection Application en terminologie anglo-saxonne), mise en oeuvre ici dans un calculateur 615 et autre calculateur 620. 25 Les calculateurs sont ici reliés les uns aux autres par un réseau de communication de type AFDX. Pour des raisons de clarté, seuls des liens logiques entre ces équipements sont représentés sur la figure 6. Une sortie de l'ADIRU 605-1 est reliée à une entrée du CDS 605-2, par un lien virtuel (aussi appelé virtual link en terminologie anglo-saxonne, 30 pouvant être considéré comme un acheminement logique similaire à un lien câblé), pour transmettre des données, par exemple des données de service. Une autre sortie de l'ADIRU 605-1 est reliée à une entrée du FMS 605-3, par un lien virtuel, pour transmettre des données telles que des données de position. Une autre sortie encore de l'ADIRU 605-1 est reliée à l'application LIINDA pour lui permettre d'obtenir des informations caractérisant l'ADIRU 605-1, en particulier la liste 625 visant les références de TRAITEMENT minimal pour les données d'entrée et les références de TRAITEMENT pour les données de sortie. L'ADIRU 605-1 n'ayant pas ici d'entrée reliée à un autre équipement, la liste 625 ne comprend qu'une référence de TRAITEMENT pour les données de sortie (ADIRU TRTOUT), cette référence, égale à 028, étant ici commune à toutes les sorties.

De façon similaire, une sortie du FMS 605-3 est reliée à une entrée du CDS 605-2, par un lien virtuel, pour transmettre des données, par exemple des données de service. Une autre sortie du FMS 605-3 est reliée à l'application LIINDA pour lui permettre d'obtenir des informations caractérisant le FMS 605-3, en particulier la liste 630 visant les références de TRAITEMENT minimal pour les données d'entrée et les références de TRAITEMENT pour les données de sortie. Le FMS 605-3 ayant ici une entrée reliée à l'ADIRU 605-1, la liste 625 comprend une référence de TRAITEMENT minimal pour les données d'entrée issues de l'ADIRU 605-1 (ADIRU TRTINmin), égale à 030, ainsi qu'une référence de TRAITEMENT pour les données de sortie (FMS TRTOUT), égale à 030. De même, une sortie du CDS 605-2 est reliée à une entrée du calculateur 620, par un lien virtuel, pour transmettre des données, par exemple des données de service. Une autre sortie du CDS 605-2 est reliée à l'application LIINDA pour lui permettre d'obtenir des informations caractérisant le CDS 605-2, en particulier la liste 635 visant les références de TRAITEMENT minimal pour les données d'entrée et les références de TRAITEMENT pour les données de sortie. Le CDS 605-2 ayant ici une entrée reliée à l'ADIRU 605-1 et une entrée reliée au FMS 605-3, la liste 635 comprend deux références de TRAITEMENT minimal pour les données d'entrées issues de l'ADIRU 605-1 (ADIRU TRTINmin) et du FMS 605-3 (FMS TRTINmin), égales à 030, ainsi qu'une référence de TRAITEMENT pour les données de sortie (CDS TRTOUT), égale à 030.

L'application LIINDA peut donc comparer les exigences des équipements 605-1, 605-2 et 605-3 avec les références de TRAITEMENT associées aux données qui leur sont fournies. Ainsi, en effectuant ces comparaisons, l'application en déduit que les références de TRAITEMENT minimal requis pour les données d'entrée du CDS 605-2 et du FMS 605-3, en provenance de l'ADIRU 605-1, sont égales à 030 alors que la référence de TRAITEMENT associée aux données provenant de l'ADIRU 605-1 est égale 028, soit une valeur inférieure à la valeur minimale requise. Une incompatibilité de l'ADIRU 605-1 avec le FMS 605-3 et CDS 605-2 est donc identifiée et une alarme est générée à destination du FWS 610. L'alarme comprend ici une identification des équipements en cause : « Aircraft configuration potential incompatibility between ADIRU & CDS and between ADIRU & FMS ». Bien que l'invention ait été essentiellement décrite selon des références de TRAITEMENT, il est possible d'utiliser une granularité différente et d'utiliser dynamiquement des informations relatives aux traitements des données échangées via les interfaces des équipements. Ainsi, à titre d'illustration, le processus qui gère notamment l'organisation des TRAITEMENTS et des ICDs peut obtenir dynamiquement des informations relatives à l'évolution de données émises par un équipement selon l'état de ce dernier (démarrage, initialisation, cycle de calcul des données considérées, etc.). De telles informations, définissant des niveaux de définition, peuvent alors être utilisées comme les références de TRAITEMENT, de façon complémentaire ou non, en combinaison avec des niveaux de définition minimale, pour déterminer des incompatibilités entre équipements.

Ainsi, conformément à l'invention, un niveau de définition minimal de données associé à une entrée d'un équipement et un niveau de définition de données associé à une sortie d'un équipement peuvent comprendre des références de TRAITEMENT et/ou toute autre caractéristique représentative d'un état des données échangées via cette entrée ou cette sortie.

Par ailleurs, selon un mode de réalisation particulier, il est possible d'inhiber ou d'annuler les alarmes émises selon l'invention, par exemple pour autoriser des vols dans des configurations particulières, notamment pour des essais en vol. En outre, il est observé que toutes ou certaines listes visant les références de TRAITEMENT minimal pour les données d'entrée et les références de TRAITEMENT pour les données de sortie des équipements devant être analysés peuvent être acquises par des équipements qui procèdent, pour des questions de sécurité (aussi appelées safety en terminologie anglo-saxonne), à des vérifications complémentaires sur la validité des informations qu'ils acquièrent de tous ou de certains équipements.

La figure 7 illustre un exemple de dispositif pouvant être utilisé pour mettre en oeuvre, au moins partiellement, l'invention, notamment des étapes décrites en référence aux figures 3 et 5. Le dispositif 700 est par exemple un calculateur, notamment un serveur de type ANSU (sigle d'Avionic Network Server Unit en terminologie anglo-saxonne).

Le dispositif 700 comporte de préférence un bus de communication 702 auquel sont reliés : - une unité centrale de traitement ou microprocesseur 704 (CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ; - une mémoire morte 706 (ROM, acronyme de Read Only Memory 20 en terminologie anglo-saxonne) pouvant comporter le système d'exploitation et des programmes tels que "Prog" ; - une mémoire vive ou mémoire cache 708 (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 25 cours de l'exécution des programmes précités ; - un lecteur 710 de support amovible de stockage 712 tel qu'une carte mémoire ou un disque, par exemple un disque DVD, permettant notamment de télécharger une application logicielle ; et, - une carte graphique 714 reliée à un écran 716. 30 Optionnellement, le dispositif 700 peut également disposer des éléments suivants : - un disque dur 720 pouvant comporter les programmes "Prog" précités et des données traitées ou à traiter selon l'invention ; - un clavier 722 et une souris 724 ou tout autre dispositif de pointage comme un crayon optique, un écran tactile ou une télécommande permettant à l'utilisateur d'interagir avec les programmes selon l'invention ; et, - une interface de communication 726 reliée à un réseau de communication distribué 728, par exemple le réseau AFDX, l'interface étant apte à transmettre et à recevoir des données, notamment vers et en provenance d'un équipement d'un aéronef.

Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le dispositif 700 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 700 directement ou par l'intermédiaire d'un autre élément du dispositif 700. Le code exécutable de chaque programme permettant à l'appareil programmable de mettre en oeuvre les processus selon l'invention, peut être stocké, par exemple, dans le disque dur 720 ou en mémoire morte 706. Selon une variante, le code exécutable des programmes pourra être reçu par l'intermédiaire du réseau de communication 728, via l'interface 726, pour être stocké de façon identique à celle décrite précédemment. De manière plus générale, le ou les programmes pourront être chargés dans un des moyens de stockage du dispositif 700 avant d'être exécutés.

L'unité centrale 704 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 720 ou dans la mémoire morte 706 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 720 ou la mémoire morte 706, sont transférés dans la mémoire vive 708 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. Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications 5 dans la description précédente.

Claims (12)

1. REVENDICATIONS1. Procédé pour ordinateur de détection d'incompatibilité entre au moins deux équipements d'un système embarqué, ce procédé étant caractérisé en ce que, une interface logique associée à l'un desdits au moins deux équipements comprenant au moins une entrée et une interface logique associée à l'autre desdits au moins deux équipements comprenant au moins une sortie, ladite au moins une entrée étant connectée à ladite au moins une sortie, le procédé comprend les étapes suivantes, - obtention (505) d'un niveau de définition minimal de données associé à ladite au moins une entrée dudit un desdits au moins deux équipements et d'un niveau de définition de données associé à ladite au moins une sortie dudit autre desdits au moins deux équipements ; - comparaison (515) dudit niveau de définition minimal de données associé à ladite au moins une entrée dudit un desdits au moins deux équipements avec ledit niveau de définition de données associé à ladite au moins une sortie dudit autre desdits au moins deux équipements ; et, - en réponse à ladite étape de comparaison, si ledit niveau de définition minimal de données associé à ladite au moins une entrée dudit un desdits au moins deux équipements est inférieur audit niveau de définition de données associé à ladite au moins une sortie dudit autre desdits au moins deux équipements, génération (545) d'une alarme indiquant une incompatibilité desdits au moins deux équipements.
2. 2. Procédé selon la revendication 1 selon lequel ladite étape d'obtention comprend l'obtention, pour chaque équipement dudit système embarqué dont l'incompatibilité avec un autre équipement est analysée, d'un niveau de définition minimal de données associé à chaque entrée de l'équipement considéré, ladite étape de comparaison étant effectuée pour chaque niveau de définition minimal obtenu.
3. 3. Procédé selon la revendication 2 selon lequel ladite étape d'obtention comprend en outre l'obtention, pour chaque équipement dudit système embarqué transmettant au moins une donnée à un desdits équipements dont l'incompatibilité avec un autre équipement est analysée, d'un niveau de définition de données associé à au moins une sortie de l'équipement considéré.
4. 4. Procédé selon la revendication 2 ou la revendication 3 comprenant en outre une étape de sélection d'équipements dudit système embarqué dont l'incompatibilité avec d'autres équipements est analysée, ladite sélection étant déterminée selon un niveau de criticité des équipements dudit système embarqué.
5. 5. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de transmission d'un identifiant dudit un desdits au moins deux équipements et dudit autre desdits au moins deux équipements si ledit niveau de définition minimal de données associé à ladite au moins une entrée dudit un desdits au moins deux équipements est inférieur audit niveau de définition de données associé à ladite au moins une sortie dudit autre desdits au moins deux équipements.
6. 6. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de transmission d'au moins ladite alarme générée à un système de traitement de l'information centralisé distinct dudit système embarqué.
7. 7. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape préalable de transmission d'au moins une requête, ledit niveau de définition minimal de données associé à ladite au moins une entrée dudit un desdits au moins deux équipements et ledit niveau de définition de données associé à ladite au moins une sortie dudit autre desdits au moins deux équipements étant obtenu en réponse à ladite requête.
8. 8. Procédé selon l'une quelconque des revendications précédentes selon lequel lesdites étapes d'obtention, de comparaison et de génération d'une alarme en réponse à ladite étape de comparaison sont effectuées de façon périodique selon un état associé audit système embarqué.
9. 9. Procédé selon l'une quelconque des revendications précédentes selon lequel ledit niveau de définition minimal de données associé à ladite au moins une entrée dudit un desdits au moins deux équipements et ledit niveau de définition de données associé à ladite au moins une sortie dudit autre desdits au moins deux équipements sont reçus sous forme de trames de type UDP.
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