CA2725292A1 - Systeme et procede de simulation ou de test exploitant des donnees issues de ports de surveillance - Google Patents
Systeme et procede de simulation ou de test exploitant des donnees issues de ports de surveillance Download PDFInfo
- Publication number
- CA2725292A1 CA2725292A1 CA2725292A CA2725292A CA2725292A1 CA 2725292 A1 CA2725292 A1 CA 2725292A1 CA 2725292 A CA2725292 A CA 2725292A CA 2725292 A CA2725292 A CA 2725292A CA 2725292 A1 CA2725292 A1 CA 2725292A1
- Authority
- CA
- Canada
- Prior art keywords
- ports
- switch
- network
- switches
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/20—Support for services
- H04L49/201—Multicast operation; Broadcast operation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/20—Support for services
- H04L49/205—Quality of Service based
- H04L49/206—Real Time traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/14—Network analysis or design
- H04L41/145—Network analysis or design involving simulating, designing, planning or modelling of a network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/50—Testing arrangements
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Quality & Reliability (AREA)
- Small-Scale Networks (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
La présente invention concerne un système de simulation/ test d'une architecture réseau de calculateurs aéronautiques, notamment embarqué dans un aéronef, et un procédé correspondant. Le système comprend: - un réseau de communication (2) comprenant une pluralité de commutateurs (SW1-SW8); - une pluralité de calculateurs réels (11-14) connectés au réseau au niveau de commutateurs correspondants (SW1-SW4); - une unité de simulation (100) simulant au moins un calculateur (15-17) de ladite architecture, et connectée au réseau au niveau d'au moins un commutateur correspondant (SW5-SW8), et - un commutateur tiers (42) recevant, au niveau de ports d'entrée (PE), des données (Mess13, Mess17) acquises au niveau de ports de surveillances (PM) desdits commutateurs correspondants et émises par lesdits calculateurs sur le réseau, et étant configuré pour dupliquer lesdites données sur une pluralité de ports de sortie (UTAP j, OB1j, AFDXIF j, OTi j) à laquelle est connectés une pluralité d'applications consommatrices (100, 110, UTAP, OBi, OTi).
Description
FIELD OF THE INVENTION
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.
BACKGROUND OF THE INVENTION
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
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.
BACKGROUND OF THE INVENTION
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
2 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.
On connaît le document "Evaluation des performances temps-réel de réseaux embarqués avioniques" (H. Charara, 2007) qui modélise un tel réseau avionique AFDX et le trafic y circulant en fonction des liens virtuels VL, par la suppression de chemins dits "non ou indirectement influents".
D'une façon générale, 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
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.
On connaît le document "Evaluation des performances temps-réel de réseaux embarqués avioniques" (H. Charara, 2007) qui modélise un tel réseau avionique AFDX et le trafic y circulant en fonction des liens virtuels VL, par la suppression de chemins dits "non ou indirectement influents".
D'une façon générale, 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
3 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.
SUMMARY OF THE INVENTION
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;
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.
SUMMARY OF THE INVENTION
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;
4 une pluralité de calculateurs réels connectés au réseau respectivement au niveau d'un des commutateurs, dit commutateur correspondant; 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 dit correspondant, caractérisé en ce que ledit système comprend:
un commutateur, dit 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
un commutateur, dit 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
5 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
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
6 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
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
7 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.
II 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 respectivement au niveau d'un des commutateurs, dit commutateur correspondant; et une unité de simulation simulant au moins un calculateur, et connectée au réseau au niveau d'au moins un commutateur dit correspondant, caractérisé en ce que ledit procédé comprend:
- la réception, au niveau de ports d'entrée d'un commutateur, dit 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.
BRIEF DESCRIPTION OF THE FIGURES
II 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 respectivement au niveau d'un des commutateurs, dit commutateur correspondant; et une unité de simulation simulant au moins un calculateur, et connectée au réseau au niveau d'au moins un commutateur dit correspondant, caractérisé en ce que ledit procédé comprend:
- la réception, au niveau de ports d'entrée d'un commutateur, dit 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.
BRIEF DESCRIPTION OF THE FIGURES
8 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.
DETAILED DESCRIPTION OF AN EMBODIMENT OF THE INVENTION
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 travers d'un câblage et de connecteurs d'un premier type, par exemple des câbles Starquad et des connecteurs Quadrax.
- 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.
DETAILED DESCRIPTION OF AN EMBODIMENT OF THE INVENTION
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 travers d'un câblage et de connecteurs d'un premier type, par exemple des câbles Starquad et des connecteurs Quadrax.
9 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 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 SW 11-SW 18) de sorte à former deux réseaux parallèles: l'un nominal, l'autre 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, 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 (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 5 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 FTP100/RJ45.
Pour interfacer le domaine de simulation, c'est-à-dire ici l'unité de
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, 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 (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 5 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 FTP100/RJ45.
Pour interfacer le domaine de simulation, c'est-à-dire ici l'unité de
10 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; à 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 SW; 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 à
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; à 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 SW; 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 à
11 destination des calculateurs 14 (réel) et 15 (simulé), et l'autre Messe 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
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
12 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 Mess17 (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
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 Mess17 (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
13 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, OB1 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, OB18 et AFDXIF8. Pour alimenter chacune des applications consommatrices UTAP, OB1 et 100, on réalise un câblage direct, à l'aide de câbles du deuxième type (c'est-à-dire dans le
- 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, OB1 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, OB18 et AFDXIF8. Pour alimenter chacune des applications consommatrices UTAP, OB1 et 100, on réalise un câblage direct, à l'aide de câbles du deuxième type (c'est-à-dire dans le
14 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 5 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.
10 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
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 5 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.
10 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
15 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 observe par exemple la ligne correspondant au port de monitoring 2 du commutateur SW3 (SW3-PORT 2).
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 observe par exemple la ligne correspondant au port de monitoring 2 du commutateur SW3 (SW3-PORT 2).
16 Cette ligne de configuration renseigne que le port de sortie n 06 [col.
C2] de l'adaptateur 40 alimente le port d'entrée PE,1 [col. C3]. Ce port d'entrée est dupliqué [col. C4-C6] vers les ports de sortie UTAP11, OB11, (relié au port d'entrée n 06 de l'équipement OB1, 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.
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].
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 "J". Par exemple, l'entrée PE_13 (SW4_PORT1) est utilisée pour les applications UTAP (voir C4), OB1 (voir C5), "AFDXIF" (c'est-à-dire l'unité de simulation, voir C6) et deux applications plus 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é.
C2] de l'adaptateur 40 alimente le port d'entrée PE,1 [col. C3]. Ce port d'entrée est dupliqué [col. C4-C6] vers les ports de sortie UTAP11, OB11, (relié au port d'entrée n 06 de l'équipement OB1, 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.
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].
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 "J". Par exemple, l'entrée PE_13 (SW4_PORT1) est utilisée pour les applications UTAP (voir C4), OB1 (voir C5), "AFDXIF" (c'est-à-dire l'unité de simulation, voir C6) et deux applications plus 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é.
17 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 OB1 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 SW1 1 (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, 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
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 OB1 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 SW1 1 (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, 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
18 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.
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.
Claims (10)
1. 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 respectivement au niveau d'un des commutateurs, dit commutateur correspondant; 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 dit correspondant, caractérisé en ce que ledit système comprend:
un commutateur, dit 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 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.
- un réseau de communication comprenant une pluralité de commutateurs;
- une pluralité de calculateurs réels connectés au réseau respectivement au niveau d'un des commutateurs, dit commutateur correspondant; 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 dit correspondant, caractérisé en ce que ledit système comprend:
un commutateur, dit 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 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.
2. Système selon la revendication 1, dans lequel au moins une des applications consommatrices est l'unité de simulation.
3. Système selon la revendication 1 ou 2, dans lequel ledit commutateur tiers forme partie de moyens d'adaptation prévus entre ladite unité
de simulation et ledit réseau de communication.
de simulation et ledit réseau de communication.
4. Système selon la revendication 3, dans lequel la duplication des données a lieu, au sein des moyens d'adaptation, après ladite adaptation.
5. Système selon la revendication 1 ou 2, dans lequel 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.
6. Système selon la revendication 1 ou 2, dans lequel 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.
de ports d'entrée avant émission sur un port de sortie.
7. Système selon la revendication 6, dans lequel ledit filtrage comprend la sélection de données issues d'au moins un calculateur, réel ou simulé, prédéfini.
8. Système selon la revendication 1 ou 2, dans lequel 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.
9. Système selon la revendication 1 ou 2, dans lequel 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.
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 comprenant une pluralité de commutateurs; des calculateurs réels connectés au réseau respectivement au niveau d'un des commutateurs, dit commutateur correspondant; et une unité de simulation simulant au moins un calculateur, et connectée au réseau au niveau d'au moins un commutateur dit correspondant, caractérisé en ce que ledit procédé comprend:
- la réception, au niveau de ports d'entrée d'un commutateur, dit 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.
- la réception, au niveau de ports d'entrée d'un commutateur, dit 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.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FR0959077A FR2954026B1 (fr) | 2009-12-16 | 2009-12-16 | Systeme et procede de simulation ou de test exploitant des donnees issues de ports de surveillance |
FR0959077 | 2009-12-16 |
Publications (1)
Publication Number | Publication Date |
---|---|
CA2725292A1 true CA2725292A1 (fr) | 2011-06-16 |
Family
ID=42226663
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CA2725292A Abandoned CA2725292A1 (fr) | 2009-12-16 | 2010-12-15 | Systeme et procede de simulation ou de test exploitant des donnees issues de ports de surveillance |
Country Status (3)
Country | Link |
---|---|
US (1) | US20110154108A1 (fr) |
CA (1) | CA2725292A1 (fr) |
FR (1) | FR2954026B1 (fr) |
Families Citing this family (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20120203401A1 (en) * | 2011-02-08 | 2012-08-09 | Jonathan Mark Dunsdon | Onboard Maintenance System Network Optimization |
FR3034601A1 (fr) * | 2015-03-31 | 2016-10-07 | Thales Sa | Reseau de communication, installation de communication a bord d'un aeronef et aeronef comprenant une telle installation de communication |
CN105391598A (zh) * | 2015-11-10 | 2016-03-09 | 上海斐讯数据通信技术有限公司 | 一种结合基本路径法的黑盒测试用例设计方法 |
FR3071119B1 (fr) * | 2017-09-11 | 2019-09-13 | Thales | Reseau de communication, systeme de mesure, moyen de transport et procede de construction d'un reseau de communication associes |
US11451586B2 (en) * | 2018-08-29 | 2022-09-20 | Panasonic Avionics Corporation | Network security attack misdirection on a transport vehicle |
FR3091440B1 (fr) * | 2018-12-26 | 2021-01-15 | Thales Sa | Commutateur comportant un port d’observabilité et système de communication comportant un tel commutateur |
CN110557303B (zh) * | 2019-09-09 | 2021-04-20 | 网易(杭州)网络有限公司 | 网络多出口测试平台系统及测试方法 |
CN111431766A (zh) * | 2020-03-20 | 2020-07-17 | 深圳震有科技股份有限公司 | 一种交换机的端口测试方法和系统 |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
FR2868567B1 (fr) * | 2004-04-02 | 2008-03-14 | Airbus France Sas | Systeme de simulation et de test d'au moins un equipement sur un reseau afdx |
US20060215568A1 (en) * | 2005-03-28 | 2006-09-28 | Honeywell International, Inc. | System and method for data collection in an avionics network |
JP5059017B2 (ja) * | 2006-09-27 | 2012-10-24 | 富士通テン株式会社 | シミュレーション装置 |
US8135807B2 (en) * | 2007-09-18 | 2012-03-13 | The Boeing Company | Packet generator for a communication network |
US20090080421A1 (en) * | 2007-09-21 | 2009-03-26 | Ou Frank Y | Data flow mirroring |
FR2947127B1 (fr) * | 2009-06-23 | 2011-06-10 | Airbus France | Systeme de simulation ou de test, et procede associe. |
-
2009
- 2009-12-16 FR FR0959077A patent/FR2954026B1/fr not_active Expired - Fee Related
-
2010
- 2010-12-15 CA CA2725292A patent/CA2725292A1/fr not_active Abandoned
- 2010-12-16 US US12/970,136 patent/US20110154108A1/en not_active Abandoned
Also Published As
Publication number | Publication date |
---|---|
FR2954026B1 (fr) | 2012-11-30 |
US20110154108A1 (en) | 2011-06-23 |
FR2954026A1 (fr) | 2011-06-17 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CA2725292A1 (fr) | Systeme et procede de simulation ou de test exploitant des donnees issues de ports de surveillance | |
EP2145426B1 (fr) | Systeme de communication entre un reseau d'ordinateurs dans un aeronef et un reseau d'ordinateurs au sol | |
EP2320603A1 (fr) | Système de communication dans un aéronef | |
EP2306672B1 (fr) | Méthode de génération de fichiers de configuration d'interface pour calculateurs d'une plateforme avionique | |
FR2804227A1 (fr) | Ensemble de pilotage et/ou de controle d'organes fonctionnels d'un avion | |
FR3032078A1 (fr) | Architecture hybride de transmission d'informations avioniques et systeme correspondant | |
FR2992620A1 (fr) | Train et procede de determination de la composition d'un tel train en securite | |
CN105634832A (zh) | 一种服务器的备份方法和装置 | |
Van Hook et al. | An approach to DIS scalability | |
FR3045256A1 (fr) | Reseau de communication embarque d'un vehicule et abonne d'un tel reseau de communication | |
WO2014079629A1 (fr) | Dispositif et procede de retransmission de donnees dans un commutateur reseau | |
FR3014622A1 (fr) | Architecture de transmission de donnees critiques dans des systemes avioniques | |
FR2947127A1 (fr) | Systeme de simulation ou de test, et procede associe. | |
EP1997295A2 (fr) | Procede de communication de donnees entre des systemes de traitement heterogenes connectes en reseau local et systeme de communication mettant en oeuvre ce procede | |
EP2751959A1 (fr) | Procédé d'échange de données entre noeuds d'une grappe de serveurs et grappe de serveurs mettant en oeuvre ce procédé | |
FR3049141A1 (fr) | Reseau de communication | |
EP0812084A1 (fr) | Dispositif de communication entre une pluralité de modules fontionnels installés dans une unité locale et un bus externe de type ethernet | |
CN106961475A (zh) | 一种基于nbd的远程磁盘共享方法和共享系统 | |
CN103491079B (zh) | 一种报文生成装置、服务器以及方法 | |
EP3122005A1 (fr) | Système de routage permettant le filtrage de données pour l'intégration et le test d'équipements opérationnels | |
WO2015177452A1 (fr) | Commutateur de trames numeriques | |
EP3398294B1 (fr) | Reseau de communication | |
EP1654830A2 (fr) | Procede de diffusion d information multicast etendue, system e et produit logiciel correspondant | |
CN109347851A (zh) | 一种请求响应方法及装置 | |
CN117596284B (zh) | 数据传输的方法、装置、计算机设备和存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
FZDE | Discontinued |
Effective date: 20151215 |