Brevet FR2841999A1 — publié le 20040109

La présente invention concerne les échanges de données entre des équipements embarqués à bord d'un aérodyne. Un aérodyne est équipé de plus en plus d'équipements électroniques, certains captant les positions des éléments mobiles volets, gouvernes, aérofreins, trains d'atterrissage, etc., d'autres affichant les paramètres de vol, d'autres aidant au pilotage ou à la navigation comme le pilote automatique ou le calculateur de vol, d'autres permettant des échanges d'informations avec le sol ou avec d'autres aérodynes, d'autres encore assurant la surveillance de l'environnement proche de l'aérodyne, etc.. L'ensemble de ces équipements embarqués à bord d'un aérodyne est habituellement désigné par le terme générique de système avionique. Les systèmes avioniques sont très divers d'un aérodyne à l'autre, et sont soumis, pour des questions de sécurité, à des procédures de certification qui rendent très coteuses leur mise au point initiale et leurs 1 5 modifications ultérieures pour des mise à niveau tout au long de la période d'exploitation d'un aérodyne qui peut atteindre plusieurs décennies. La modification du système avionique d'un aérodyne implique, pour éviter une perte de certification, de reprendre les procédures de certification aussi bien au niveau des équipements modifiés ou ajoutés qu'au niveau des conséquences de ces modifications ou ajout d'équipements sur les équipements préexistants non modifiés du système avionique. Par exemple, l'ajout d'un équipement anticollision avion demande un raccordement avec le calculateur de vol pour la fourniture, à l'équipement anticollision, du vecteur vitesse et des coordonnées de position de l'aérodyne. Si un tel raccordement n'a pas été prévu lors de la conception du calculateur de vol, sa création implique des modifications au niveau du calculateur de vol entraînant pour celui-ci la nécessité d'une reprise plus ou moins complète des procédures de certification le concernant. La modification et la recertification d'équipements existant du système avionique d'un aérodyne en vue d'ajouter un nouvel équipement est une opération qui est souvent compliquée par le fait que le fabricant de l'équipement à rajouter est souvent différent de ceux des équipements préexistants à modifier, ce qui implique la mise en place de coopérations entre fabricants différents avec leurs lots de négociations, qui alourdissent considérablement le cot et le temps nécessaire à la mise à jour d'un système avionique. La présente invention a pour but de faciliter l'introduction d'un nouvel équipement dans un système avionique, lorsque ce nouvel équipement doit échanger des informations avec des équipements déjà en place, mais non initialement prévus pour coopérer avec le nouvel 10 équipement, cela en utilisant l'approche de la programmation orientée objet vis à vis des différents équipements du système avionique. Elle a pour objet un système de mise en réseau d'équipements aéronautiques embarqués à bord d'un aérodyne comportant, pour chaque i 5 équipement, une interface orientée objet avec des moyens dits façade objet, lui permettant d'appréhender l'équipement embarqué auquel elle est affectée, en tant qu'un objet, au sens de la programmation orientée objet, capable de communiquer avec d'autres objets au sens de la programmation orientée objet selon un modèle client/serveur orienté objet et avec des moyens dits observateurs recensant les événements résultants du fonctionnement de l'équipement embarqué. L'approche des équipements embarqués d'un aérodyne en tant qu'objets, au sens de la programmation orienté objet, capables de communiquer selon un modèle client/serveur orienté objet permet de les faire dialoguer entre eux tout en les considérant comme des boîtes noires, c'est-àdire en faisant abstraction de la façon dont ils remplissent les tâches ou services auxquelles ils sont dévolus. Cela minimise les interventions sur les équipements existants et donc les opérations nécessaires à la recertification d'un système avionique modifié. La conception de la façade objet d'une interface orientée objet permettant de percevoir un équipement aéronautique embarqué à bord d'un aérodyne en tant qu'un objet, au sens de la programmation orientée objet, capable de communiquer selon un modèle client/serveur orienté objet et de ses moyens observateurs recensant les événements résultant du 35 fonctionnement de l'équipement est rendu possible par le fait que les différents états que peut prendre un équipement aéronautique, les différents messages qu'il peut traiter, les services qu'il rend ou les procédures qu'il engage à la suite de ces messages, et les événements résultant des services rendus ou procédures engagées sont toujours très précisément répertoriés dans les spécifications des constructeurs. Avantageusement, une interface orientée objet comporte une façade objet pourvue de services de communication par abonnement. Avantageusement, les interfaces orientées objet communiquent entre elles en respectant la norme CORBA établie par l"'Object Management 1o Group". Avantageusement, les interfaces orientées objet communiquent entre elles en respectant le protocole Java Remote Method Invocation établi par la société Sun Microsystem, Java étant une marque déposée par cette dernière société. 1 5 Avantageusement, les interfaces orientées objet communiquent entre elles en respectant le protocole Simple Object Access Protocol établi par le 'World Wide Web Consortium". Avantageusement, les interfaces orientées objet communiquent entre elles par l'intermédiaire d'un objet au sens de la programmation orientée objet, dit objet adaptateur, pourvu moyens d'adaptation de la forme des messages et événements émis par les interfaces orientées objet pour qu'ils soient compris de l'interface orientée objet destinataire. Avantageusement, lorsque les interfaces orientées objet communiquent entre elles par l'intermédiaire d'un objet adaptateur, le système de mise en réseau renferme un objet de configuration connaissant tous les objets du réseau et tous les services et s'occupant de la création des objets adaptateurs. Avantageusement, lorsqu'un bus aéronautique dédié interconnecte les équipements embarqués, il est utilisé pour raccorder des interfaces orientées objet à leurs équipements d'affectation. Avantageusement, lorsqu'un bus aéronautique dédié interconnecte les équipements embarqués, il est utilisé pour raccorder des interfaces orientées objet à leurs équipements d'affectation et pour relier entre elles les interfaces orientées objet. D'autres avantages et caractéristiques de l'invention ressortiront de la description ci-après d'un mode de réalisation donné à titre d'exemple. Cette description sera faite en regard du dessin dans lequel: - une figure 1 est un schéma illustrant une interface orientée objet selon l'invention pour un équipement anticollision avion, - une figure 2 est un schéma illustrant un mode de communication direct entre les interfaces orientées objet d'un calculateur de vol et d'un équipement anticollision avion placés à bord d'un aérodyne, - une figure 3 est un schéma illustrant un mode de communication indirect, par l'intermédiaire d'un objet adaptateur, entre les interfaces orientées objet d'un calculateur de vol et d'un équipement anticollision avion placés à bord d'un aérodyne, - une figure 4 est un schéma illustrant le raccordement d'une 1 5 interface orientée objet à un calculateur de vol dans le cas o ce dernier est accessible par un bus avion dédié, et - une figure 5 est un schéma illustrant un mode de communication indirect, par l'intermédiaire d'un objet adaptateur, entre l'interface orientée objet d'un équipement anticollision avion et l'interface orientée objet d'un calculateur de vol greffée à ce dernier par l'intermédiaire du bus aéronautique dédié. La programmation orientée objet, connue sous le sigle OOP tiré de l'anglosaxon "Object Oriented Programming", cherche à maîtriser la complexité croissante des programmes d'ordinateur en organisant un programme d'ordinateur comme des ensembles coopérants d'entités informatiques autonomes dites objets, constituées à la fois de données et d'une collection de structures et de procédures liées. Elle fait l'objet d'une abondante littérature auquel le lecteur peut se rapporter pour une connaissance détaillée notamment le livre de Grady BOOCH intitulé:"Object Oriented Design with Application" paru aux éditions Addison-Wesley Pub. Co. (février 1994) ISBN:0805353402. Il suffit, pour la suite, de savoir qu'un objet au sens de la programmation orientée objet, modélise le comportement d'une entité du monde réel appréhendé à partir d'un état courant de l'entité, des services ou procédures que l'entité peut exécuter, de la forme des messages et des paramètres permettant de requérir ces services ou procédures, et des événements résultant des services ou procédures exécutés. La structure effective de l'entité modélisée, c'est-à-dire la manière dont elle exécute des services ou procédures n'est pas prise en compte dans l'objet qui la modélise, ce qui rend le modèle à objet de la programmation orientée objet particulièrement intéressant dans le cas d'équipements dont on cherche à modifier l'utilisation sans pour autant toucher à leurs structures ou aux services qu'ils rendent. Les objets coopèrent selon un modèle client/serveur, un objet étant considéré comme serveur lorsqu'il exécute un service sur la demande d'un autre objet, et comme client lorsqu'il est demandeur d'un service de la part d'un autre objet. Dans le cas du système avionique d'un aéronef, chaque équipement tel que le pilote automatique, le calculateur de vol, le routeur de 1 5 communication, etc. peut avoir son comportement modélisé par un objet au sens de la programmation orientée objet, au moyen d'une interface orientée objet avec une façade objet renfermant un enregistrement de l'état courant de l'équipement et décrivant formellement les services rendus avec leurs paramètres d'appel, et avec des moyens observateurs collectant les événements résultant de l'exécution des services demandés. Plus précisément, les moyens observateurs peuvent être des objets comportementaux au sens du chapitre "observer" du livre intitulé "Design Patterns" écrit par Erich Gamma et ai. et publié aux éditions "Addison-Wesley Professional Computing Series" ISBN: 0-201-63361-2. Pour que des équipements modélisés par des objets au sens de-la programmation orientée objet communiquent entre eux selon un modèle client/serveur orienté objet, il suffit d'ajouter, à leurs façades objet, des services ou procédures qui leur sont propres, spécialisés dans la communication entre objets et accessibles des autres objets par abonnement, et de munir les équipements modélisés destinés à être utilisateurs de services rendus par d'autres équipements modélisés, de bases de connaissance de services rendus par d'autres objets. La figure 1 illustre un exemple d'interface orientée objet adaptée à un équipement anticollision avion connu sous le sigle TCAS tiré de l'anglo35 saxon "Traffic Collision Avoidance System". Cette interface orientée objet se compose d'une façade objet 1 et de moyens observateurs 2. Dans la façade objet 1, l'état courant de l'équipement TCAS est identifié par des valeurs de paramètres 10 repérées par leurs noms précédés d'un signe moins en préfixe alors que les services rendus par l'équipement TCAS et leurs paramètres d'appel 11 ainsi que les services de communication par abonnement 12 rendus par l'interface orientée objet elle-même, sont repérés par leurs noms précédés d'un signe plus en préfixe. Dans les moyens observateurs 2, les événements découlant des services rendus par l'équipement TCAS sont identifiés par des valeurs de paramètres 20 repérés par leurs noms précédés d'un signe plus en préfixe. La façade objet 1 est un nouvel accès aux services rendus par l'équipement TCAS, tandis que les moyens observateurs 2 constituent une base des événements à notifier aux objets clients qui se sont abonnés. La figure 2 illustre un exemple de couplage d'un équipement i I TCAS avec un calculateur de vol connu sous le sigle FMS tiré de l'anglosaxon "Flight Management System" en vue de réaliser une fonction de détection de conflit et d'anticollision. Dans cet exemple, l'équipement TCAS et le calculateur FMS sont considérés comme des objets au sens de la programmation objet, l'un étant pourvu d'une base de connaissance des services rendus qu'il peut être amené à demander à l'autre et réciproquement pour réaliser la fonction de détection de conflit et d'anticollision avion. Le calculateur FMS est pourvu, comme l'équipement TCAS d'une interface orienté objet qui le modélise en tant qu'objet au sens de la programmation orientée objet. Dans un but de simplification, seules les interfaces orientées objet ont été représentées sur la figure 2. L'interface orientée objet de l'équipement TCAS avec sa façade objet 1 et ses moyens observateurs 2 est reprise de la figure 1. L'interface orientée objet du calculateur FMS présente également une façade objet 3 et des moyens observateurs 4 mais ceux-ci sont adaptés au comportement du calculateur FMS. La façade objet de l'interface orientée objet du calculateur FMS identifie l'état courant du calculateur FMS par des valeurs de paramètres 30 repérées par leurs noms précédés d'un signe moins en préfixe et les services rendus par le 35 calculateur FMS et leurs paramètres d'appel 31 ainsi que les services de communication par abonnement 32 rendus par l'interface orientée objet (3, 4) elle-même, par leurs noms précédés d'un signe plus en préfixe. Les moyens observateurs 4 identifient les événements consécutifs aux services rendus par le calculateur FMS par des valeurs de paramètres 40 repérés par leurs noms précédés d'un signe plus en préfixe. Les interfaces orientées objet 1, 2 de l'équipement TCAS et 3, 4 du calculateur de vol sont directement couplées en ce sens que chacune d'elles est cliente de l'autre et souscrit directement des abonnements auprès de l'autre lorsque le besoin s'en fait sentir. Elles sont reliées dans les deux 10 sens, au niveau logique par des liens "est un" 5, 6 et au niveau physique, par une liaison de transmission 7, 8. Ce mode de couplage direct entre l'interface orientée objet 1, 2 de l'équipement TCAS et l'interface orientée objet 3, 4 du calculateur FMS implique que l'interface orientée objet 1, 2 de l'équipement TCAS non 1 5 seulement modélise l'équipement TCAS en tant qu'objet au sens de la programmation orientée objet mais également envoie, à l'interface orientée objet 3, 4 du calculateur FMS, des messages de demande de service selon la forme ou protocole utilisé par cette dernière et est capable d'interpréter la forme sous laquelle l'interface orientée objet 3, 4 du calculateur FMS lui communique les événements résultant de l'exécution des services demandés. Il implique de même que l'interface orientée objet 3, 4 du calculateur FMS non seulement modélise le calculateur FMS en tant qu'objet au sens de la programmation orientée objet mais également envoie, à l'interface orientée objet 1, 2 de l'équipement TCAS, des messages de demande de service selon la forme ou protocole utilisé par ce dernier et est capable d'interpréter la forme sous laquelle l'interface orientée objet 1, 2 de l'équipement TCAS lui communique les événements résultant de l'exécution des services demandés. Le couplage direct nécessite de concevoir une interface orientée 30 objet non seulement en fonction de l'équipement à modéliser en tant qu'objet au sens de la programmation orientée objet mais également en fonction des interfaces orientées objet des équipements avec lesquelles elle peut être amenée à être en relation. Cette contrainte implique la remise en cause des interfaces orientées objet des équipements d'un système avionique à chaque 35 ajout d'un nouvel équipement ou à chaque modification du protocole des messages acceptés par une interface orientée objet ou des événements qu elle émet. Une telle remise en cause n'est pas souhaitable car elle oblige à reprendre les procédures de certification de toutes les interfaces orientées objet modifiées. Pour éviter d'avoir à tenir compte, lors de la conception d'une interface orientée objet, des caractéristiques des autres interfaces orientées objet avec lesquelles elle peut être amenée à communiquer, on propose, relativement à la figure 3, un autre exemple de couplage d'un équipement TCAS avec un calculateur FMS en vue de réaliser une fonction de détection 0o de conflit et d'anticollision, l'un et l'autre étant toujours considérés comme des objets au sens de la programmation objet. Dans cette autre forme de couplage, les interfaces orientées objet 1,2 et 3,4 de l'équipement TCAS et du calculateur FMS ne sont plus mises en relation directe mais par l'intermédiaire d'un autre objet 9, toujours au sens de la programmation 1 5 orientée objet, dit objet adaptateur, effectuant les adaptations nécessitées par les éventuelles différences de protocole des messages et événements. Sur la figure 3, on retrouve l'interface orientée objet 1, 2 de l'équipement TCAS et l'interface orientée objet 3, 4 du calculateur FMS. Celles-ci s'ignorent tout en ayant connaissance d'un ensemble de services 20 accessibles. A chaque expression d'un besoin de service de la part de l'autre équipement, un objet adaptateur 9 spécifique est créé pour les mettre en relation et assurer les conversions de protocole nécessaires. L'objet adaptateur 9 est relié, dans les deux sens par des liaisons de transmission 100, 101 à l'interface objet 1, 2 de l'équipement TCAS et à 25 l'interface objet 3, 4 du calculateur FMS. Il est abonné en tant que client à ces deux interfaces objet 1, 2 et 3, 4 au moyen de liens "est un" 103, 104. Un autre objet 15 dit de configuration, qui connaît tous les objets et tous les services, s'occupe de créer les objets adaptateurs 9 en fonction des besoins d'interconnexion. Aucun savoir-faire applicatif (autre que protocolaire) n'est intégré dans les objets adaptateurs 9. L'expérience montre que les temps de calcul associés à ces formatages sont faibles par rapport aux temps de traitement pris par les services rendus. Le cot de développement de ces objets adaptateurs est, a priori, faible puisqu'il ne s'agit que de formatage de données. L'intérêt majeur des objets adaptateurs 9 est le faible couplage entre modèles objets qu'ils autorisent. Ce faible couplage permet, de cantonner l'essentiel des conséquences de l'insertion d'un nouvel équipement dans un système avionique, à la création de nouveaux objets adaptateurs, les équipements préexistants subissant éventuellement une mise à jour de leur base de connaissance des services rendus pour y intégrer des services rendus par le nouvel équipement et des événements qu'il est susceptible de produire. Les interfaces orientées objet 1, 2; 3,4 et les objets adaptateurs 9 0o respectent avantageusement une norme ou protocole d'applications distribuées hétérogènes comme la norme CORBA établie par l"'Object Management Group" ou le protocole Java Remote Method Invocation établi par la société Sun Microsystem, Java étant une marque déposée par cette dernière société ou encore le protocole Simple Object Access Protocol établi par le 'VVorld Wide Web Consortium". Une interface orientée objet d'un équipement, qui permet le passage entre le monde non-orienté objet d'un équipement et le monde orienté objet du système de mise en réseau est une machine logique qui peut être réalisée en logique combinatoire ou séquentielle, soit à l'aide de 20 circuits spécialisés montés sur une carte électronique fille placée dans le boîtier de l'équipement modélisé et raccordée aux bus propriétaires de ce dernier, soit en utilisant du temps de calcul d'un calculateur appartenant à l'équipement modélisé. Dans les deux cas, l'ajout d'une l'interface orientée objet porte atteinte à l'intégrité d'un équipement qui doit subir de nouveaux tests pour conserver sa certification. Ces deux manières de faire ne sont bien adaptées qu'à un nouvel équipement conçu, dès l'origine avec une interface orientée objet. Pour les équipements déjà présents dans le système avionique elles posent toujours le problème de la recertification même si celui-ci est atténué par le fait que la structure de l'équipement n'est pas touchée. La figure 4 montre une autre façon d'ajouter une interface orientée objet à un équipement embarqué à bord d'un aéronef, lorsque celui-ci est raccordé à un bus aéronautique dédié de transmission de données comme c'est le cas par exemple du modèle d'avion commercial Boeing 777 fabriqué par la compagnie Boeing ou du futur modèle d'avion commercial A 380 en voie de construction par la compagnie Airbus. L'équipement concerné est un calculateur FMS représenté par son interface d'accès 50 à un bus aéronautique dédié 51. Son interface orientée objet avec sa façade objet 52 et ses moyens observateurs 53 lui est raccordée par l'intermédiaire du bus aéronautique dédié 51 et de son interface 50 d'accès au bus. La connexion au calculateur FMS, de son l'interface orientée objet 52, 53 par l'intermédiaire du bus aéronautique dédié 51 et de son interface io d'accès 50 à ce bus aéronautique dédié 51 est rendue possible par le fait que l'interface d'accès 50 est une machine logique prévue pour permettre au système avionique d'avoir accès à l'ensemble des services que le calculateur FMS est capable de rendre (paramètres précédés de flèches entrantes indexés par 500) et des événements susceptibles d'être produits par le 15 calculateur FMS et de son état (paramètres suivis de flèches sortantes indexés par 501). Ce mode de raccordement rend possible un respect complet de l'intégrité du calculateur FMS et donc de sa certification, si l'on accepte de ne pas faire bénéficier le calculateur FMS des services de l'équipement TCAS ajouté. Dans ce cas, le calculateur FMS est uniquement vu par l'équipement TCAS comme un serveur éventuel mais jamais comme un client. La figure 5 illustre un exemple de couplage, du genre de celui de la figure 3, entre un équipement TCAS nouvellement ajouté à un système avionique et un calculateur FMS préexistant, accessible dans le système avionique par un bus aéronautique dédié, en vue de réaliser une fonction de détection de conflit et d'anticollision avion, sans toucher à l'intégrité du calculateur FMS pour conserver sa certification. Comme dans la figure précédente, le calculateur FMS est pourvu d'une interface orientée objet, avec une façade objet 52 et des moyens observateurs 53, qui lui est raccordée par l'intermédiaire du bus aéronautique dédié 51 et de son interface 50 d'accès au bus. L'équipement TCAS, qui est nouvellement rajouté au système avionique, est doté en interne d'une interface orientée objet avec une façade objet 1 et des moyens observateurs 2. L'équipement TCAS et le calculateur FMS communiquent 35 entre eux par l'intermédiaire de leurs interfaces orientées objet 1, 2 et 52, 53 il mises en relation par un objet adaptateur 9' et des liaisons de transmission 102, 103 créés chaque fois que le besoin s'en fait sentir par un objet de configuration 15'. Dans le cas considéré ici du respect total de l'intégrité du calculateur FMS préexistant du système avionique, un objet adaptateur 9' de mise en relation de l'équipement TCAS et du calculateur FMS est uniquement abonné au. calculateur FMS puisque ce dernier n'a pas été conçu à l'origine pour bénéficier des services rendus par l'équipement TCAS et que l'on ne veut pas toucher à son intégrité. Cela n'empêche pas une mise 0o à niveau ultérieure du calculateur FMS, au prix d'une recertification et de l'utilisation d'objets adaptateurs abonnés à la fois au calculateur FMS et à l'équipement TCAS. Les liaisons de transmission 102, 103 entre interfaces orientées objet 1, 2; 52, 53 et objet adaptateur 9' peuvent emprunter le bus aéronautique dédié, les données échangées entre eux mettant en oeuvre une surcouche de protocole avantageusement du genre protocole d'applications distribuées hétérogènes comme la norme CORBA établie par l"'Object Management Group" ou le protocole Java Remote Method Invocation établi par la société Sun Microsystem, Java étant une marque déposée par cette dernière société ou encore le protocole Simple Object Access Protocol établi par le "World Wide Web Consortium". REVENDICATIONS 1. Système de mise en réseau d'équipements aéronautiques embarqués à bord d'un aérodyne caractérisé en ce qu'il comporte, pour chaque équipement, une interface orientée objet (1, 2; 3, 4) avec des moyens dits façade objet (1, 3), lui permettant d'appréhender l'équipement embarqué auquel elle est affectée, en tant qu'un objet, au sens de la programmation orientée objet, capable de communiquer avec d'autres objets au sens de la programmation orientée objet selon un modèle client/serveur orienté objet et avec des moyens dits observateurs (2, 4) recensant les événements résultants du fonctionnement de l'équipement. 2. Système selon la revendication 1, caractérisé en ce que une 1 5 interface orientée objet (1, 2; 3, 4) comporte une façade objet (1, 3) pourvue de services de communication par abonnement. 3. Système selon la revendication 1, caractérisé en ce que les interfaces orientées objet (1, 2; 3, 4; 52, 53) respectent un protocole d'applications distribuées hétérogènes 4. Système selon la revendication 1,caractérisé en ce que les interfaces orientées objet (1, 2; 3, 4; 52, 53) respectent la norme CORBA établie par l"'Object Management Group". 5. Système selon la revendication 1, caractérisé en ce que les interfaces orientées objet (1, 2; 3, 4; 52, 53) respectent le protocole Java Remote Method Invocation établi par la société Sun Microsystem, Java étant une marque déposée par cette dernière société. 6. Système selon la revendication 1, caractérisé en ce que les interfaces orientées objet (1, 2; 3, 4; 52, 53) respectent le protocole Simple Object Access Protocol établi par le 'World Wide Web Consortium". 7. Système selon la revendication 1, caractérisé en ce que les interfaces orientées objet (1, 2; 3, 4) communiquent entre elles par l'intermédiaire d'un objet au sens de la programmation orientée objet, dit objet adaptateur (9, 9'), pourvu moyens d'adaptation de la forme des messages et événements émis par les interfaces orientées objet pour qu'ils soient compris de l'interface orientée objet destinataire. 8. Système selon la revendication 7, caractérisé en ce qu'il comporte un objet de configuration (15, 15') connaissant tous les objets, au sens de la programmation orientée objet, du réseau et tous les services et s'occupant de la création des objets adaptateurs (9, 9'). 9. Système selon la revendication 7, caractérisé en ce qu'un objet adaptateur (9, 9') respecte la norme CORBA établie par l"'Object Management Group". 1 5 10. Système selon la revendication 7, caractérisé en ce qu'un objet adaptateur (9, 9') respecte le protocole Java Remote Method Invocation établi par la société Sun Microsystem, Java étant une marque déposée par cette dernière société. 11. Système selon la revendication 7, caractérisé en ce qu'un objet adaptateur (9, 9') respecte le protocole Simple Object Access Protocol établi par le 'World Wide Web Consortium". 12. Système selon la revendication 1, utilisé dans un système avionique comportant un bus aéronautique dédié (51), caractérisé en ce que des interfaces orientées objet (52, 53) sont raccordées à leurs équipements d'affectation par l'intermédiaire du bus aéronautique dédié (51). 13. Système selon la revendication 1, utilisé dans un système avionique comportant un bus aéronautique dédié (51), caractérisé en ce que les interfaces orientées objet (1, 2; 52, 53) communiquent entre elles par l'intermédiaire du bus aéronautique dédié (51). 14. Système selon la revendication 1, caractérisé en ce qu'un des équipements aéronautiques est un équipement anticollision avion TCAS et un autre équipement aéronautique, un calculateur de vol FMS.