FR 2954026 A1 20110617 FR 0959077 A 20091216 La présente invention concerne un système de simulation ou de test d'une architecture réseau de calculateurs aéronautiques, notamment embarqué dans un aéronef, et un procédé correspondant. Le développement de systèmes réels est de nos jours réalisé progressivement à l'aide de systèmes de simulation. Ces systèmes permettent de visualiser et de tester des projets en cours mais également de faire évoluer ceux-ci rapidement et à moindres coûts. C'est le cas notamment dans le domaine aéronautique où l'on exploite des systèmes de simulation dans lesquels des équipements embarqués, également appelés calculateurs réels ou LRU ("Line Replaceable Units"), sont intégrés avec des modules simulant d'autres équipements embarqués. Dans les versions récentes d'aéronef, les calculateurs réels sont intégrés dans une architecture réseau numérique de type Ethernet adaptée à l'aéronautique et appelée réseau ADCN (« Avionics Data Communication Network ») utilisant la technologie AFDX (« Avionics Full DupleX switched Ethernet »). Ce réseau est composé de commutateurs au travers desquels les calculateurs communiquent. Dans ce réseau, les communications entre calculateurs sont réalisées en mode multidiffusion (multicast) non connecté, c'est-à-dire sans que le ou les destinataires des données n'accusent réception à l'émetteur. Les chemins que prennent les différentes données sont organisés sous forme de liens virtuels (« Virtual Link » ou « VL »). Un lien virtuel est un chemin logique au travers de différents commutateurs du réseau entre un calculateur émetteur et n calculateurs récepteurs. Ces liens virtuels permettent de définir autant de chemins logiques que nécessaire, étanches entre eux, et ayant des performances garanties malgré le recours à un réseau physique commun. L'ensemble de ces liens virtuels constitue la topologie logique du réseau. Pour garantir les performances requises et répondre aux contraintes de certification aéronautique, cette topologie logique est définie statiquement. Sur le réseau physique, les données échangées entre les calculateurs peuvent transiter via un ou plusieurs commutateurs en fonction de la topologie physique du réseau ADCN. Le document FR 2 868 567 présente un système de simulation prévu pour une telle architecture avionique. Dans ce système, une unité de simulation comprend des modèles simulant tout ou partie des calculateurs réels (sorte de logiciels constitués de fonctions des calculateurs alors simulés), et des fonctions de communication AFDX avec le réseau ADCN réel auquel elle est reliée. Les modèles de simulation sont intégrés au réseau numérique ADCN via les fonctions de communication. Grâce à cette intégration, les modèles de simulation communiquent entre eux ou avec des équipements embarqués, dans des conditions les plus proches possible de celles rencontrées dans l'aéronef réel. Pour interagir sur les simulations et/ou suivre les tests menés, on a recours à des outils dédiés, tels que des outils d'instrumentation et d'analyse, ou à des outils mobiles et partagés entre plusieurs systèmes, connectés temporairement à des points d'accès utilisateur prévus dans le système de simulation pour relever des informations circulant dans ce système. Ces outils, généralement mis en oeuvre sous forme d'applications logicielles externes à l'unité de simulation, sont consommateurs d'informations véhiculées dans le réseau, et notamment les messages émis par les divers calculateurs réels ou simulés. La récupération des messages peut être mise en oeuvre de diverses façons. D'un côté, l'unité de simulation peut être utilisée pour retransmettre, vers ces outils, les messages émis par les calculateurs, qu'elle récupère dans le but d'alimenter les modèles de simulation. Cette solution amène cependant une charge supplémentaire de traitement pour l'unité de simulation. De plus, l'ensemble des messages étant nécessaire aux outils, l'unité de simulation doit alors acquérir les messages inter-calculateurs réels (qui ne sont donc pas nécessairement utilisés par les modèles de simulation), augmentant encore sa charge de traitement. D'un autre côté, des outils d'acquisition des messages circulants sur le réseau peuvent être envisagés. Toutefois une telle acquisition doit être menée sur tous les segments du réseau sur lesquels un même message peut transiter, et produit donc de nombreux doublons de messages. Il en résulte également une surcharge inutile pour l'équipement d'acquisition, ainsi que d'éventuels traitements visant à supprimer les doublons avant transmission aux outils. Le présente invention vise à résoudre au moins l'un des problèmes de l'art antérieur, par l'agencement efficace d'un commutateur, notamment de ceux disponibles sur étagère, avec les commutateurs du réseau (ici ADCN) et son utilisation efficace. A cet effet, l'invention concerne notamment un système de simulation ou de test d'une architecture réseau de calculateurs aéronautiques, le système comprenant: un réseau de communication comprenant une pluralité de commutateurs; une pluralité de calculateurs réels connectés au réseau au niveau de commutateurs correspondants; et une unité de simulation simulant au moins un calculateur de ladite architecture, et connectée au réseau au niveau d'au moins un commutateur correspondant, caractérisé en ce que ledit système comprend: un commutateur tiers recevant, au niveau de ports d'entrée, des données acquises au niveau de ports de surveillances desdits commutateurs correspondants et émises par lesdits calculateurs (réels ou simulés notamment) sur le réseau, le commutateur tiers étant configuré pour dupliquer lesdites données sur une pluralité de ports de sortie à laquelle est connectée une pluralité d'applications consommatrices. Le commutateur tiers permet de distribuer une copie des messages diffusés sur le réseau sans traitement supplémentaire soit de l'unité de simulation, soit d'un quelconque équipement actif du réseau. Par ailleurs, l'utilisation des ports de surveillance (également nommés "ports monitoring") permet de limiter l'acquisition des messages qu'à un seul exemplaire. En effet, un commutateur du réseau produit, sur ses ports monitoring, uniquement une copie des messages émis par les calculateurs qui lui sont directement reliés. Ainsi, l'acquisition des messages au niveau des autres commutateurs n'aboutit pas à celle d'une nouvelle copie du message déjà acquis. En outre, tout calculateur étant relié à un commutateur correspondant du réseau, l'acquisition au niveau de tous les commutateurs permet d'assurer celle de tous les messages, à moindre coût eu égard au nombre de segments réseau qu'il faudrait surveiller dans les solutions de l'art antérieur. En outre, en gérant l'exploitation des ports monitoring au travers d'un réseau parallèle _ le commutateur étant tiers au réseau AFDX _ au réseau de communication, par exemple le réseau AFDX, on évite l'émission de données parasites vers ce dernier. On s'assure, dans ce cas, de cette étanchéité entre les deux réseaux, en évitant toute émission des outils dédiés/de surveillance vers le réseau ACDN. Dans un mode de réalisation, au moins une des applications consommatrices est l'unité de simulation. Ainsi, les messages émis sur le réseau par les calculateurs réels peuvent être acquis simplement par l'unité de simulation, sans surcoût. En effet, l'unité de simulation n'acquiert ainsi qu'un exemplaire de chaque message qu'elle peut rediriger vers les modèles de simulation cibles, alors qu'en utilisation normale, elle peut être amenée à acquérir plusieurs copies d'un même message pour autant de modèles cibles. On limite ainsi la charge de traitement pour l'acquisition par cette unité de simulation. En particulier, ledit commutateur tiers forme partie de moyens d'adaptation prévus entre ladite unité de simulation et ledit réseau de communication. Il s'agit par exemple d'une conversion de câblage sans adaptation électrique. On utilise ainsi, dans une configuration simple, les mêmes messages acquis pour le fonctionnement de la simulation (donc pour l'unité de simulation et ses modèles) et pour l'ensemble des autres applications consommatrices. En particulier, la duplication des données a lieu, au sein des moyens d'adaptation, après ladite adaptation (conversion de câblage par exemple). Cette adaptation délimite distinctement le domaine de l'avion (le réseau et les calculateurs réels) du domaine de simulation (l'unité de simulation). Ainsi, la configuration proposée ici offre une manipulation des données principalement dans le domaine de simulation, lequel s'apparente généralement à un réseau informatique classique, donc plus simple à mettre en oeuvre. Selon un caractéristique de l'invention, ledit commutateur tiers est configuré pour agréger les données d'une pluralité de ports d'entrée avant transmission sur un même port de sortie. Cette configuration permet de répondre à des besoins précis d'applications consommatrices potentiellement démunies de moyens de traitement. En outre, grâce à ce prétraitement par combinaison/agrégation, on économise des ports de sortie utilisés pour satisfaire un plus grand nombre d'applications consommatrices, étant donné que les commutateurs ont généralement un nombre limité de ports. Dans un mode de réalisation, ledit commutateur tiers est configuré pour filtrer lesdites données d'une pluralité de ports d'entrée avant émission sur un port de sortie. Cet autre prétraitement permet également de produire des données exploitables plus directement par les applications consommatrices. En particulier, ledit filtrage comprend la sélection de données issues d'au moins un calculateur, réel ou simulé, prédéfini. En d'autres termes, il s'agit d'un filtrage selon l'expéditeur des messages. En variante ou en combinaison, le critère de calculateur destinataire peut également être pris en compte. Le filtrage peut notamment s'appliquer sur des données déjà agrégées. Dans un mode de réalisation de l'invention, ledit commutateur tiers est configuré au moyen d'un fichier de configuration définissant des règles statiques de commutation des ports d'entrée aux ports de sortie du commutateur tiers. La configuration du commutateur pour répondre à de nouvelles demandes ou contraintes peut ainsi être réalisée simplement. On note en outre que ce mécanisme de configuration est compatible avec certains commutateurs sur étagère. En particulier, ledit fichier de configuration définit en outre un câblage externe entre les ports du commutateur tiers et les ports des équipements auxquels il est relié. Cette disposition permet, à l'aide du fichier de configuration, de générer rapidement une cartographie de connexions à réaliser sur le commutateur tiers. Cette dernière permet à un opérateur de connecter, sans difficulté ou multiples vérifications, les différents équipements au commutateur tiers. Selon une caractéristique particulière, lesdits règles statiques définissent l'agrégation par concaténation de données issues de plusieurs ports d'entrées et le filtrage par sélection d'au moins un calculateur émetteur des données. Dans un mode de réalisation, le commutateur tiers présente une pluralité d'ensembles de ports de sortie dupliquant à l'identique les données de l'ensemble des ports d'entrée, et un autre ensemble de ports de sortie configurables pour générer des sorties concaténant et/ou filtrant plusieurs ports d'entrée. La configuration ici permet de répondre à la fois aux besoins d'applications invariables dans le temps pour lesquelles on transmet l'ensemble des données des ports surveillés (par exemple l'unité de simulation qui récupère l'ensemble des messages à l'identique), et aux besoins plus spécifiques et plus temporaires d'outils particuliers. Encore une fois, l'agrégation de plusieurs entrées pour une sortie répondant à ces besoins spécifiques utilise efficacement les ressources du commutateur, et notamment le nombre de ports de sortie. Il est bien entendu que la configuration de l'autre ensemble peut être menée automatiquement au moyen du fichier de configuration évoquée plus haut. Corrélativement, l'invention concerne un procédé d'exploitation d'un système de simulation ou de test d'une architecture réseau de calculateurs aéronautiques, le système comprenant un réseau de communication comprenant une pluralité de commutateurs; des calculateurs réels connectés au réseau au niveau de commutateurs correspondants; et une unité de simulation simulant au moins un calculateur, et connectée au réseau au niveau d'au moins un commutateur correspondant, caractérisé en ce que ledit procédé comprend: - la réception, au niveau de ports d'entrée d'un commutateur tiers, de données acquises au niveau des ports de surveillances desdits commutateurs correspondants et émises par lesdits calculateurs sur le réseau, et - la duplication desdites données pour émission sur une pluralité de ports de sortie du commutateur tiers à laquelle est connectée une pluralité d'applications consommatrices. De façon optionnelle, le procédé peut comprendre des étapes se rapportant aux caractéristiques du système exposé précédemment. D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après, illustrée par les dessins ci-joints, dans lesquels : - la figure 1 représente un système de simulation d'une architecture de calculateurs embarqués ; - la figure 2 représente le système de la figure 1 intégrant l'objet de l'invention selon un mode de réalisation ; - la figure 3 illustre le commutateur tiers de la figure 2 ; et - la figure 4 représente un extrait simplifié d'un fichier de configuration du commutateur tiers de la figure 2. On a représenté sur la figure 1 un réseau ADCN prévu pour équiper un aéronef, et dont les spécifications sont adaptées au domaine aérien. Ce réseau repose sur la technologie de communication AFDX dont les prérequis relatifs à la qualité de service sont prévus pour assurer une utilisation temps-réel. Ce réseau 2, que l'on nomme ci-après réseau AFDX en lien avec la technologie de communication associée, interconnecte, entre eux, une pluralité d'équipements embarqués 11, 12, 12', 13, 14, c'est-à-dire des équipements réalisant des fonctions propres à l'aéronef, tels qu'un pilote automatique, des capteurs de vitesse et altimètres, etc. Ces équipements embarqués sont également appelés calculateurs ou LRU (« Line Replaceable Units ») et définissent le domaine 3 des calculateurs réels comprenant en pratique plusieurs dizaines de calculateurs. Dans les systèmes embarqués, il est répandu que les calculateurs soient dupliqués pour des questions de sécurité. Toutefois, chaque calculateur redondant est un calculateur à part entière, et ne sera donc pas traité différemment par la suite. Les connexions entre équipements du réseau sont réalisées au 10 travers d'un câblage et de connecteurs d'un premier type, par exemple des câbles Starquad et des connecteurs Quadrax. Le réseau 2 est un réseau numérique de commutation dans lequel différents commutateurs SW1-SW8 aiguillent les données véhiculées d'un bus AFDX vers un autre tronçon de bus AFDX. Ces commutateurs sont vus ici 15 comme des équipements d'aiguillage n'altérant pas le contenu des données véhiculées. Un schéma classique de réseau, comme représenté sur la figure, comprend huit commutateurs réseau auxquels est relié l'ensemble des calculateurs réels, chaque commutateur réseau étant redondé (respectivement SW11-SW18) de sorte à former deux réseaux parallèles: l'un nominal, l'autre 20 redondant. Comme on le voit sur la figure, chaque calculateur 11-14 du réseau 2 est connecté directement à un commutateur, dit "commutateur correspondant", qui est "son" point d'entrée dans le réseau 2 (respectivement SW1-SW4, et SW11-SW14 pour les commutateurs redondants). Plusieurs calculateurs (12, 25 12') peuvent être reliés à un même commutateur correspondant. Les échanges de données entre ces différents calculateurs 11-14 sont réalisés au format AFDX et en mode non connecté de type multidiffusion ("multicast"), c'est-à-dire une transmission de type 1 vers N destinataires. Ce mode de transmission est mis en oeuvre à l'aide d'un protocole de haut niveau 30 (au dessus d'UDP/IP) basé sur la notion de lien virtuel ("virtual link" ou VL) définissant statiquement, au niveau de chaque commutateur SWi, des règles de routage de messages. Cette configuration initiale des commutateurs pour aiguiller les données peut être menée à l'aide d'un fichier de configuration définissant l'architecture (ou topologie) réseau. On a également représenté sur cette figure une unité de simulation ou de test 100 prévue, lors des phases de développement d'aéronef ou de test, à simuler certains calculateurs prévus dans le système embarqué. Ici, les calculateurs 15 à 17 sont simulés au travers des modèles de simulations M15 à M17. Ces modèles sont exécutés par l'unité de simulation sous contrôle d'un logiciel de gestion globale de la simulation. Les simulations visent généralement à vérifier le fonctionnement d'un ou plusieurs nouveaux équipements dans le réseau. Bien entendu, le nombre de calculateurs simulés peut évoluer au cours des phases de test et de développement, par ajout ou suppression (activation/désactivation) d'un modèle de simulation. L'unité de simulation 100 est généralement mise en oeuvre sur un ordinateur personnel ou un serveur informatique classique, et est relié à d'autres équipements à l'aide d'un câblage et de connecteurs d'un deuxième type, par exemple des câbles Ethernet classiques munis de connecteurs FTP 100/RJ45. Pour interfacer le domaine de simulation, c'est-à-dire ici l'unité de simulation 100, avec le domaine de l'avion, ici le réseau AFDX 2 et les calculateurs réels 11-14, on prévoit une couche d'adaptation représentée ici par le bloc 4. Cette couche d'adaptation 4 comprend notamment un convertisseur 40 de câblage AFDX-Ethernet sans adaptation électrique pour faire correspondre les connecteurs du premier type avec ceux de deuxième type, ainsi que des racks de connexion 41 spécifiques à chaque modèle de simulation M; (le rack 4117 correspondant au modèle M17 et donc au calculateur réel 17) et venant se substituer, dans le réseau AFDX, aux calculateurs réels que l'on souhaite simuler dans le réseau AFDX. En venant substituer, dans le réseau, un rack 41 i à un calculateurs réel i, ou vice et versa, on fait évoluer le nombre de calculateurs simulés. Par ailleurs, la correspondance rack 41; û calculateurs réel i permet de conserver la topologie réseau lors de la substitution car on conserve ainsi la connexion du calculateurs i / modèle M; avec le commutateur réseau SWi correspondant. Un même commutateur SWi peut être, en même temps, le commutateur correspondant d'un ou plusieurs calculateurs réels et d'un ou plusieurs calculateurs simulés. Lors des opérations de simulations, l'unité de simulation 100 garantit que les communications concernant un modèle de simulation sont propagées uniquement au travers du rack correspondant. On considère maintenant deux messages transmis sur le réseau 2, l'un Mess13 représenté par des flèches vides et émis par le calculateur 13 à destination des calculateurs 14 (réel) et 15 (simulé), et l'autre Mess17 représenté par des flèches pleines et émis par le calculateur simulé 17 à destination du calculateur réel 11. Comme représenté sur la figure, le message Mess13 est propagé par les commutateurs SW3, SW4 et SW5 (et leurs redondants dans le réseau redondant), configurés statiquement au préalable, vers les calculateurs 14 et 15. Comme ce dernier est simulé, le message traverse le module d'adaptation 4, via le rack de connexion 4115, et est transmis au sein de l'unité de simulation pour traitement par le modèle M15. De même, le message Mess17 prend un chemin inverse le long d'un chemin virtuel VL défini avec le calculateur 11, via le rack 4117 et le commutateur SW7/SW17. La figure 2 représente un mode de réalisation de l'invention dans lequel le module d'adaptation 4 comprend en outre un moyen de commutation 42, par exemple un commutateur sur étagère doté de 192 ports physiques utiles. Les commutateurs SWi du réseau AFDX 2 possèdent chacun un ou plusieurs ports de surveillance, également nommés ports de « monitoring », PM, sur lesquels ils émettent automatiquement une copie de chaque message reçu d'un calculateur qui lui est directement relié. Grâce à la définition statique de la topologie du réseau, chaque commutateur SWi est capable d'identifier le précédent relayeur des messages qu'il reçoit (soit un autre commutateur, soit directement la source du message) et d'éviter de retransmettre sur le port monitoring les messages ayant déjà transité par d'autres commutateurs SWi. Les commutateurs SWi utilisés dans le domaine aérien présentent deux ports monitoring PM1 et PM2, par exemple. Dans la configuration de l'invention, chaque port monitoring des commutateurs SWi du réseau 2 est relié à un port physique d'entrée du commutateur 42. Dans notre exemple ci-dessus, il y a donc 32 ports de monitoring et 32 ports physiques d'entrée PE correspondant. Pour simplifier l'architecture, on peut uniquement relier les ports monitoring des commutateurs dits "correspondants", c'est-à-dire auxquels au moins un calculateur (qu'il soit simulé ou non) est directement relié. En effet, les commutateurs non "correspondants" ne diffuseront aucun message sur leurs ports monitoring. On diminue ainsi le nombre de ports d'entrée PE utilisés. Les messages transmis sur le réseau 2 sont ainsi automatiquement dupliqués au niveau des commutateurs "correspondants" SWi, puis transmis au commutateur 42 via les ports de monitoring (voir les traits plus épais, continus ou en pointillés, de la figure), après adaptation de câblage par le convertisseur 40. On montre également sur la figure la propagation d'une copie des messages Mess13 et Mess, (triangles vides et pleins) le long de ce chemin. Les ports de sortie du commutateur 42 sont alors connectés aux ports d'entrée d'une pluralité d'applications consommatrices de ces informations, représentées sur la partie gauche de la figure. La première application consommatrice est l'unité de simulation 100 qui peut ainsi récupérer les messages Mess émis sur le réseau en un seul exemplaire, alors qu'en l'absence du commutateur 42 un même message destiné à deux calculateurs simulés devait être acquis deux fois au niveau des deux racks correspondants. Vu le nombre important de calculateurs parfois simulés, cette acquisition simple peut réduire considérablement la charge de traitement de l'unité de simulation 100. On observe ainsi que les racks 41 ne sont utilisés que dans le sens sortant (depuis l'unité de simulation 100). Puisque ces copies récupérées sur les ports monitoring ne tiennent pas compte de l'état du réseau 2 (disponibilités ou non des commutateurs SWi), l'exploitation de ces copies par l'unité de simulation 100 peut en outre être conditionnée à la disponibilité des liens virtuels le long desquels ces copies doivent être transmises: par exemple, l'unité de simulation 100 s'assure que l'ensemble des commutateurs SWi d'un chemin VL est opérationnel avant d'exploiter la copie d'un message qui doit être diffusé le long de ce chemin. D'autres applications consommatrices 110, distinctes de l'unité de simulation, sont: - des outils temporaires connectés à des points d'accès utilisateur, outils notés UTAP (User Test Access Point), par lesquels l'utilisateur peut observer n'importe quel trafic de données d'un port de monitoring. A titre d'exemple, les points d'accès peuvent être de simples câbles volants auxquels l'utilisateur vient connecter, le cas échéant, un interpréteur de messages AFDX; - des outils consommateurs de ports bruts (c'est-à-dire sans traitement des messages) de surveillance, notés OBi (outils bruts), par exemple des outils d'instrumentation et d'analyse; - des outils consommateurs de tout ou partie des ports de surveillance avec traitement d'agrégation et/ou de filtrage des messages, notés OTi (outils traités). Les messages acquis au niveau des ports de monitoring PM des commutateurs SWi sont dupliqués au sein du commutateur 42 pour alimenter en entrée chacune des applications consommatrices 100/110. Pour l'exemple de huit commutateurs redondés et de deux ports monitoring par commutateur SWi, on manipule 32 signaux issus de ces ports de monitoring, comme illustré par le nombre "32" dans les flèches arrivant et sortant du convertisseur 40 sur la figure 2. La figure 3 illustre la façade d'un commutateur 42 tiers au réseau 2 muni de 192 ports physiques, sur laquelle 32 ports sont des ports d'entrée PE dédiés à l'acquisition des signaux récupérés au niveau des ports monitoring PM et des messages y circulant. Le commutateur 42 présente également une pluralité d'ensembles de ports de sortie dupliquant à l'identique les données de l'ensemble des ports d'entrée. Sur la figure 3, ces ensembles sont identifiés par les applications consommatrices destinataires, à savoir UTAP, OBI et l'unité de simulation 100 notée AFDXIF. Une distribution symétrique des ports au travers de ces différents ensembles est préférablement envisagée, c'est-à-dire que les ports de sortie ayant la même position physique au sein de leur ensemble respectif qu'un port d'entrée dans l'ensemble PE, distribue les mêmes données acquises au niveau de ce port d'entrée: par exemple, les données acquises sur le port PE8 sont dupliquées vers les ports UTAP8, OBI8 et AFDXIF8. Pour alimenter chacune des applications consommatrices UTAP, OBI et 100, on réalise un câblage direct, à l'aide de câbles du deuxième type (c'est-à-dire dans le domaine de simulation), entre chaque port de sortie de chaque ensemble et les ports d'entrée des équipements consommateurs correspondants. Le commutateur 42 présente également un autre ensemble de ports de sortie qui sont configurables dynamiquement en fonction de l'utilisation qui en est faite. Ces ports sont identifiés sur la figure par la notation OUTILS. Ces ports de sortie sont exploités par des outils plus spécifiques que ceux visés par les premiers ensembles AFDXIF, UTAP, OBi. Il s'agit des outils OTi. 32 ports forment cet ensemble et sont connectés aux applications consommatrices OTi via des câbles du deuxième type. Enfin, 32 autres ports peuvent être réservés, par exemple pour la mise en place de duplications à l'identique pour d'autres applications consommatrices OBi. La possibilité de configurer dynamiquement les ports OUTILS assure l'adaptation du système à des besoins évolutifs, que ce soit le nombre d'applications consommatrices spécifiques ou les besoins variables de celles-ci. Dans la configuration représentée sur la figure 3, certains ports de sortie de l'ensemble OUTILS sont configurés et utilisés par les applications consommatrices alors que d'autres sont prévus en tant que ports de secours/ports disponibles et non encore affectés (les ports numérotés 1 à 4 et 17 à 20 par exemples). Sur la figure 2, on a indiqué, à cet effet dans la flèche vers OUTILS, X ports utilisés et Y ports de secours (ici X+Y=32). Le nombre de ports utilisés peut varier dans le temps en fonction des besoins des applications OUTILS consommatrices et du nombre de celles-ci. Vu le faible nombre de ports de sortie OUTILS disponibles au regard du nombre de ports de monitoring acquis et du nombre d'applications consommatrices reliées à cet ensemble OUTILS, le commutateur 42 est en outre configuré pour réaliser des traitements entre les ports d'entrée PE; et les ports de sortie OUTILS. Deux principaux traitements peuvent être mis en oeuvre dans le commutateur 42, à savoir: - l'agrégation des trafics issus de plusieurs ports de monitoring (ports d'entrée PE), par concaténation des messages par exemple. Ainsi on génère, au niveau de certains ports de sortie OUTILS, des sorties composites de plusieurs ports d'entrée; - le filtrage des trafics de sortie en fonction de un ou plusieurs critères. Par exemple, un outil OB ne peut avoir besoin que du trafic correspondant à un calculateur émetteur ou destinataire particulier. Un tel filtrage selon l'émetteur/destinataire avant transmission sur le port de sortie permet, à moindre coût, de simplifier l'exploitation des données par l'application consommatrice connectée sur ce port de sortie. On peut ainsi utiliser des équipements consommateurs à faibles ressources. Ces deux traitements peuvent être mis en oeuvre indépendamment l'un de l'autre, ou consécutivement, par exemple d'abord l'agrégation de messages et ensuite un filtrage portant sur l'émetteur. La configuration dynamique du commutateur 42 est principalement menée par transfert d'un fichier de configuration établi par un utilisateur. Ce transfert peut être opéré sur un port série d'administration ou sur un port Ethernet du commutateur 42. La prise en compte du fichier de configuration par le commutateur peut être immédiate et conduire à une reconfiguration quasi instantanée, ou être repoussée à un redémarrage ultérieur du commutateur 42 ou à une action volontaire d'un opérateur. La conversion d'un fichier éditable en un fichier de configuration dans le langage propre au commutateur est prévue le cas échéant, en amont du transfert de fichier. La figure 4 présente une portion de fichier éditable prévu pour la configuration du commutateur 42 dans l'état représenté sur la figure 3. Le fichier définit le câblage externe entre les ports du commutateur 42 et les ports des équipements 40/100/OB1 auxquels il est relié, ainsi que des règles statiques de commutation des ports d'entrée aux ports de sortie du commutateur tiers. Pour illustrer ce fichier et la configuration correspondante, on 10 observe par exemple la ligne correspondant au port de monitoring 2 du commutateur SW3 (SW3-PORT 2). Cette ligne de configuration renseigne que le port de sortie n° 06 [col. C2] de l'adaptateur 40 alimente le port d'entrée PE11 [col. C3]. Ce port d'entrée est dupliqué [col. C4-C6] vers les ports de sortie UTAP11, OB111 (relié au port 15 d'entrée n° 06 de l'équipement OBI, voir col. C8) et AFDXIF11 (relié au port d'entrée n° B16 de l'unité de simulation 100, voir col. C9). On note qu'aucun port d'entrée d'un équipement UTAP n'est indiqué car il s'agit généralement de câbles volants à disposition des utilisateurs, et donc non reliés en permanence à un équipement. 20 Si l'on prend les lignes SW3_PORT 1, SW4_PORT 1, SW5_PORT 1 et SW6 PORT 1, la configuration prévoit en outre que les messages acquis sur ces ports sont transmis respectivement aux ports de sortie n°25, 27, 29 et 31 de l'ensemble OUTILS, et sont tous transmis au port de sortie n°15 de l'ensemble OUTILS [col. C7]. 25 Dans la colonne commentaire [col. C10], il est indiqué les applications consommatrices des données acquises au niveau de chaque port de monitoring PM, séparées par le caractère "1". Par exemple, l'entrée PE_13 (SW4 PORT1) est utilisée pour les applications UTAP (voir C4), OBI (voir C5), "AFDXIF" (c'est-à-dire l'unité de simulation, voir C6) et deux applications plus 30 spécifiques OT1 et OT2 reliées aux ports OUTILS (dans le même ordre que la colonne C7). Avec cette configuration, le commutateur prévoit une agrégation des messages issus des ports de monitoring SW3_PORT 1, SW4_PORT 1, SW5 PORT 1 et SW6 PORT 1, en un signal commun de sortie au niveau du port n°15 de l'ensemble OUTILS pour l'application OT2. Cette agrégation est notamment la concaténation des messages acquis pendant un intervalle temporel sur ces ports de monitoring PM. L'agrégation citée ci-dessus vers le port de sortie OUTILS_15 comprend en outre le filtrage des données agrégées en fonction du nom de l'émetteur, ici le calculateur identifié SOURCE_1, qui est indiqué entre crochets à la suite de l'application destinataire OT2 dans la colonne de commentaires. Le sigle "&" précédant "OT2" dans cette colonne est un marqueur indiquant au commutateur 42 qu'un filtrage doit être opéré. L'association des applications consommatrices aux ports de sortie OUTILS découle des ordres identiques de déclaration de celles-ci et des ports OUTILS dans les colonnes C7 et C10. C'est ainsi que l'application OT2 et le port OUTILS_15, tous deux cités en dernier, correspondent. On voit ici que ce fichier éditable permet de générer automatiquement et à moindre frais une cartographie de connexion sur le commutateur 42 comme partiellement représentée sur la figure 3. En configurant le commutateur 42 à l'aide du fichier de configuration de la figure 4, les applications consommatrices 100, UTAP et OBI reçoivent l'intégralité des messages sur 32 ports distincts correspondant aux 32 ports de monitoring. En outre, les applications OUTILS OT3 et OT3 reçoivent sur quatre ports distincts (respectivement connectés à OUTILS-5 à 8 et à OUTILS_9 à 12), respectivement les messages acquis au niveau des deux ports de monitoring des commutateurs SW1 et SW11 (redondants l'un à l'autre). L'application OUTILS OT5 reçoit, sur quatre ports distincts, les messages acquis au niveau des ports monitoring n°1 des commutateurs SW1, 30 SW2 et de leurs redondants SW11 et SW12. L'application OUTILS OT1 reçoit, sur quatre ports distincts, les messages acquis au niveau des ports monitoring n°1 des commutateurs SW3 à SW6, sans leurs redondants. Enfin, l'application OUTILS OT2 reçoit, quant à elle, sur un unique port connecté au port de sortie OUTILS_15, la concaténation des messages issus des ports de monitoring n°1 des commutateurs SW3 à SW6 et uniquement émis par le calculateur SOURCE_1. Les exemples qui précèdent ne sont que des modes de réalisation de l'invention qui ne s'y limite pas. Notamment, le commutateur 42 peut être mis en oeuvre sous la forme de plusieurs commutateurs sur étagères interconnectés. Toutefois l'utilisation d'un unique commutateur disposant d'un grand nombre de ports utiles permet d'offrir une interface de supervision commune, permet une configuration commune de l'ensemble des ports, permet une affectation souple des ensembles de ports de sortie car non soumise à des contraintes de liaison inter-commutateurs et offre généralement une alimentation redondée. Par ailleurs, le commutateur 42 peut être distinct de l'interface d'adaptation 4. Dans ce cas, on peut prévoit que l'unité de simulation 100 acquiert les messages de façon classiquement directement sur le réseau 2 au niveau des racks 41, et qu'en parallèle, le commutateur 42 relié aux ports monitoring alimente, comme décrit précédemment, les applications consommatrices UTAP, OBi, OTi.25 REVENDICATIONS1. Système de simulation ou de test d'une architecture réseau de calculateurs aéronautiques, le système comprenant: un réseau de communication (2) comprenant une pluralité de commutateurs (SW 1-SW8); une pluralité de calculateurs réels (11-14) connectés au réseau (2) au niveau de commutateurs correspondants (SW1-SW4); et une unité de simulation (100) simulant au moins un calculateur (15-17) de ladite architecture, et connectée au réseau (2) au niveau d'au moins un commutateur correspondant (SW5-SW8), caractérisé en ce que ledit système comprend: un commutateur tiers (42) recevant, au niveau de ports d'entrée (PE), des données (Mess13, Mess,) acquises au niveau de ports de surveillances (PM) desdits commutateurs correspondants (SW1-SW8) et émises par lesdits calculateurs (11-17) sur le réseau (2), le commutateur tiers étant configuré pour dupliquer lesdites données sur une pluralité de ports de sortie (UTAPj, OB1j, AFDXIFj, OTij) à laquelle est connectée une pluralité d'applications consommatrices (100, 110, UTAP, OBi, OTi). 2. Système selon la revendication 1, dans lequel au moins une des applications consommatrices est l'unité de simulation (100). 3. Système selon la revendication 1 ou 2, dans lequel ledit commutateur tiers (42) forme partie de moyens d'adaptation (4) prévus entre ladite unité de simulation (100) et ledit réseau de communication (2). 4. Système selon la revendication précédente, dans lequel la duplication des données a lieu, au sein des moyens d'adaptation (4), après ladite adaptation. 5. Système selon l'une des revendications précédentes, dans lequel ledit commutateur tiers (42) est configuré pour agréger les données d'une pluralité de ports d'entrée (PE) avant transmission sur un même port de sortie. 6. Système selon l'une des revendications précédentes, dans lequel ledit commutateur tiers (42) est configuré pour filtrer lesdites données d'une pluralité de ports d'entrée (PE) avant émission sur un port de sortie. 7. Système selon la revendication précédente, dans lequel ledit filtrage comprend la sélection de données issues d'au moins un calculateur (11- 17), réel ou simulé, prédéfini. 8. Système selon l'une des revendications précédentes, dans lequel ledit commutateur tiers (42) est configuré au moyen d'un fichier de configuration définissant des règles statiques de commutation des ports d'entrée aux ports de sortie du commutateur tiers (42). 9. Système selon l'une des revendications précédentes, dans lequel le commutateur tiers présente une pluralité d'ensembles (UTAP, OBI, AFDXIF) de ports de sortie dupliquant à l'identique les données de l'ensemble des ports d'entrée (PE), et un autre ensemble (OUTILS) de ports de sortie configurables pour générer des sorties concaténant et/ou filtrant plusieurs ports d'entrée. 10. Procédé d'exploitation d'un système de simulation ou de test d'une architecture réseau de calculateurs aéronautiques, le système comprenant un réseau de communication (2) comprenant une pluralité de commutateurs (SW1-SW8); des calculateurs réels (11-14) connectés au réseau (2) au niveau de commutateurs correspondants (SW1-SW4); et une unité de simulation (100) simulant au moins un calculateur (15-17), et connectée au réseau (2) au niveau d'au moins un commutateur correspondant (SW5-SW8), caractérisé en ce que ledit procédé comprend: - la réception, au niveau de ports d'entrée (PE) d'un commutateur tiers (42), de données (Mess13, Mess,) acquises au niveau des ports de surveillances (PM) desdits commutateurs correspondants (SW1-SW8) et émises par lesdits calculateurs (11-17) sur le réseau (2), et - la duplication desdites données pour émission sur une pluralité de ports de sortie (UTAPj, OB1j, AFDXIFj, OTij) du commutateur tiers (42) à laquelle est connectée une pluralité d'applications consommatrices (100, 110, UTAP, OBi, OTi).