Note: Descriptions are shown in the official language in which they were submitted.
CA 02725292 2010-12-15
1
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
CA 02725292 2010-12-15
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
CA 02725292 2010-12-15
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;
CA 02725292 2010-12-15
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
CA 02725292 2010-12-15
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
CA 02725292 2010-12-15
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
CA 02725292 2010-12-15
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
CA 02725292 2010-12-15
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.
CA 02725292 2010-12-15
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.
CA 02725292 2010-12-15
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 à
CA 02725292 2010-12-15
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
CA 02725292 2010-12-15
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
CA 02725292 2010-12-15
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
CA 02725292 2010-12-15
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
CA 02725292 2010-12-15
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).
CA 02725292 2010-12-15
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é.
CA 02725292 2010-12-15
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
CA 02725292 2010-12-15
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.
