FR 2848051 A1 20040604 FR 0215240 A 20021203 Passerelle et procédé pour l'interconnexion de deux réseaux, notamment un réseau HAVi et un réseau UPnP. Le domaine de l'invention est celui des passerelles (" gateway ") permettant l'interconnexion de réseaux permettant chacun de réaliser des communications entre une pluralité d'équipements. Plus précisément, l'invention concerne une passerelle permettant l'interconnexion d'un premier réseau, d'un premier type et permettant de réaliser des communications entre une pluralité d'équipements conformes à une première norme d'interopérabilité entre équipements, et un second réseau, d'un second type et 10 permettant de réaliser des communications entre une pluralité d'équipements conformes à une seconde norme d'interopérabilité entre équipements. On suppose que le second type de réseau est différent du premier type de réseau. En revanche, la seconde norme d'interopérabilité entre équipements peut être soit identique à soit différente de la première norme d'interopérabilité entre équipements. D'une façon générale, une passerelle possède des fonctionnalités permettant notamment de rendre visibles les équipements du premier réseau au second réseau et inversement, d'établir des communications entre plusieurs équipements appartenant a un même réseau ou à des réseaux différents, de permettre le transfert de données (asynchrone ou isochrone) entre les deux réseaux, etc. La présente invention vise à résoudre des problèmes précis identifiés du côté du premier réseau (typiquement 1394 dans le contexte particulier précisé ci-après) de la passerelle. En d'autres termes, l'invention décrit une technique pour rendre visible des équipements du second réseau dans le premier réseau. Typiquement, les premier et second réseaux sont des réseaux audiovisuels 25 domestiques, permettant de réaliser des communications entre des équipements audio et/ou vidéo, de type analogique et/ou numérique, afin qu'ils échangent des signaux audiovisuels. Les équipements précités appartiennent par exemple à la liste d'équipements suivante (qui n'est pas exhaustive): récepteurs de télévision (par satellite, par voie 30 hertzienne, par câble, xDSL, ... ), téléviseurs, magnétoscopes, scanners, caméras numériques, appareils photo numériques, lecteurs DVD, ordinateurs, assistants numériques personnels (PDA), imprimantes, etc. L'invention s'applique notamment, mais non exclusivement, dans le contexte particulier o le premier réseau est un bus selon la norme IEEE 1394, auquel sont 5 connectés des équipements conformes à la norme HAVi, et le second réseau est un réseau IP (basé sur le protocole internet) auquel sont connectés des équipements conformes à la norme UPnP. La norme IEEE 1394 est décrite dans les documents de référence suivants " IEEE Std 1394-1995, Standard for High Performance Serial Bus " et " IEEE Std 10 1394a-2000, Standard for High Performance Serial Bus (Supplement) ". La norme HAVi est décrite dans le document de référence " HAVi (Home Audio Video interoperability) spécifications (version 1.1 May 15, 2001) ". La norme UPnP est décrite dans le document de référence " UPnP (Universal Plug and Play) architecture specification (version 1.0 June 8, 2000) ". Dans un souci de simplification, on discute les inconvénients de l'art antérieur en relation avec le contexte particulier précité (IEEE1394-HAVi / IP-UPnP). Il est clair cependant que la présente invention n'est pas limitée à cette combinaison particulière de normes. On rappelle que les normes d'interopérabilité entre équipements, notamment les 20 normes HAVi et UPnP, définissent chacune une couche logicielle intermédiaire (" Middleware layer ") assurant l'interface entre, d'une part un ensemble de couches basses, notamment de communication et de transport, et, d'autre part un ensemble de couches supérieures d'application. En d'autres termes, chacune de ces normes fournit des services et fonctions standardisés (par exemple une interface de programmation 25 d'applications (API, pour " Application Programming Interface " en anglais)), sur lesquels peuvent être développés des applications, indépendamment des implémentations des réseaux. Les normes HAVi et UPnP résultent de deux initiatives au sein de l'industrie, pour répondre à des besoins différents. Selon la tendance actuelle, on considère que la 30 norme HAVi convient aux équipements audiovisuels connectés à un bus IEEE 1394, et la norme UPnP convient aux équipements audiovisuels connectés à un réseau IP. Or, on souhaite que ces deux types d'équipements (" équipements HAVi " et " équipements UPnP ") soient présents dans un réseau audiovisuel domestique. Par conséquent, il convient de traiter la question de la coexistence des normes HAVi et UPnP. On rappelle maintenant, en relation avec les figures 1 et 2, quelques caractéristiques définies dans la norme HAVi. La figure 1 présente un exemple d'architecture matérielle d'un équipement HAVi. Cette architecture matérielle comprend, de façon classique: un bus 200 permettant d'interconnecter les éléments listés ci-après, une unité centrale (CPU) 201, une horloge 202, un système interne 203, un clavier 204, une mémoire de type RAM 10 205, une mémoire de type ROM 206, un système d'entrée/sortie 207, un moyen d'affichage (écran) 208 et un adaptateur réseau 209. La figure 2 présente un exemple d'architecture logicielle d'un équipement HAVi. Cette architecture logicielle, stockée dans la mémoire de type ROM 206 et mise en oeuvre dans la mémoire de type RAM 205 (voir figure 1) de l'équipement HAVi, 15 comprend: - un ensemble 210 de couches basses, notamment de communication et de transport, formant une plate-forme " spécifique vendeur " (c'est-à-dire propre au fabricant de l'équipement) 215 connectée au bus numérique 216 de type IEEE 1394; - un ensemble 211 de couches supérieures d'application, comprenant des modules d'application (AM) 213 et des modules " Havlet " 214; - une couche intermédiaire (" pile HAVi ") 212, assurant l'interface entre l'ensemble 210 de couches basses et l'ensemble 211 de couches supérieures. La pile HAVi 212 comprend elle-même: - un gestionnaire 217 de média de communication 1394 (1394 CMM), en charge des aspects communication de type IEEE 1394; - un système de messagerie 218, permettant de faire communiquer tous les autres modules de la pile HAVi; - un gestionnaire (ou module de gestion) 219 d'enregistrement (Registry); - un gestionnaire (ou module de gestion) 220 d'évènements (Event Manager); - un gestionnaire (ou module de gestion) 221 de flux (Stream Manager, SM). Il permet d'établir une connexion de flux entre deux équipements; - un gestionnaire (ou module de gestion) 222 de ressources (Ressource Manager); - un gestionnaire (ou module de gestion) 223 de modules de commandes (DCM Manager); - des modules de commande d'équipement (DCM) 224, et des modules de commande de fonction (FCM) (non représentés), permettant chacun de commander un équipement HAVi. Les modules de commande de fonction (FCM) sont des " sous-modules " des modules de commande d'équipement 10 (DCM). Selon la terminologie HAVi, l'ensemble des modules précités (213, 214, 219 à 224), qui sont hébergés par les équipements, sont appelés " modules fonctionnels élémentaires " (SE, pour " Software Element " en anglais). En fonction des modules qu'ils implémentent (notamment parmi ceux listés ci15 dessus), on peut distinguer quatre types d'équipements HAVi, pouvant être regroupés en deux catégories: - les équipements FAV (" Full AudioVideo ") et IAV (" Intermediate AudioVideo "), qui sont des équipements " intelligents " au sens HAVi (c'est-àdire des équipements aptes à contrôler d'autres équipements); - les équipements BAV (" Base AudioVideo ") et LAV (" Legacy AudioVideo "), qui sont des équipements " non-intelligents " au sens HAVi (c'est-à-dire des équipements contrôlés par d'autres équipements). Il est également important de rappeler que la norme HAVi (version 1.1) définit une notion essentielle d'identifiant unique HAVi (ou HUID, pour " HAVi Unique 25 Identifier "). Selon cette notion, certains modules fonctionnels élémentaires (" Software Element "), à savoir les modules d'application (AM), les modules de commande d'équipement (DCM) et les modules de commande de fonction (FCM), possèdent chacun identifiant unique HUID. Cet identifiant unique HUID comprend notamment un champ important, appelé " TargetId ", comprenant lui-même notamment un sous- champ 30 " type " et un sous-champ " GUID ". Le sous-champ " type " indique si le module fonctionnel élémentaire concerné est un module d'application (AM), un module de commande d'équipement (DCM) ou un module de commande de fonction (FCM). Dans les deux derniers cas, ce sous-champ indique également si l'équipement commandé est compatible IEC 61883 (c'est-à-dire si des registres IEC 61883 y sont physiquement localisés). Le sous-champ " GUID " indique l'identifiant unique global (ou GUID, pour " Global Unique Identifier ") de l'équipement à utiliser pour les communications IEEE 1394 avec le module fonctionnel élémentaire concerné. On distingue les cas suivants: - si le module fonctionnel élémentaire concerné est un module de commande d'équipement (DCM) ou un module de commande de fonction (FCM), et si l'équipement commandé est compatible IEC 61883, l'identifiant GUID indiqué est celui de l'équipement commandé; - si le module fonctionnel élémentaire concerné est un module de commande d'équipement (DCM) ou un module de commande de fonction (FCM), et si 15 l'équipement commandé n'est pas compatible IEC 61883, l'identifiant GUID indiqué est celui de l'équipement " hôte " qui héberge le module fonctionnel élémentaire concerné; - si le module fonctionnel élémentaire concerné est un module d'application (AM), l'identifiant GUID indiqué est celui de l'équipement " hôte " qui 20 héberge le module fonctionnel élémentaire concerné. On notera que dans la norme HAVi, les deux relations bijectives suivantes sont définies: (i) à chaque équipement correspond un seul identifiant GUID; (ii) à chaque équipement correspond une seule adresse 1394. La figure 3 présente un exemple d'utilisation d'une passerelle 1 selon l'art antérieur, dans le contexte particulier précité. Le premier réseau 2 est un bus selon la norme IEEE 1394. Dans cet exemple, deux équipements HAVi y sont connectés: l'un, référencé A, est un équipement HAVi BAV (par exemple un magnétoscope numérique (DVCR)) ou LAV (par exemple un 30 caméscope numérique) et l'autre, référencé C, est un équipement HAVi IAV (par exemple une Set-Top-Box (STB, ou récepteur/tuner satellite ou câble)) ou FAV (par exemple une télévision numérique (DTV)). L'équipement C héberge (au sens "exécute") un module de gestion de flux (SM) référencé 5, ainsi que le module de commande (DCM) de l'équipement A. Ce module de commande, référencé 4, est symbolisé sur la figure 3 par un cercle contenant la lettre A. On notera que les équipements HAVi peuvent " stocker " le programme d'un ou plusieurs modules de commande (DCM), sans que ces programmes ne soient activés. Après activation de ce ou ces programme(s) en vue de leur exécution, on considère que l'équipement considéré " héberge " le module de commande (DCM) associé. On notera également que, dans un souci de simplification, on discute ici uniquement le cas des modules de commande d'équipement (DCM). Il est clair cependant que cette discussion peut être directement transposée aux modules de commande de fonction (FCM). Le second réseau 3 est un réseau IP. Dans cet exemple, deux équipements UPnP 15 y sont connectés: l'un, référencé B, est un équipement contrôlé (UPnP Controlled Device) et l'autre, référencé D, est un équipement apte à contrôler (UPnP Control Point) les autres équipements. Dans cet exemple, on suppose que les deux équipements UPnP, référencés B et D, peuvent être impliqués dans une connexion de flux. Par exemple, l'équipement B est une " webcam " pouvant générer un flux de données vidéo, et 20 l'équipement D est un ordinateur personnel (PC) capable de restituer le flux de données vidéo. Après leur détection du côté du réseau IP 3, les équipements B et D sont représentés du côté HAVi de la passerelle 1 par deux modules de commande (DCM). Ces derniers, référencés 6 et 7 respectivement, sont symbolisés sur la figure 3 par des 25 cercles contenant les lettres B et D respectivement. On suppose maintenant que le module de gestion de flux (SM) hébergé par l'équipement C souhaite établir une connexion de flux entre l'équipement A (en tant qu'équipement récepteur) et l'équipement B (en tant qu'équipement récepteur). Ceci implique que le module de gestion de flux (SM): transmette des paquets 1394 (paquets asynchrones) à des registres IEC 61883 physiquement localisés dans l'équipement A et dans la passerelle 1 chargée de la gestion de l'équipement B " distant " (puisque l'équipement B n'est pas accessible directement du fait qu'il est connecté au réseau IP). La norme IEC 61883 est décrite dans le document de référence " IEC 61883 Parts 1-5 Standard for a Consumer-Use Digital Interface "). Sur la figure 3, les registres de 5 l'équipement A sont référencés ai et ceux de la passerelle 1 sont référencés gl, g2, etc.; - échange des messages HAVi avec le module de commande (DCM) 4 de l'équipement A, qui est hébergé par l'équipement C, et avec le module de commande (DCM) 6 de l'équipement B, qui est hébergé par la passerelle 1. Ces 10 messages HAVi sont encapsulés dans des paquets 1394. La passerelle 1 selon l'art antérieur, présentée brièvement ci-dessus en relation avec la figure 3, présente plusieurs inconvénients. Tout d'abord, elle n'est pas compatible avec la notion d'identifiant unique HAVi (HUID), du fait que la relation bijective (i) précitée (à chaque équipement correspond un 15 seul identifiant GUID) n'est pas respectée. En effet, il est impossible de définir un identifiant HUID différent pour chacun des modules DCM, FCM et AM hébergés par la passerelle, puisqu'ils possèdent tous l'identifiant GUID de la passerelle (en tant qu'équipement à utiliser pour les communications IEEE 1394 avec ces modules) dans le sous-champ " GUID " du champ " TargetId " de leur identifiant HUID. D'autres inconvénients découlent du fait que la relation bijective (ii) précitée (à chaque équipement correspond une seule adresse 1394) n'est pas respectée non plus. En effet, le fait que la passerelle gère les équipement UPnP revient à considérer que tous ces équipements possèdent comme adresse 1394 celle de la passerelle. Le traitement des messages HAVi destinés aux modules DCM, FCM et AM 25 hébergés par la passerelle est complexe, du fait que tous ces messages HAVi sont encapsulés dans des paquets 1394 ayant pour adresse de destination l'adresse 1394 de la passerelle. La passerelle doit donc mettre en oeuvre un mécanisme spécifique de traitement des paquets 1394 qu'elle reçoit, afin de: - détecter les éventuels messages HAVi qui y sont encapsulés; - identifier au sein de chaque message HAVi détecté le module destinataire parmi les modules DCM, FCM et AM qu'elle héberge; - fournir chaque message HAVi détecté au module destinataire identifié. En outre, le fait que l'adresse 1394 de la passerelle soit utilisée pour tous les équipements UPnP implique que tous les registres IEC 61883 associés aux équipements UPnP et destinés à recevoir des paquets 1394 (notamment dans le cadre de connexions 5 de flux) soient physiquement localisés dans la passerelle (puisqu'ils ne peuvent pas l'être sur les équipements UPnP). Or, la passerelle en tant qu'équipement 1394 possède un nombre limité de registres IEC 61883: 31 en entrée (iPCR, pour " input Control Register ") et 31 en sortie (oPCR, pour " output Control Register "). Ces registres sont donc à partager entre 10 tous les équipements UPnP situés sur le second réseau. Ceci constitue donc une contrainte sur le nombre maximal d'équipements du second réseau que peut gérer la passerelle. Le fait de devoir implémenter physiquement les registres IEC 61883 sur la passerelle présente également l'inconvénient de consommer inutilement de la bande 15 passante dans certaines situations. Prenons l'exemple de l'établissement d'un flux de données isochrones par un équipement C situé sur le premier réseau entre des équipements B et D situés sur le second s-réseau. Après collecte d'informations sur les types de formats et de transmission, l'équipement C vient écrire dans le registre iPCR de l'équipement B récepteur du flux et le registre oPCR de l'équipement D émetteur du 20 flux. Du fait que les registres iPCR et oPCR sont physiquement implémentés sur la passerelle (ces registres pouvant également être lus par d'autres équipements sur le bus 1394), le flux de données isochrone doit être délivré sur le bus 1394 et ce inutilement. L'invention a notamment pour objectif de pallier ces différents inconvénients de l'état de la technique. Plus précisément, l'un des objectifs de la présente invention est de fournir une passerelle permettant de rendre visible dans le premier réseau tous les équipements du second réseau, tout en permettant à chaque équipement du second réseau de posséder un identifiant unique global. Dans le cas d'un premier réseau HAVi, un objectif de l'invention est ainsi 30 d'étendre la notion d'identifiant unique HAVi (HUID) aux modules DCM, FCM et AM hébergés par la passerelle et relatifs à des équipements du second réseau (non HAVi). L'invention a également pour objectif de fournir une passerelle permettant de simplifier le traitement de messages reçus par la passerelle et qui sont destinés à différents modules fonctionnels élémentaires (DCM, FCM et AM dans la terminologie HAVi) relatifs à des équipements du second réseau. Un autre objectif de l'invention est de fournir une passerelle qui ne nécessite pas une localisation physique dans la passerelle de tous les registres (typiquement les registres IEC 61883) associés aux équipements du second réseau et destinés à recevoir des paquets (typiquement des paquets 1394) (notamment dans le cadre de connexions de flux). Un objectif complémentaire de l'invention est de fournir une passerelle permettant d'optimiser la consommation de bande passante. Ces différents objectifs, ainsi que d'autres qui apparaîtront par la suite, sont atteints selon l'invention à l'aide d'une passerelle permettant l'interconnexion de: - un premier réseau d'un premier type et permettant de réaliser des communications entre une pluralité d'équipements conformes à une première norme d'interopérabilité entre équipements, et - un second réseau d'un second type, distinct du premier type, et permettant de réaliser des communications entre une pluralité d'équipements. Selon l'invention, la passerelle est conforme à la première norme 20 d'interopérabilité entre équipements et comprend: - des moyens d'affectation d'un identifiant unique global, vu du côté du premier réseau, à chaque équipement du second réseau; - des moyens de gestion d'un réseau virtuel possédant le même type que le premier réseau et correspondant à une virtualisation du second réseau, chaque 25 équipement du second réseau étant représenté dans le réseau virtuel par un équipement virtuel distinct possédant une adresse virtuelle distincte dans le réseau virtuel; - des moyens formant un pont entre le premier réseau et le réseau virtuel, et comprenant des moyens formant une première porte reliée au premier réseau, et 30 des moyens émulant une seconde porte reliée au réseau virtuel; - des moyens permettant aux moyens émulant la seconde porte de communiquer avec les équipements du second réseau, lesdits moyens permettant de communiquer comprenant eux- mêmes des moyens de communication sur le second réseau du second type. Le principe général de l'invention consiste donc en une combinaison de moyens permettant d'assurer que les deux relations bijectives (i) et (ii) précitées soient vérifiées pour les équipements du second réseau quand ils sont vus par le premier réseau. La passerelle selon l'invention permet au premier réseau de voir chaque équipement du second réseau par l'intermédiaire d'un équipement virtuel qui lui est 10 associé et qui possède un identifiant unique global (celui affecté à cet équipement du second réseau) et une adresse unique (sur un réseau virtuel, géré dans la passerelle, qui est une image du second réseau, mais qui possède la même structure que le premier réseau). Dans un mode de réalisation particulier de l'invention, la première norme 15 d'interopérabilité entre équipements est la norme HAVi et le premier réseau est un bus selon la norme IEEE 1394. Préférentiellement, le pont formé entre le premier réseau et le réseau virtuel est conforme à la norme IEEE 1394.1 relative à l'interconnexion de réseaux par des ponts. De cette façon, on s'appuie avantageusement sur les spécifications de la norme 20 1394.1 et le pont ne fait donc pas l'objet d'un développement spécifique. La norme 1394.1 est décrite dans le document de référence " P1394.1 Draft Standard for High Perfomance Serial Bus Bridges (Draft 1.03, August 26, 2002) ". De façon avantageuse, les moyens de gestion d'un réseau virtuel comprennent des moyens de gestion de registres virtuels associés à des équipements virtuels 25 représentant des équipements du second réseau conformes à une norme relative à la gestion de registres. Ainsi, les registres associés aux équipements du second réseau et destinés à recevoir des paquets sont des registres virtuels gérés par la passerelle et non pas des registres physiquement présents sur la passerelle. Ceci permet de se libérer de toute 30 contrainte sur le nombre maximal d'équipements du second réseau que peut gérer la passerelle. En outre, ceci permet d'optimiser la consommation de bande passante (voir discussion ci-dessus). Avantageusement, la norme relative à la gestion de registres est la norme IEC61883. Dans un mode de réalisation particulier de l'invention, le second réseau est un réseau IP basé sur le protocole internet. Le second réseau permet de réaliser des communications entre une pluralité d'équipements conformes à une seconde norme d'interopérabilité entre équipements,par exemple la norme UPnP. Selon une caractéristique avantageuse, les moyens permettant aux moyens 10 émulant la seconde porte de communiquer avec les équipements du second réseau comprennent en outre: - des moyens en charge de traitements adaptatifs d'interfaçage entre les première et seconde normes d'interopérabilité entre équipements; - des moyens requis dans tout équipement conforme à la seconde norme 15 d'interopérabilité entre équipements. L'invention concerne également un procédé d'interconnexion, via une passerelle, entre: un premier réseau d'un premier type et permettant de réaliser des communications entre une pluralité d'équipements conformes à une première norme d'interopérabilité entre équipements, et un second réseau d'un second type, distinct du 20 premier type, et permettant de réaliser des communications entre une pluralité d'équipements. Selon l'invention, la passerelle est conforme à la première norme d'interopérabilité entre équipements, et effectue les étapes suivantes: affectation d'un identifiant unique global, vu du côté du premier réseau, à chaque équipement du second réseau; - gestion d'un réseau virtuel possédant le même type que le premier réseau et correspondant à une virtualisation du second réseau, chaque équipement du second réseau étant représenté dans le réseau virtuel par un équipement virtuel distinct possédant une adresse virtuelle distincte dans le réseau virtuel; formation d'un pont entre le premier réseau et le réseau virtuel, ledit pont étant formé par réalisation d'une première porte reliée au premier réseau, et émulation d'une seconde porte reliée au réseau virtuel; - mise en communication de la seconde porte émulée avec les équipements du second réseau. L'invention concerne aussi un programme d'ordinateur comprenant des séquences d'instructions adaptées à la mise en oeuvre d'un procédé tel que précité, lorsque ledit programme est exécuté sur un ordinateur. L'invention concerne encore un produit programme d'ordinateur, adapté à l'interconnexion, via une passerelle telle que précitée. Le produit programme d'ordinateur comprend des instructions de code de programme enregistré sur un support utilisable dans un ordinateur, comprenant: - des moyens de programmation lisibles par ordinateur pour effectuer une étape d'affectation d'un identifiant unique global, vu du côté du premier réseau, à chaque équipement du second réseau; - des moyens de programmation lisibles par ordinateur pour effectuer une étape de gestion d'un réseau virtuel possédant le même type que le premier réseau et 15 correspondant à une virtualisation du second réseau, chaque équipement du second réseau étant représenté dans le réseau virtuel par un équipement virtuel distinct possédant une adresse virtuelle distincte dans le réseau virtuel; - des moyens de programmation lisibles par ordinateur pour effectuer une étape de formation d'un pont entre le premier réseau et le réseau virtuel, ledit pont 20 étant formé par réalisation d'une première porte reliée au premier réseau, et émulation d'une seconde porte reliée au réseau virtuel; - des moyens de programmation lisibles par ordinateur pour effectuer une étape de mise en communication de la seconde porte émulée avec les équipements du second réseau. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante d'un mode de réalisation préférentiel de l'invention, donné à titre d'exemple indicatif et non limitatif, et des dessins annexés, dans lesquels: - la figure 1, déjà décrite précédemment dans le document, présente un exemple d'architecture matérielle d'un équipement HAVi; - la figure 2, également décrite précédemment, illustre un exemple d'architecture logicielle d'un équipement HAVi; - la figure 3, également décrite précédemment, représente une passerelle reliant un réseau HAVi et un réseau UPnP selon l'art antérieur; * - la figure 4 représente une passerelle reliant un réseau HAVi et un réseau UPnP selon l'invention; - la figure 5 représente un mode de réalisation particulier de l'architecture logicielle de la passerelle selon l'invention, apparaissant sur la figure 4; - la figure 6 représente un exemple de table de correspondance entre des composants HAVi et UPnP au niveau de la passerelle selon l'invention; - la figure 7 représente un exemple d'allocation d'identifiants GUID et d'adresses de type 1394 pour des équipements émulés coté HAVi de la passerelle selon l'invention; - la figure 8 présente un organigramme d'un exemple de traitement logiciel pour la gestion des changements éventuels de topologie; - la figure 9 présente un organigramme d'un exemple de traitement logiciel pour la gestion des messages inter-ponts 1394.1. L'invention concerne donc une passerelle permettant l'interconnexion de deux réseaux permettant chacun de réaliser des communications entre une pluralité d'équipements. Dans la suite de la description, on considère le cas particulier o le premier 20 réseau 2 est un bus selon la norme IEEE 1394, auquel sont connectés des équipements conformes à la norme HAVi, et le second réseau 3 est un réseau IP (par exemple de type Ethernet) auquel sont connectés des équipements conformes à la norme UPnP. Il est clair cependant que d'autres combinaisons de normes peuvent être envisagées sanssortir du cadre de la présente invention. Les premier et second réseaux 2, 3 sont parfois aussi appelés " réseau HAVi " et " réseau UPnP " dans la suite de la description. Dans l'exemple illustré sur la figure 4, on suppose que les premier et second réseaux (référencés 2 et 3), ainsi que les équipements qui y sont connectés (référencés A, B, C et D), sont identiques à ceux apparaissant sur la figure 3. Pour cette raison, cette 30 figure 4 n'est pas décrite ici en détail. Par ailleurs, les mêmes éléments conservent les mêmes références sur les figures 3 et 4. En revanche, la passerelle selon l'invention est référencée 50 sur la figure 4, tandis que la passerelle de l'art antérieur est référencée 1 sur la figure 3. Dans un mode de réalisation particulier, illustré sur la figure 5 l'architecture logicielle de la passerelle 50 selon l'invention comprend les modules logiciels suivants: 5 - une première porte de pont 1394.1 (" 1394.1 Bridge Portal "), côté réseau HAVi, référencée 51; - un gestionnaire HAVi (" HAVi Handler "), référencé 52; - un gestionnaire UPnP (" UPnP Handler "), référencé 53; - un gestionnaire de protocole bas niveau (" Low-level Protocol Handler ") référencé 54; - un adaptateur de couches logicielles intermédiaires (" Middleware Adaptor "), référencé 55; - un générateur d'identifiants GUID (" GUID Generator "), référencé 56; un gestionnaire d'équipements 1394 virtuels (" 1394 Virtual Devices "), référencé 57; - un émulateur d'une seconde porte de pont 1394.1, côté réseau UPnP, (" GW Adaptor ") référencé 58. On décrit maintenant plus précisément chacun de ces modules logiciels. Le module 51 formant la première porte de pont 1394.1, côté réseau HAVi, 20 possède les fonctionnalités décrites dans la norme 1394.1 (voir document de référence précité) relative aux ponts entre bus IEEE 1394. Ce module 51 est également en charge des fonctionnalités 1394 des niveaux PHY, LINK et TRAN. Le module 52 formant gestionnaire HAVi 52 inclut la pile logicielle HAVi. Cette dernière comprend au minimum les modules logiciels requis dans le cas d'un 25 équipement HAVi de type IAV, ainsi que certains des modules logiciels optionnels comme le gestionnaire d'établissement de flux isochrone (Stream Manager (SM)) et le gestionnaire de DCMs (DCM Manager (DM)). Ce module 52 est également en charge de la mise en oeuvre des composants logiciels (Software Elements (SE)) HAVi DCMs/FCMs représentant les équipements 30 localisés sur le second réseau UPnP. On parle alors de proxy DCMs ou de proxy FCMs: - quand un équipement est ajouté/supprimé au niveau du second réseau, le gestionnaire UPnP 53 le détecte et fournit une information au gestionnaire HAVi 52, par l'intermédiaire de l'adaptateur de couches logicielles intermédiaires 55. Le gestionnaire HAVi 52 est en charge d'instancier ou supprimer les composants S proxy DCMs ou proxy FCMs correspondants; - quand un message HAVi reçu du réseau HAVi est destiné à un équipement du réseau UPnP, il appartient au proxy DCM/FCM en question de l'analyser et le cas échéant de l'émettre à destination dudit équipement sur le second réseau, en utilisant notamment les services de l'adaptateur de couches logicielles 10 intermédiaires 55 et du gestionnaire UPnP 53; - quand un message est reçu par le gestionnaire UPnP 53, celui-ci est communiqué à l'adaptateur de couches logicielles intermédiaires 55, qui à la charge de solliciter ou non le gestionnaire HAVi 52 pour générer d'éventuelles actions auprès du proxy DCM/FCM correspondant ou d'autres modules HAVi comme le 15 gestionnaire d'événement (Event Manager (EM)), dans le cas de la propagation d'un événement, ou comme le gestionnaire des composants HAVi (Registry), dans le cas de la mise à jour de données relative au proxy DCM/FCM d'un équipement donné. Le module 53 formant gestionnaire UPnP est en charge au minimum des 20 fonctionnalités requises dans tout équipement UPnP. Le module 54 formant gestionnaire de protocole bas niveau est en charge de la mise en oeuvre des protocoles de communications au niveau du second réseau. Par exemple, dans le cas d'UPnP, il s'agit de l'adaptation des protocoles IP/TCP/UDP en fonction des protocoles bas niveaux de transmission (par exemple Ethernet) et du 25 medium physique (par exemple le câble coaxial ou le câble à paire torsadée non-blindée (Unshielded Twisted Pair (UTP)) utilisés. Le module 55 formant adaptateur de couches logicielles intermédiaires est en charge des traitements concernant les adaptations entre les architectures HAVi d'une part et UPnP d'autre part: découverte/suppression d'équipements (information sur la topologie des sousréseaux); - gestion/correspondance de l'adressage (SEID pour HAVi, IP/URL pour UPnP); - transfert de messages: adaptation (mapping) des commandes: " HAVi API call UPnP service action call "; - transfert d'évènements: adaptation (mapping) des évènements: " HAVi API call UPnP évent call "); - mise en place de demande d'établissement de flux isochrone: adaptation entre les commandes HAVi (SM API, DCM/FCM API) et les services UPnP (AVTransport, ConnectionManager). Le module 56 formant générateur d'identifiants GUID est en charge de générer 10 des identifiants GUID cohérents au niveau du réseau vu côté HAVi (qui peut également être constitué de plusieurs autres réseaux de type bus 1394 par exemple). On rappelle qu'un identifiant GUID est composé de deux champs: un premier champ de 24 bits identifiant le vendeur/compagnie de l'équipement (cet identifiant est attribué par un organisme officiel un niveau mondial (" 1394 Registration Authorithy 15 Committee "), un second champ de 40 bits (ou numéro de série) identifiant de façon unique cet équipement pour le vendeur/compagnie considéré. Selon l'invention, on utilise une valeur d'identifiant de vendeur non attribuée (par exemple une valeur réservée ou non encore attribuée qui pourrait ensuite être dédiée pour ce genre d'équipement passerelle) et on attribue une valeur unique pour le 20 numéro de série. Dans la mesure du possible, on attribue un identifiant GUID qui reste invariant dans le temps. La valeur attribuée au numéro de série peut par exemple être composée à partir de l'adresse Ethernet de l'équipement ou encore de son adresse IP, dans la mesure o elle reste fixe dans le temps. L'avantage sur la technique antérieure est que l'identifiant GUID n'étant pas lié à la passerelle, un équipement donné même 25 localisé derrière une autre passerelle (du même type que celle de la présente invention) se voit attribuer un même identifiant GUID. Le module 57 formant gestionnaire d'équipements 1394 virtuels est en charge de créer et gérer toutes les informations relatives à un équipement de type 1394 et ce pour chacun des équipements localisés sur le second réseau (réseau UPnP) et présenté comme 30 étant de type 1394 côté réseau HAVi. Il s'agit des informations habituellement inscrites dans la mémoire ROM de configuration des équipements IEEE 1394 (IEEE 1212 Configuration ROM), ainsi que celles relatives à des fonctionnalités HAVi (type d'équipement, informations utilisées lors du chargement des DCMs, etc.). L'ensemble de ces informations sont appelées en termes HAVi " informations de description de l'équipement HAVi (SDD) ". De plus, ce module 57 est également en charge d'attribuer une adresse de type 1394 pour chacun des équipements physiquement situés sur le second réseau. Cette adresse comprend un identifiant de bus sur 10 bits (" busID ") et un identifiant de noeud sur 6 bits (" nodelD "). La valeur de " busID " est obtenue par l'émulateur d'une seconde porte de pont 1394.1 (module " GW Adaptator ") en utilisant les mécanismes 10 décrits dans la norme 1394.1. On pourra se reporter à la figure 8 et à la description correspondante. En quelques mots, il s'agit pour la passerelle d'interpréter les informations de changements de topologies échangées entre les portes (des ponts 1394.1) et de détecter si la valeur de " busID " est toujours valide ou pas. En cas de non validité, la passerelle (porte côté HAVi) va alors utiliser le mécanisme 1394.1 15 permettant d'obtenir une nouvelle valeur de " busID " valide. La porte dite " alphaportal " demande à la porte dite " prime portal ", en charge de la distribution des valeurs de " busID ", de lui attribuer une valeur de bus valide. Le module 58 (" GW Adaptator ") est en charge d'émuler le comportement de la seconde porte du pont 1394.1, côté réseau UPnP, que ce soit concernant les messages 20 inter-pont 1394.1 (" inter-bridge messages ") ou le transfert des paquets 1394 asynchrones et isochrones. Notamment, lorsque l'émulateur de la seconde porte de pont 1394.1 (module " GW Adaptator ") 58 reçoit un paquet destiné à être routé vers un équipement UPnP virtualisé (donc situé sur le second réseau) et que l'offset correspond à un registre IEC 25 61883, le paquet est alors traité au niveau de la passerelle. Les informations sont mémorisées dans une structure de données (formant registre virtuel) gérée par le gestionnaire d'équipements 1394 virtuels (module " 1394 Virtual Device ") pour cet équipement UPnP. Dans le cas o des actions nécessitent d'être effectuées auprès de l'équipement UPnP, un message est généré en utilisant les services de l'adaptateur de 30 couches logicielles intermédiaires 55 (module " Middleware Adpator ") et du gestionnaire UPnP 53 (module " UPnP Handler "). Enfin, une réponse doit être retournée par l'émulateur de la seconde porte de pont 1394.1 (module " GW Adaptator ") 58 à l'initiateur de la requête. Ainsi, chaque équipement UPnP situé sur le second réseau est virtualisé au niveau 1394, et donc présenté comme étant de type 1394 sur le premier réseau HAVi (adresse 1394 unique à un instant donné, identifiant GUID invariant dans le temps). En adéquation avec l'architecture HAVi, il est possible de montrer du coté du réseau HAVi un équipement capable de gérer des flux de données isochrones et situé sur le second réseau comme étant de type IEC61883 (mise à jour adéquate de la " Configuration ROM "). Aussi, chaque équipement situé sur le second réseau ayant un 10 identifiant GUID unique, les concepts de " HUID " et " TargetID " de l'architecture HAVi restent valides. Un avantage de la virtualisation au niveau 1394 de chaque équipement situé sur le second réseau est que les registres IEC 61883 ne doivent pas être physiquement localisés sur la passerelle, mais sont sensés être sur ledit équipement (ici virtualisé). On 15 s'affranchit ainsi de la limite de 31 registres IEC 61883 possibles en entrée (iPCR) et 31 autres en sortie (oPCR) autorisés pour un équipement 1394 tel que la passerelle. Selon l'invention, ces registres sont virtuels et sont désormais gérés de façon logicielle au niveau de l'émulateur de la seconde porte de pont 1394.1 (module " GW Adaptator ") 58. Le fait ne pas implémenter physiquement les registres IEC 61883 sur la passerelle présente également l'autre avantage de ne pas consommer de bande passante inutilement. Reprenons l'exemple précité de l'établissement d'un flux de données isochrones par un équipement C situé sur le premier réseau entre deux équipements B et D situés sur le second réseau. Dans le cas de l'invention, les équipements B et D étant 25 virtualisés au sens 1394, les registres IEC 61883 concernés (à savoir le registre iPCR de l'équipement B récepteur du flux et le registre oPCR de l'équipement D émetteur du flux) sont situés au niveau de ce bus virtuel et donc aucune perturbation n'est attendu au niveau du premier réseau. L'établissement des flux de données isochrones (initié par un module logiciel 30 HAVi specific (SM)) est d'autre part conforme au standard P1394.1 (" ControllerTalker-Listener mechanism "). On notera que la passerelle de l'invention présente quelques particularités par rapport à un pont 1394: - en ce qui concerne les fonctions de première porte (portai), qui sont exécutées au niveau du module référencé 51: la table de routage doit être telle que seule une 5 entrée (celle correspondant au " buslD " attribué au second réseau) au plus existe; cette passerelle doit être vue comme un pont 1394 (même interface) feuille et non intermédiaire; - en ce qui concerne les fonctions de seconde porte (co-portal) et de la ou des portes (portals) logiquement situées sur le second réseau, qui sont exécutées au 10 niveau du modules référencé 58 (" GW Adaptator "): tous les messages interponts doivent être analysés et le cas échéant des réponses générées (également pour le compte de porte(s) en charge du bus (second réseau) ici virtualisé). La figure 6 décrit un exemple de table de correspondance entre les composants HAVi d'une part et les composants UPnP d'autre part. Dans cet exemple, on suppose que du côté du réseau HAVi, suite à la détection d'un nouvel équipement 1394 sur le bus 1394, des composants logiciels HAVi (DCM/FCMs) sont instanciés: - à un composant logiciel DCM " DCM1 ", on fait correspondre un équipement UPnP " D 1 " (description XML, type " device "); - à chacun de ses composants logiciels FCM " FCM1.1, FCM1.2 ", on fait correspondre les services UPnP " S1.1, S1.2 " (description XML, type " service "). De même, dans cet exemple, on suppose que, suite à la détection d'un nouvel équipement UPnP sur le second réseau: - à cet équipement UPnP " D2 ", on fait correspondre un composant logiciel DCM " DCM2 " (proxy DCM); à chacun des services associé à cet équipement UPnP " S2.1 ", on fait correspondre un composant logiciel FCM " " FCM2.1 " (proxy FCM). On rappelle que la norme HAVi spécifie différents types de composants logiciels 30 FCMs (Tuner, VCR, clock, Camera, ...). Le Forum UPnP a aussi spécifié différents équipements et services associés (Internet Gateway Device (IGD), Printer, Media Server, Media Renderer). Selon les types d'équipements définis dans chacun de ces standards, des correspondances peuvent être pré-établies. Une mise à jour des correspondances entre équipements est possible afin d'assurer les différentes évolutions des équipements: nouveaux services pour des équipements, nouveaux équipements, ... La figure 7 décrit un exemple d'allocation d'identifiants GUID et d'adresses virtuelles 1394 à des équipements UPnP émulés du côté du réseau HAVi. Lorsqu'un équipement UPnP est détecté sur le second réseau, l'adaptateur de couches logicielles intermédiaires (module " Middleware Adaptor ") 55 est alerté via le (module " UPnP Handler ") 53. Si cet équipement UPnP est inconnu du module 10 " Middleware Adaptor " 55, celui-ci demande au générateur d'identifiants GUID (module " GUID Generator ") 56 de lui fournir un identifiant GUID (par exemple " GUID1 ") pour ce nouvel équipement UPnP. Le module " Middleware Adaptor " 55 rassemble les informations concernant cet équipement UPnP et demande alors au gestionnaire d'équipements 1394 virtuels (module " 1394 Virtual Device ") 57 de 15 fournir une adresse virtuelle 1394 (par exemple " busID1; nodelD1 ") et de construire la description 1394-HAVi (SDD) associée. Finalement, en fonction du type de l'équipement UPnP, le module " Middleware Adaptor " 55 demande au gestionnaire HAVi (module " HAVi Handler ") 52 d'instancier les DCM/FCMs adéquats (par exemple " HAVi DCM proxy SE DCM1 ") (voir la norme HAVi 1.1 pour connaître les 20 différents DCMs/FCMs définis à ce jour). La figure 8 décrit les opérations effectuées au niveau de l'émulateur d'une seconde porte de pont 1394.1 (module " GW Adaptator ") 58 lorsqu'un changement de topologie a été détecté au niveau du premier réseau et est tel que la valeur utilisée du " buslD " du bus virtuel n'est plus valide (valeur conflictuelle par exemple suite à la 25 réunion de plusieurs bus 1394), ou encore lors de la première affectation de la valeur de " buslD " du bus virtuel. Lorsque l'un des deux cas précités se produit (réponse positive à la question de l'étape référencée 81), on passe à l'étape référencée 82. Au cours de celle-ci, le module " GW Adaptator " 58 utilise le mécanisme décrit dans P1394.1. Ce mécanisme consiste 30 à demander une nouvelle valeur de " buslD " auprès d'un noeud particulier (prime portal) en charge précisément de l'attribution des valeurs de " busID ". Après réception, la nouvelle valeur de " busID " est mémorisée (étape référencée 83). Il est à noter que tant que la valeur de " busID " reste invalide, les communications asynchrones entre le premier réseau et le second réseau sont 5 interrompues. Celles-ci peuvent reprendre après la nouvelle attribution de la valeur du " busID ", moyennant que les émetteurs en aient pris connaissance (selon les mécanismes décrits dans la norme 1394. 1). La figure 9 décrit les opérations effectuées au niveau de l'émulateur d'une seconde porte de pont 1394.1 (module " GW Adaptator ") 58, lorsqu'un message inter10 pont 1394.1 est reçu et est destiné soit à la seconde porte (co-portal) implementée au niveau de la passerelle, soit à une porte (portal) virtuelle sensée être située sur le second réseau (suite à la virtualisation effectuée du point de vue du premier réseau). Lorsque l'un des deux cas précités se produit (réponse positive à la question de l'étape référencée 91), on passe à l'étape référencée 82, au cours de laquelle on 15 détermine si le message reçu est une requête ou une réponse. S'il s'agit d'une requête, une réponse est générée au nom de la porte initialement destinataire (qui devient dans ce cas source de la réponse), selon les informations disponibles au niveau des équipements virtualisés au sens 1394 du second réseau (étape référencée 93). S'il s'agit d'une réponse à une précédente requête émise par la seconde porte (co-portal) (cas lors de la demande d'une valeur de " busID " par exemple, voir cidessus), cette réponse est alors prise en compte (étape référencée 94). REVENDICATIONS 1. Passerelle (50) permettant l'interconnexion de: - un premier réseau (2) d'un premier type et permettant de réaliser des communications entre une pluralité d'équipements (A, C) conformes à une première norme d'interopérabilité entre équipements, et - un second réseau (3) d'un second type, distinct du premier type, et permettant de réaliser des communications entre une pluralité d'équipements (B, D), caractérisée en ce qu'elle est conforme à la première norme d'interopérabilité entre équipements et comprend: - des moyens (56) d'affectation d'un identifiant unique global, vu du côté du premier réseau, à chaque équipement du second réseau; - des moyens (57) de gestion d'un réseau virtuel possédant le même type que le premier réseau et correspondant à une virtualisation du second réseau, chaque équipement du second réseau étant représenté dans le réseau virtuel par un 15 équipement virtuel distinct possédant une adresse virtuelle distincte dans le réseau virtuel; - des moyens formant un pont entre le premier réseau et le réseau virtuel, et comprenant des moyens (51) formant une première porte reliée au premier réseau, et des moyens (58) émulant une seconde porte reliée au réseau virtuel; 20 - des moyens permettant aux moyens émulant la seconde porte de communiquer avec les équipements du second réseau, lesdits moyens permettant de communiquer comprenant eux-mêmes des moyens (54) de communication sur le second réseau du second type. 2. Passerelle selon la revendication 1, caractérisée en ce que la première norme 25 d'interopérabilité entre équipements est la norme HAVi. 3. Passerelle selon l'une quelconque des revendications 1 et 2, caractérisée en ce que le premier réseau (2) est un bus selon la norme IEEE 1394. 4. Passerelle selon l'une quelconque des revendications 1 à 3, caractérisée en ce que le pont formé entre le premier réseau et le réseau virtuel est conforme à la norme IEEE 30 1394.1 relative à l'interconnexion de réseaux par des ponts. 5. Passerelle selon l'une quelconque des revendications 1 à 4, caractérisée en ce que les moyens (57) de gestion d'un réseau virtuel comprennent des moyens de gestion de registres virtuels associés à des équipements virtuels représentant des équipements du second réseau conformes à une norme relative à la gestion de registres. 6. Passerelle selon la revendication 5, caractérisée en ce que la norme relative à la gestion de registres est la norme IEC-61883. 7. Passerelle selon l'une quelconque des revendications 1 à 6, caractérisée en ce que le second réseau (3) est un réseau IP basé sur le protocole internet. 8. Passerelle selon l'une quelconque des revendications 1 à 7, caractérisée en ce que 10 le second réseau permet de réaliser des communications entre une pluralité d'équipements conformes à une seconde norme d'interopérabilité entre équipements. 9. Passerelle selon la revendication 8, caractérisée en ce que la seconde norme d'interopérabilité entre équipements est la norme UPnP. 10. Passerelle selon l'une quelconque des revendications 8 et 9, caractérisée en ce que 15 les moyens permettant aux moyens émulant la seconde porte de communiquer avec les équipements du second réseau comprennent en outre: - des moyens (55) en charge de traitements adaptatifs d'interfaçage entre les première et seconde normes d'interopérabilité entre équipements; - des moyens (53) requis dans tout équipement conforme à la seconde norme 20 d'interopérabilité entre équipements. 11. Procédé d'interconnexion, via une passerelle, entre: - un premier réseau d'un premier type et permettant de réaliser des communications entre une pluralité d'équipements conformes à une première norme d'interopérabilité entre équipements, et 25 - un second réseau d'un second type, distinct du premier type, et permettant de réaliser des communications entre une pluralité d'équipements, caractérisé en ce que la passerelle est conforme à la première norme d'interopérabilité entre équipements, et en ce que la passerelle effectue les étapes suivantes affectation d'un identifiant unique global, vu du côté du premier réseau, à chaque équipement du second réseau; - gestion d'un réseau virtuel possédant le même type que le premier réseau et correspondant à une virtualisation du second réseau, chaque équipement du second réseau étant représenté dans le réseau virtuel par un équipement virtuel distinct possédant une adresse virtuelle distincte dans le réseau virtuel; formation d'un pont entre le premier réseau et le réseau virtuel, ledit pont étant formé par réalisation d'une première porte reliée au premier réseau, et émulation d'une seconde porte reliée au réseau virtuel; - mise en communication de la seconde porte émulée avec les équipements du second réseau. 12. Procédé selon la revendication 11, caractérisé en ce que la première norme d'interopérabilité entre équipements est la norme HAVi. 13. Procédé selon l'une quelconque des revendications 11 et 12, caractérisé en ce que le premier réseau est un bus selon la norme IEEE 1394. 14. Procédé selon l'une quelconque des revendications 11 à 13, caractérisé en ce que le pont formé entre le premier réseau et le réseau virtuel est conforme à la norme IEEE 1394.1 relative à l'interconnexion de réseaux par des ponts. 15. Procédé selon l'une quelconque des revendications 11 à 14, caractérisé en ce que l'étape de gestion d'un réseau virtuel comprend une étape de gestion de registres virtuels associés à des équipements virtuels représentant des équipements du second réseau conformes à une norme relative à la gestion de registres. 16. Procédé selon la revendication 15, caractérisé en ce que la norme relative à la gestion de registres est la norme IEC-61883. 17. Procédé selon l'une quelconque des revendications 1 1 à 16, caractérisé en ce que le second réseau est un réseau IP basé sur le protocole intemet. 18. Procédé selon l'une quelconque des revendications 11 à 17, caractérisé en ce que le second réseau permet de réaliser des communications entre une pluralité d'équipements conformes à une seconde norme d'interopérabilité entre équipements. 19. Procédé selon la revendication 18, caractérisé en ce que la seconde norme d'interopérabilité entre équipements est la norme UPnP. 20. Procédé selon l'une quelconque des revendications 18 et 19, caractérisé en ce que l'étape de mise en communication de la seconde porte émulée avec les équipements du second réseau comprend: - une étape permettant d'effectuer des traitements adaptatifs d'interfaçage entre les première et seconde normes d'interopérabilité entre équipements; - une étape de communication selon la seconde norme d'interopérabilité entre équipements. 21. Programme d'ordinateur, caractérisé en ce qu'il comprend des séquences d'instructions adaptées à la mise en oeuvre d'un procédé selon l'une quelconque des 10 revendications 11 à 20, lorsque ledit programme est exécuté sur un ordinateur. 22. Produit programme d'ordinateur, adapté à l'interconnexion, via une passerelle selon l'une quelconque des revendications 1 à 10, entre: - un premier réseau d'un premier type et permettant de réaliser des communications entre une pluralité d'équipements conformes à une première 15 norme d'interopérabilité entre équipements, et - un second réseau d'un second type, distinct du premier type, et permettant de réaliser des communications entre une pluralité d'équipements, la passerelle étant conforme à la première norme d'interopérabilité entre équipements, ledit produit programme d'ordinateur comprenant des instructions de code de 20 programme enregistré sur un support utilisable dans un ordinateur, comprenant: - des moyens de programmation lisibles par ordinateur pour effectuer une étape d'affectation d'un identifiant unique global, vu du côté du premier réseau, à chaque équipement du second réseau; - des moyens de programmation lisibles par ordinateur pour effectuer une étape de gestion d'un réseau virtuel possédant le même type que le premier réseau et correspondant à une virtualisation du second réseau, chaque équipement du second réseau étant représenté dans le réseau virtuel par un équipement virtuel distinct possédant une adresse virtuelle distincte dans le réseau virtuel; - des moyens de programmation lisibles par ordinateur pour effectuer une étape de formation d'un pont entre le premier réseau et le réseau virtuel, ledit pont étant formé par réalisation d'une première porte reliée au premier réseau, et émulation d'une seconde porte reliée au réseau virtuel; - des moyens de programmation lisibles par ordinateur pour effectuer une étape de mise en communication de la seconde porte émulée avec les équipements du second réseau.