[go: up one dir, main page]

FR2835372A1 - Systeme et procede de gestion de l'installation d'un module de commande d'un equipement, au sein d'un reseau audiovisuel domestique - Google Patents

Systeme et procede de gestion de l'installation d'un module de commande d'un equipement, au sein d'un reseau audiovisuel domestique Download PDF

Info

Publication number
FR2835372A1
FR2835372A1 FR0201175A FR0201175A FR2835372A1 FR 2835372 A1 FR2835372 A1 FR 2835372A1 FR 0201175 A FR0201175 A FR 0201175A FR 0201175 A FR0201175 A FR 0201175A FR 2835372 A1 FR2835372 A1 FR 2835372A1
Authority
FR
France
Prior art keywords
equipment
host
gateway
local
bus
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.)
Granted
Application number
FR0201175A
Other languages
English (en)
Other versions
FR2835372B1 (fr
Inventor
Jean Paul Accarie
Kretz Thomas Rohmer
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Research Center France SAS
Canon Europa NV
Original Assignee
Canon Research Center France SAS
Canon Europa NV
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Canon Research Center France SAS, Canon Europa NV filed Critical Canon Research Center France SAS
Priority to FR0201175A priority Critical patent/FR2835372B1/fr
Publication of FR2835372A1 publication Critical patent/FR2835372A1/fr
Application granted granted Critical
Publication of FR2835372B1 publication Critical patent/FR2835372B1/fr
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/40052High-speed IEEE 1394 serial bus
    • H04L12/40091Bus bridging
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/61Installation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803Home automation networks
    • H04L12/2805Home Audio Video Interoperability [HAVI] networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803Home automation networks
    • H04L12/2816Controlling appliance services of a home automation network by calling their functionalities
    • H04L12/282Controlling appliance services of a home automation network by calling their functionalities based on user interaction within the home
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/40052High-speed IEEE 1394 serial bus
    • H04L12/40117Interconnection of audio or video/imaging devices
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4604LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L12/462LAN interconnection over a bridge based backbone
    • H04L12/4625Single bridge functionality, e.g. connection of two networks over a single bridge
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/18Delegation of network management function, e.g. customer network management [CNM]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803Home automation networks
    • H04L12/283Processing of data at an internetworking point of a home automation network
    • H04L12/2832Interconnection of the control functionalities between home networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803Home automation networks
    • H04L2012/2847Home automation networks characterised by the type of home appliance used
    • H04L2012/2849Audio/video appliances

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Automation & Control Theory (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Small-Scale Networks (AREA)

Abstract

L'invention concerne un système de gestion d'un réseau audiovisuel domestique (préférentiellement conforme à la norme 1394. 1) permettant l'interconnexion d'une pluralité d'équipements (préférentiellement conformes à la norme HAVi). Chaque équipement est commandé par un module de commande. Au moins un équipement appelé passerelle est connecté à chaque bus. Le système comprend : * des moyens de recherche, via les passerelles, d'équipements effectivement capables d'héberger un module de commande d'un équipement nouvellement connecté à un bus local, ladite recherche portant sur l'ensemble des équipements potentiellement capables d'héberger ledit module, connectés aux autres bus du réseau, dits bus distants, et ayant connaissance d'au moins une des passerelles desdits bus distants;* des moyens, activés si le résultat de la recherche n'est pas nul, de sélection d'un équipement hôte, parmi celui ou ceux résultant de la recherche, en fonction d'au moins un critère fonctionnel prédéterminé;* des moyens d'installation, dans ledit équipement hôte, dudit module de commande.

Description

<Desc/Clms Page number 1>
Système et procédé de gestion de l'installation d'un module de commande d'un équipement, au sein d'un réseau audiovisuel domestique.
Le domaine de l'invention est celui des réseaux audiovisuels domestiques permettant l'interconnexion d'une pluralité d'équipements. En d'autres termes, ces réseaux permettent d'interconnecter 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 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.
On suppose que le réseau audiovisuel domestique est du type comprenant une pluralité de bus numériques, sur chacun desquels peuvent être connectés des équipements (connexion directe pour les équipements numériques, ou via un convertisseur analogique/numérique pour les équipements analogiques).
L'invention s'applique notamment, mais non exclusivement, aux bus numériques de type IEEE 1394. On rappelle que 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 1394a-2000, Standard for High Performance Serial Bus (Supplement) .
On suppose également que les bus sont interconnectés par des ponts (aussi appelés premiers équipements spécifiques dans la suite de la description), conformément à une première norme relative à l'interconnexion d'équipements via des bus numériques eux-mêmes interconnectés par des ponts.
Ainsi, en reprenant l'exemple d'application donné ci-dessus, on connecte différents bus de type IEEE 1394 par l'intermédiaire de ponts, en se conformant à la norme IEEE PI 3 94. 1 Draft Standard for High Performance Serial Bus Bridges (Draft 1. 01 December 6, 2001) .
On suppose aussi que les équipements, y inclus les ponts, sont conformes à une seconde norme d'interopérabilité entre équipements, définissant une couche intermédiaire 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
<Desc/Clms Page number 2>
supérieures d'application. En d'autres termes, cette seconde norme fournit une interface de programmation d'applications (API, pour Application Programming Interface en anglais), sur laquelle peuvent être développés des services, indépendamment des implémentations des réseaux audiovisuels domestiques.
L'invention s'applique notamment, mais non exclusivement, dans le cas où la seconde norme précitée est la norme HAVi, décrite dans le document de référence HAVi (Home Audio Video interoperability) specifications (version 1.1 May 15, 2001) .
On rappelle maintenant, en relation avec les figures 8 et 9, quelques caractéristiques définies dans la norme HAVi.
La figure 8 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 205 ; une mémoire de type ROM 206 ; un système d'entrée/sortie 207 ; un moyen d'affichage (écran) 208 ; un adaptateur réseau 209.
La figure 9 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 8) de l'équipement HAVi, 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 ;
Figure img00020001

un ensemble 211 de couches supérieures d'application, comprenant des modules d'application (AM) 213 et des modules Havlet 214 ;
<Desc/Clms Page number 3>
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 (DCM) 224, permettant chacun de commander un équipement HAVi.
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 cidessus), 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 ; les équipements BAV ( Base AudioVideo ) et LAV ( Legacy AudioVideo ), qui sont des équipements non-intelligents au sens HAVi.
Dans un souci de simplification, on considère uniquement, dans la suite de la description, le cas d'un réseau audiovisuel domestique, comprenant une pluralité de bus numériques de type IEEE 1394, interconnectés par l'intermédiaire de ponts, conformément à la norme IEEE P1394.1 précitée, et interconnectant des équipements (y inclus les ponts) conformes à la norme HAVi précitée. Il est clair cependant que la
<Desc/Clms Page number 4>
présente invention n'est pas limitée à cette combinaison de première et seconde normes particulières.
Il apparaît que la combinaison envisagée des normes IEEE P1394. 1 et HAVi présente plusieurs inconvénients. D'une manière générale, ces inconvénients découlent du fait que la norme HAVi a été définie en relation avec la notion de bus numérique de type IEEE 1394, mais sans tenir compte de la notion (intervenue plus tard) d'interconnexion de bus numériques selon la norme IEEE P1394. 1. En d'autres termes, la norme HAVi suppose que tous les équipements concernés sont connectés à un même bus de type IEEE 1394. Or, la norme IEEE P1394. 1 vise précisément à permettre à des équipements connectés à différents bus, de communiquer entre eux.
Dans le cadre de la norme HAVi 1.1 notamment, pour chaque équipement connecté à l'unique bus considéré, un module fonctionnel élémentaire spécifique, appelé module de commande (ou DCM pour l'anglais"Device Control Module") doit être installé sur ce bus, afin de contrôler l'équipement associé, et de le rendre accessible à tous les autres équipements du bus. Les équipements de type IAV et FAV peuvent héberger leurs propres modules de commande. En revanche, les modules de commande des équipements HAVi de type LAV ou BAV doivent être hébergés par des équipements de type IAV et FAV du bus.
Dans un réseau de bus numériques interconnectés selon la norme IEEE P1394. 1, il est possible qu'un équipement de type BAV ou LAV soit connecté à un bus 1394 donné, et que l'équipement de type IAV ou FAV qui est le plus à même d'héberger (et de gérer) son module de commande associé ne soit pas connecté à ce bus donné, mais à un bus distant. Notamment, il est possible qu'un équipement de type BAV ou LAV soit connecté à un bus 1394 donné, et qu'aucun équipement de type IAV ou FAV de ce bus ne soit capable d'héberger le module de commande associé à l'équipement BAV ou LAV considéré.
Or, un inconvénient majeur de la combinaison précitée des normes IEEE P1394. 1 et HAVi est qu'un équipement intelligent (de type IAV ou FAV), connecté à un bus donné (dit bus local), ne peut pas : - détecter, - communiquer avec,
<Desc/Clms Page number 5>
avoir connaissance des modules fonctionnels élémentaires hébergés par, un autre équipement, connecté à un autre bus (dit bus distant).
Notamment, un module de commande, installé dans un équipement connecté à un bus distant du bus auquel est connecté l'équipement de type BAV ou LAV qui lui est associé, ne peut pas commander à distance cet équipement BAV ou LAV.
De même, un module fonctionnel élémentaire, hébergé dans un équipement connecté au même bus que l'équipement BAV ou LAV considéré, ne peut pas communiquer avec le module de commande de ce dernier, lorsqu'il est situé sur un bus distant.
L'invention a notamment pour objectif de pallier ces inconvénients de l'art antérieur.
Plus précisément, un objectif de l'invention est de fournir une technique permettant d'installer, dans un équipement appelé équipement hôte, connecté à un premier bus appelé bus hôte, un module de commande pilotant un équipement, appelé équipement contrôlé, connecté à un second bus, distant de ce bus hôte.
Un autre objectif de l'invention est de proposer une telle technique, qui permette à un équipement tiers du réseau, appelé équipement émetteur, de communiquer avec l'équipement contrôlé, même si cet équipement émetteur est connecté à un bus distant du bus hôte.
Un autre objectif de l'invention est de fournir une telle technique qui fonctionne que les équipements soient conformes ou non à la première norme (IEEE 1394.1 dans l'application préférentielle), de façon que tous les équipements existants puissent être conservés et utilisés.
Un objectif complémentaire de l'invention est de fournir une telle technique qui permette de bénéficier autant que faire se peut des avantages offerts par la norme IEEE P1394.1.
Ces objectifs, ainsi que d'autres qui apparaîtront par la suite, sont atteints à l'aide d'un système de gestion d'un réseau audiovisuel domestique permettant l'interconnexion d'une pluralité d'équipements, dans lequel :
<Desc/Clms Page number 6>
- ledit réseau comprend au moins deux bus, sur chacun desquels peut être connecté au moins un desdits équipements, et au moins un premier équipement spécifique formant pont, interconnectant lesdits au moins deux bus, - ledit réseau est conforme à une première norme relative à l'interconnexion d'équipements via des bus numériques eux-mêmes interconnectés par des ponts, - les équipements, y inclus les ponts, sont conformes à une seconde norme d'interopérabilité entre équipements, définissant une couche intermédiaire 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, - une pluralité de modules fonctionnels élémentaires (SE) est hébergée par ladite pluralité d'équipements, chacun desdits équipements étant commandé par un module fonctionnel élémentaire spécifique, dit module de commande (DCM),
Figure img00060001

- au moins un deuxième équipement spécifique formant passerelle (HBP) est connecté à chaque bus, - les passerelles comprennent des moyens de communication entre passerelles leur permettant d'avoir une vision dudit système au sens de ladite seconde norme, - ledit système comprend en outre : * des moyens de recherche, via lesdits moyens de communication entre passerelles, d'équipements effectivement capables d'héberger un module de commande d'un équipement, appelé nouvel équipement, nouvellement connecté à un bus, dit bus local, ladite recherche portant sur l'ensemble des équipements potentiellement capables d'héberger ledit module, connectés aux autres bus du réseau, dits bus distants, et ayant connaissance d'au moins une des passerelles desdits bus distants ; * des moyens, activés si le résultat de la recherche n'est pas nul, de sélection d'un équipement, dit équipement hôte, parmi celui ou ceux résultant de la recherche, en fonction d'au moins un critère fonctionnel prédéterminé ; * des moyens d'installation, dans ledit équipement hôte, dudit module de commande.
<Desc/Clms Page number 7>
Le principe général de l'invention repose donc sur l'utilisation d'un jeu de passerelles (au moins une par bus), permettant de gérer la connexion, au niveau de leurs piles HAVi , d'équipements qui ne sont pas connectés à un même bus. Ce principe général consiste notamment, grâce au jeu de passerelles mis en oeuvre, à étendre la recherche des équipements capables d'héberger le module de commande d'un nouvel équipement, à l'ensemble du réseau, et non plus seulement au bus local comme décrit dans la norme HAVi 1.1.
Dans le cas où aucun équipement hôte n'est disponible sur le bus local, l'invention permet donc avantageusement d'aller sélectionner un équipement distant, présentant les ressources nécessaires pour héberger le module de commande d'un nouvel équipement. L'invention permet également de sélectionner, parmi tous les équipements du réseau, celui qui est le plus à même d'héberger le module de commande d'un nouvel équipement, quel que soit le bus auquel il est connecté.
Il convient de ne pas confondre les passerelles (nouveau type d'équipement introduit par la présente invention), avec les ponts (type d'équipement parfaitement défini dans la norme IEEE P1394.1). On rappelle que les ponts permettent une connexion, au niveau de leurs couches basses , d'équipements qui ne sont pas connectés à un même bus, sous réserve que ces équipements soient conformes à la norme IEEE P1394. 1.
Selon une première variante avantageuse de l'invention, lesdits moyens de recherche permettent au préalable d'effectuer ladite recherche parmi l'ensemble des équipements potentiellement capables d'héberger ledit module de commande et connectés audit bus local, de façon que, si au moins un équipement connecté audit bus local, dit équipement local, est identifié au cours de ladite recherche, lesdits moyens de sélection sélectionnent ledit au moins un équipement local comme équipement hôte.
Si aucun équipement hôte potentiel n'est identifié sur le bus local, on procède ensuite à la recherche d'un équipement hôte potentiel sur les bus distants du réseau.
Selon une deuxième variante avantageuse de l'invention, lesdits moyens de recherche permettent également d'effectuer ladite recherche simultanément parmi l'ensemble des équipements potentiellement capables d'héberger ledit module de commande et connectés audit bus local.
<Desc/Clms Page number 8>
On recherche ainsi simultanément un équipement hôte potentiel parmi l'ensemble des équipements distants et locaux du réseau, de façon à pouvoir sélectionner le meilleur équipement hôte possible.
Préférentiellement, au sein des équipements connectés auxdits bus distants, ladite recherche ne porte que sur les équipements conformes à ladite première norme.
Avantageusement, un tel système comprend des premiers moyens d'élection d'un troisième équipement spécifique dudit bus local, dit maître local final, destiné à initier la mise en oeuvre desdits moyens de recherche et à mettre en oeuvre lesdits moyens de sélection.
Dans un mode de réalisation préférentiel, ledit maître local final est une passerelle dudit bus local, dite passerelle locale.
Avantageusement, lesdits moyens de recherche comprennent eux-mêmes : dans ledit maître local final : * des moyens de diffusion d'une requête d'hébergement, vers les équipements du bus local potentiellement capables d'héberger le module de commande du nouvel équipement, et de réception des réponses fournies par lesdits équipements du bus local ; * des moyens, activés si ledit maître local final n'est pas une passerelle dudit bus local, dite passerelle locale, d'émission de la requête d'hébergement vers ladite passerelle locale, et de réception d'une réponse fournie par ladite passerelle locale ; dans ladite passerelle locale : * des moyens, activés si ladite passerelle locale n'est pas ledit maître local final, de réception de ladite requête d'hébergement en provenance du maître local final et de réponse audit maître local final ; * des moyens de diffusion de la requête d'hébergement vers les passerelles desdits bus distants, appelées passerelles distantes, et de réception des réponses fournies par lesdites passerelles distantes ; * des moyens, activés si au moins une des réponses fournies par lesdites passerelles distantes est positive, de présélection d'un équipement d'un desdits
<Desc/Clms Page number 9>
bus distants effectivement capable d'héberger ledit module de commande, en fonction dudit au moins un critère fonctionnel prédéterminé ; dans chaque passerelle distante : * parmi les moyens de communication entre passerelles, des moyens de réception de la requête d'hébergement et des moyens de diffusion de ladite requête vers les équipements du bus distant auquel est connectée ladite passerelle distante, qui sont potentiellement capables d'héberger le module de commande dudit nouvel équipement et ayant connaissance de ladite passerelle distante ; * des moyens de réception des réponses fournies par les équipements du bus distant ; * parmi les moyens de communication entre passerelles de ladite passerelle distante, des moyens de transmission des réponses des équipements du bus distant sous forme d'une liste d'équipements du bus distant effectivement capables d'héberger ledit module de commande en réponse à ladite passerelle locale.
De manière préférentielle, ladite requête d'hébergement comprend un identifiant du nouvel équipement.
Avantageusement, ladite passerelle locale comprend également des premiers moyens, activés si ladite passerelle locale n'est pas ledit maître local final, de mémorisation d'un identifiant dudit équipement présélectionné, en vue de l'éventuelle installation du module de commande du nouvel équipement dans ledit équipement présélectionné, si ledit équipement présélectionné est sélectionné par ledit maître local final comme équipement hôte.
Préférentiellement, ledit système comprend des seconds moyens d'élection d'un quatrième équipement spécifique, dit maître hôte final, du bus auquel est connecté l'équipement hôte, dit bus hôte.
Selon une variante avantageuse de l'invention, ledit maître hôte final est une passerelle dudit bus hôte, dite passerelle hôte.
Avantageusement, lesdits moyens d'installation comprennent eux-mêmes : dans la passerelle locale, parmi les moyens de communication entre passerelles :
<Desc/Clms Page number 10>
* des moyens de transmission d'une requête d'installation dudit module de commande, comprenant l'identifiant dudit équipement présélectionné, vers ladite passerelle hôte ; * des moyens de réception d'une confirmation d'installation, comprenant l'identifiant dudit équipement hôte, en provenance de ladite passerelle hôte ; * des moyens, activés si la passerelle locale n'est pas le maître local final, de transmission d'une confirmation d'installation simplifiée, ne comprenant pas l'identifiant de l'équipement hôte, au maître local final ; dans la passerelle hôte, parmi les moyens de communication entre passerelles : * des moyens de réception de la requête d'installation dudit module de commande en provenance de ladite passerelle locale ; * des moyens de transmission de la confirmation d'installation, vers ladite passerelle locale ; * des moyens, activés si la passerelle hôte n'est pas le maître hôte final, de transmission d'une requête d'installation simplifiée, ne comprenant pas l'identifiant de l'équipement présélectionné, au maître hôte final ; dans ledit maître hôte final, des moyens de commande pilotant des moyens d'instanciation du module de commande dans l'équipement hôte.
Préférentiellement, lesdits moyens d'installation comprennent en outre, dans ledit maître local final, des moyens, activés si le maître local final n'est pas la passerelle locale, d'émission de ladite requête d'installation vers la passerelle locale, et des moyens de réception de ladite confirmation d'installation, fournie par ladite passerelle locale.
De manière avantageuse, lesdits moyens d'installation comprennent également les moyens suivants, qui sont activés si la passerelle hôte n'est pas le maître hôte final : dans la passerelle hôte : * des seconds moyens de mémorisation de l'identifiant dudit équipement présélectionné ; * des moyens de réception d'une notification d'installation, comprenant l'identifiant du nouvel équipement, en provenance du maître hôte final ; * des moyens de vérification que ledit module de commande a bien été installé dans ledit équipement présélectionné ;
<Desc/Clms Page number 11>
dans ledit maître hôte final, des moyens de mise en oeuvre d'un mécanisme, prévu par ladite seconde norme d'interopérabilité, de sélection d'un équipement hôte tenant notamment compte de l'identifiant de l'équipement présélectionné, mémorisé par ladite passerelle hôte.
Préférentiellement, ladite seconde norme d'interopérabilité entre équipements est la norme HAVi (en anglais"Home Audio Video interoperability").
De manière préférentielle, ladite première norme, relative à l'interconnexion d'équipements via des bus numériques eux-mêmes interconnectés par des ponts, est la norme 1394.1.
Selon une caractéristique avantageuse de l'invention, au moins un desdits deuxièmes équipements spécifiques formant passerelles (HBP) est également compris dans un desdits premiers équipements spécifiques formant pont.
Selon une première variante de l'invention, ledit système est tel que : au moins deux passerelles sont connectées à un bus donné, - le système comprend des moyens de sélection de l'une desdites au moins deux passerelles, dite passerelle sélectionnée, de façon que seule la passerelle sélectionnée joue effectivement le rôle de passerelle sur ledit bus donné.
Selon une deuxième variante de l'invention, ledit système est tel que : au moins deux passerelles sont connectées à un bus donné, - le système comprend des moyens permettant de faire coopérer lesdites au moins deux passerelles, de façon que lesdites au moins deux passerelles jouent ensemble le rôle d'une unique passerelle sur ledit bus donné.
Préférentiellement, ledit système comprend en outre des moyens, activés si les moyens d'installation ont permis l'installation du module de commande dans un équipement hôte qui est une passerelle, dite passerelle hôte, de chargement d'un programme du module de commande dudit équipement hôte dans la passerelle locale, de façon à installer ledit module de commande dans ladite passerelle locale.
Avantageusement, les moyens de chargement comprennent eux-mêmes : dans le maître local final, des moyens, activés si le maître local final n'est pas la passerelle locale :
<Desc/Clms Page number 12>
* d'émission d'une requête d'installation du module de commande vers la passerelle locale ; * de réception d'une confirmation d'installation, fournie par lesdits moyens de fourniture d'informations de la passerelle locale ; dans la passerelle locale : * parmi lesdits moyens de communication entre passerelles, des moyens de transmission d'une requête de chargement de programme vers ladite passerelle hôte, et de réception dudit programme du module de commande en provenance de la passerelle hôte ; * des moyens d'instanciation dudit module de commande, à partir dudit programme reçu, dans ladite passerelle locale ; * parmi lesdits moyens de fourniture d'informations, des moyens de transmission de la confirmation d'installation audit maître local final ; dans la passerelle hôte, parmi lesdits moyens de communication entre passerelles, des moyens de transmission du programme du module de commande vers la passerelle locale, en réponse à ladite requête de chargement.
Selon un premier mode de réalisation avantageux de l'invention, ledit équipement hôte, les passerelles, le maître local final et le maître hôte final, sont conformes à la première norme, de façon qu'un module émetteur, hébergé dans un équipement, dit équipement émetteur, éventuellement connecté à un bus distinct dudit bus hôte et/ou dudit bus local, transmette, sans passer par les passerelles, en vue de communiquer avec et/ou de contrôler le nouvel équipement : - des paquets (paquets 1394) contenant des informations de routage permettant auxdits paquets d'atteindre le nouvel équipement, vers ledit nouvel équipement, - des messages conformes à la seconde norme (messages HAVi), vers le module de commande hébergé par l'équipement hôte, ledit équipement émetteur étant également conforme à la première norme.
Selon un deuxième mode de réalisation avantageux de l'invention, les passerelles comprennent des moyens de gestion de proxys de modules fonctionnels élémentaires,
<Desc/Clms Page number 13>
de façon qu'un module émetteur, hébergé dans un équipement, dit équipement émetteur, éventuellement connecté à un bus distinct dudit bus hôte et/ou dudit bus local, transmette en passant par les passerelles, en vue de communiquer avec et/ou de contrôler le nouvel équipement : - des paquets (paquets 1394) contenant des informations de routage permettant auxdits paquets d'atteindre le nouvel équipement, vers ledit nouvel équipement, - des messages conformes à la seconde norme (messages HAVi), vers le module de commande hébergé par l'équipement hôte, en utilisant le proxy du module de commande, ledit équipement émetteur n'étant pas conforme à la première norme.
Selon un troisième mode de réalisation avantageux de l'invention (combinaison des premier et second modes de réalisation précités), les passerelles sont conformes à la première norme et comprennent des moyens de gestion de proxys de modules fonctionnels élémentaires, de façon qu'un module émetteur, hébergé dans un équipement, dit équipement émetteur, éventuellement connecté à un bus distinct dudit bus hôte et/ou dudit bus local, transmette, en vue de communiquer avec et/ou de contrôler le nouvel équipement : - des paquets (paquets 1394) contenant des informations de routage permettant auxdits paquets d'atteindre le nouvel équipement, vers ledit nouvel équipement : * sans passer par les passerelles, si l'équipement émetteur est conforme à la première norme, * en passant par les passerelles, si l'équipement émetteur n'est pas conforme à la première norme, - des messages conformes à la seconde norme (messages HAVi), vers le module de commande hébergé par l'équipement hôte : * sans passer par les passerelles, si l'équipement émetteur et l'équipement hôte sont conformes à la première norme, * en passant par les passerelles et en utilisant le proxy du module de commande, si l'équipement émetteur et/ou l'équipement hôte n'est (ne sont) pas conforme (s) à la première norme.
<Desc/Clms Page number 14>
L'invention concerne également un procédé de gestion de l'installation d'un module de commande, au sein d'un système tel que décrit précédemment, ledit procédé comprenant : * une étape de recherche d'équipements effectivement capables d'héberger un module de commande d'un équipement, appelé nouvel équipement, nouvellement connecté à un bus, dit bus local, ladite étape de recherche portant sur l'ensemble des équipements potentiellement capables d'héberger ledit module, connectés aux autres bus du réseau, dits bus distants, et ayant connaissance d'au moins une des passerelles desdits bus distants ; * une étape, mise en oeuvre si le résultat de la recherche n'est pas nul, de sélection d'un équipement, dit équipement hôte, parmi celui ou ceux résultant de la recherche, en fonction d'au moins un critère fonctionnel prédéterminé ; * une étape d'installation, dans ledit équipement hôte, dudit module de commande.
L'invention concerne aussi un programme d'ordinateur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution des étapes du procédé décrit précédemment, lorsque ledit programme est exécuté sur un ordinateur.
L'invention concerne encore un produit programme d'ordinateur, adapté à la gestion de l'installation d'un module de commande, au sein d'un système tel que décrit précédemment, ledit produit programme d'ordinateur comprenant des instructions de code de programme enregistré sur un support utilisable dans un ordinateur comprenant : des moyens de programmation lisibles par ordinateur pour effectuer l'étape de recherche d'équipements effectivement capables d'héberger un module de commande d'un équipement, appelé nouvel équipement, nouvellement connecté à un bus, dit bus local, ladite étape de recherche portant sur l'ensemble des équipements potentiellement capables d'héberger ledit module, connectés aux autres bus du réseau, dits bus distants, et ayant connaissance d'au moins une des passerelles desdits bus distants ; des moyens de programmation lisibles par ordinateur pour effectuer l'étape, mise en oeuvre si le résultat de la recherche n'est pas nul, de sélection d'un équipement, dit équipement hôte, parmi celui ou ceux résultant de ladite recherche, en fonction d'au moins un critère fonctionnel prédéterminé ;
<Desc/Clms Page number 15>
des moyens de programmation lisibles par ordinateur pour effectuer l'étape d'installation, dans ledit équipement hôte, dudit module de commande.
D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : - la figure 1 présente un synoptique d'un réseau audiovisuel domestique dans lequel est mis en oeuvre le procédé d'installation d'un module de commande d'un équipement selon l'invention ; - la figure 2 illustre un premier mode de réalisation de la sélection d'un équipement hôte destiné à héberger le module de commande de la figure 1 ;
Figure img00150001

- la figure 3 décrit un deuxième mode de réalisation de la sélection d'un équipement hôte destiné à héberger le module de commande de la figure 1 ; - la figure 4 présente un premier mode de réalisation de l'installation d'un module de commande dans un équipement hôte sélectionné selon le mécanisme illustré en figure 3 ; - la figure 5 décrit un second mode de réalisation de l'installation d'un module de commande dans un équipement hôte sélectionné selon le mécanisme illustré en figure 3 ; la figure 6 illustre un exemple de mode de réalisation du mécanisme de chargement du programme d'un module de commande, d'une passerelle hôte vers une passerelle locale, mis en oeuvre par l'invention ; les figures 7a et 7b présentent deux exemples de réalisation d'un mécanisme de contrôle, par un module émetteur, d'un équipement dont le module de commande est hébergé sur un bus distant, lorsque le module émetteur, via l'équipement qui l'héberge, et l'équipement contrôlé sont connectés à un même bus local ; la figure 8, déjà décrite précédemment, présente un exemple d'architecture matérielle d'un équipement HAVi ; la figure 9, également décrite au début de ce document, présente un exemple d'architecture logicielle d'un équipement HAVi.
Le principe général de l'invention repose sur l'installation d'un module de commande sur un bus distant du bus auquel est connecté l'équipement qu'il commande,
<Desc/Clms Page number 16>
Figure img00160001

mettant en oeuvre un jeu de passerelles. Ce mécanisme d'installation s'applique aux équipements de type BAV ou LAV mentionnés précédemment.
On présente, en relation avec la figure 1, un exemple de réseau audiovisuel domestique de l'invention, auquel est connecté un nouvel équipement, pour lequel on souhaite mettre en oeuvre le procédé d'installation d'un module de commande de l'invention.
Le réseau de la figure 1 comprend trois bus, référencés 1 à 3. Un premier pont 4, comprenant deux portes 4a et 4b, permet d'interconnecter les bus 1 et 2. Un deuxième pont 5, comprenant deux portes 5a et 5b, permet d'interconnecter les bus 2 et 3.
L'ensemble des bus 1, 2 et 3 et des ponts 4 et 5 est conforme à une première norme relative à l'interconnexion d'équipements via des bus numériques. Par souci de simplification, on se limitera dans la suite du document au cas où cette première norme est la norme 1394. 1 mentionnée précédemment dans ce document.
Deux équipements référencés A et D, de type IAV ou FAV, sont connectés au bus 1. Un premier équipement de type IAV ou FAV référencé C, et un deuxième équipement de type BAV ou LAV référencé B sont connectés au bus 3.
Au moins un équipement spécifique, appelé passerelle, est en outre connectée à chacun des bus 1 à 3 et, en tant qu'équipement, est donc conforme à la norme HAVi 1. 1.
Les passerelles permettent de gérer la connexion d'équipements, au niveau de leurs piles HAVi , qui ne sont pas connectés à un même bus. Chaque passerelle se comporte comme un proxy de pont HAVi (HBP, pour HAVi Bridge Proxy en anglais). Elle exécute un module fonctionnel élémentaire (SE, pour Software Element selon la terminologie HAVi) spécifique, appelé par exemple HBPM (pour HBP Manager en anglais), ou encore programme propre à la passerelle. Ce dernier est en charge des fonctions et mécanismes de connexion au niveau HAVi ( HAVi bridging en anglais). Ces fonctions et mécanismes (notamment de communications entre passerelles et de traitement d'informations relatives au réseau, aux équipements et aux modules fonctionnels élémentaires) sont décrits en détail par la suite.
Tous les mécanismes de la présente invention qui seront décrits dans la suite sont mis en oeuvre sous forme d'algorithmes, qui sont stockés dans la ROM (référencée 206 sur la figure 8) des équipements HAVi, et notamment des passerelles. Ils sont
<Desc/Clms Page number 17>
chargés dans la RAM (référencée 205 sur la figure 8) lors de la mise sous tension de chaque équipement et l'unité centrale (CPU) (référencée 201 sur la figure 8) correspondante va exécuter les instructions de ces algorithmes.
Par souci de simplification, on se limitera dans toute la suite du document au cas où une seul passerelle est connectée à chaque bus. Sur la figure 1, ces passerelles référencées PI, P2 et P3, sont comprises dans les ponts 4 et 5. Ainsi, sur le bus 1, la passerelle PI correspond à la porte 4a ; sur le bus 2, la passerelle P2 correspond à la porte 4b ; sur le bus 3, la passerelle P3 correspond à la porte 5b du pont 5. L'invention s'applique bien sûr également au cas où les passerelles sont des équipements distincts des portes des ponts, connectés aux bus. Par souci de simplification, on se limitera cependant, dans la suite du document, à décrire le cas où chaque bus comprend une unique passerelle, comprise dans l'un des ponts.
Les équipements référencés A, B, C et D, ainsi que les ponts 4 et 5 (et donc notamment les passerelles PI, P2 et P3), sont conformes à une seconde norme d'interopérabilité entre équipements. Par souci de simplification, on se limitera, dans toute la suite du document, au cas où cette seconde norme est la norme HAVi.
L'invention s'applique bien sûr également à toute autre exemple de"seconde norme."
Dans l'exemple de la figure 1, l'équipement B, qui est de type BAV ou LAV, vient d'être connecté sur le bus 3, et il est donc nécessaire d'installer sur le réseau un module de commande, permettant de commander cet équipement B.
Après installation, ce module de commande, non représenté sur la figure 1, est hébergé (au sens"exécuté") par un équipement hôte, qui peut être connecté à un bus distant du bus 3 auquel est connecté l'équipement référencé B. Notamment, l'équipement hôte peut être connecté au bus 1. L'équipement hôte doit donc avoir connaissance des passerelles (et notamment de la passerelle du bus auquel il est connecté, appelée passerelle hôte), pour pouvoir contrôler l'équipement référencé B.
En effet, l'équipement hôte doit être capable de s'adresser à l'équipement contrôlé B : - en lui envoyant des paquets de type 1394 (contenant des informations de, routage selon la norme 1394, leur permettant d'atteindre l'équipement contrôlé), par l'intermédiaire
<Desc/Clms Page number 18>
des passerelles ( solution basée sur des proxys de modules fonctionnels élémentaires ), ou - en lui envoyant des paquets de type 1394.1 (contenant des informations de routage selon la norme 1394.1, leur permettant d'atteindre l'équipement contrôlé), sans passer par les passerelles ( solution basée sur 1394.1 ), si l'équipement émetteur et l'équipement hôte sont tous les deux conformes à la norme 1394.1.
On notera que, dans un mode de réalisation préférentiel de l'invention, l'équipement hôte est capable de communiquer au travers d'un pont, par exemple en étant compatible avec la norme 1394. 1.
En d'autres termes, on privilégie la solution basée sur 1394.1 . Il est clair cependant que la présente invention couvre chacun des cas où l'une des deux solutions précitées est utilisée seule, ainsi que le cas où elles sont utilisées en combinaison.
Sur l'exemple de la figure 1, il existe cinq équipements qui sont de type IAV ou FAV, qui comprennent un gestionnaire de modules de commande (en anglais"DCM Manager") tel que défini par la norme HAVi, et qui sont potentiellement capables d'héberger le module de commande de l'équipement B, à savoir : sur le bus référencé 3, l'équipement référencé C et la passerelle référencée P3 ; sur le bus référencé 1, les équipements référencés A et D, et la passerelle PI.
On notera que ces équipements peuvent stocker le programme d'un ou plusieurs modules de commande, 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 associé.
La figure 2 illustre un premier mode de réalisation de la sélection de l'un de ces équipements comme équipement hôte, destiné à héberger le module de commande de l'équipement B (encore appelé"nouvel équipement"sur la figure 2), nouvellement connecté au bus 3.
On notera que, par souci de clarté, on utilise sur toutes les figures les mêmes références pour désigner les mêmes éléments.
La figure 2 décrit notamment le rôle des passerelles dans le mécanisme de sélection d'un équipement hôte distant selon l'invention. On notera que les étapes
<Desc/Clms Page number 19>
référencées 21 et 22 font partie du protocole de gestion des modules de commande (en anglais"DCM Management Protocol") décrit dans la norme HAVi 1.1.
Au cours de l'étape référencée 21, le nouvel équipement B est connecté au bus 3,
Figure img00190001

appelé bus local, ce qui provoque un événement, appelé"bus reset"dans la norme HAVi 1. 1. (Le système de l'invention comprend en effet des moyens de détection de la connexion d'un nouvel équipement à un bus. ) Un équipement du bus 3 local (ou plus exactement, le gestionnaire de module de commande, ou"DCM Manager", de cet équipement) est alors désigné comme maître local initial (en anglais"initial leader"), en fonction de son identifiant, appelé GUID (pour l'anglais"Global Unique IDentifier").
On rappelle qu'un tel identifiant GUID peut être vu, de manière simplifiée, comme l'adresse de l'équipement au sens de la norme 1394.
Ce maître local initial, qui n'a pas été représenté sur la figure 2, élit alors un maître local final (en anglais"Final Leader"), référencé 27. Dans l'exemple particulier de la figure 2, le maître 27 est le gestionnaire de module de commande ("DCM Manager") de la passerelle référencée P3 du bus local 3. Les autres équipements de type IAV ou FAV du bus 3 local, à savoir l'équipement référencé C, est appelé disciple 28.
On notera que, par souci de simplification de la figure 2, on a illustré par des flèches les échanges entre les équipements référencés A, D, PI, P3 et C de la figure 1.
Ces échanges correspondent bien sûr à des échanges entre les gestionnaires de modules de commande ("DCM Manager") de ces différents équipements.
Concomitamment à cette élection du maître 27, tous les équipements reçoivent une notification 29, de la part de leur gestionnaire de media de communication 1394 (ou en anglais"Communication Media Manager 1394"), les informant que le nouvel équipement B a été connecté sur le bus 3 local.
Au cours de l'étape référencée 22, le maître local final 27 prend l'initiative de la gestion de l'installation du module de commande de ce nouvel équipement B. Il envoie des requêtes d'hébergement 22a, appelées"DMInquiry", vers tous les disciples 28 du bus local 3. L'identifiant GUID du nouvel équipement pour lequel un module de commande doit être installé est transmis comme paramètre de la requête d'hébergement 22a. Les disciples 28, en l'occurrence l'équipement référencé C, répond (22b) à la requête d'hébergement, en indiquant s'ils sont ou non effectivement capables d'héberger
<Desc/Clms Page number 20>
le module de commande du nouvel équipement B, sous forme d'un message "DMInquiry response".
Le maître local final 27, qui, dans l'exemple de la figure 2, est une passerelle, envoie également (23) la requête d'hébergement (ou"DMInquiry"), sous forme d'un message propriétaire ("PROP. DMInquiry"), vers chacune des passerelles distantes, comme si elles étaient situées sur le bus local 3. Cet envoi met en oeuvre les moyens de communication entre passerelles mentionnés précédemment dans le document. Par souci de simplification de la figure 2, on n'a représenté que l'envoi de la requête, par le maître 27, à la passerelle PI du bus distant 1. Le contenu de la requête d'hébergement émise au cours de cette étape référencée 23, ainsi que le protocole de transmission mis en oeuvre, sont similaires à ceux de l'étape précédente référencée 22.
Au cours d'une étape référencée 24, chaque passerelle distante transmet (24a) la requête d'hébergement ("DMInquiry"), sur le bus auquel elle est connectée, aux gestionnaires de modules de commande des équipements qui la connaissent, et reçoit (24b) leurs réponses. Les équipements n'ayant pas connaissance de la passerelle sont ignorés au cours de cette étape, puisqu'ils ne seraient en effet pas capables de contrôler le nouvel équipement B, qui n'est pas connecté au même bus qu'eux.
Notamment, dans un mode de réalisation préférentiel de l'invention, les passerelles distantes ne transmettent (24a) la requête d'hébergement qu'aux gestionnaires de modules de commande des équipements conformes à la norme 1394.1.
Ainsi, la passerelle PI du bus distant 1 transmet (24a) la requête d'hébergement aux équipements référencés A et D du bus 1, qui ont tous deux connaissance de la passerelle PI (dans un mode de réalisation préférentiel de l'invention, qui sont tous deux de type 1394. 1), et reçoit (24b) leurs réponses.
La passerelle PI, à partir des réponse reçues 24b ("DMInquiry response"), élabore une liste des équipements de son bus 1 qui sont effectivement capables d'héberger le module de commande du nouvel équipement B, et la transmet (25) au maître local final 27 du bus local 3, sous forme d'un message propriétaire ("PROP. DMInquiry responses"). Chaque passerelle distante procède de la même manière, de façon que le maître 27 du bus local 3 obtienne une liste complète de tous les équipements du réseau, qu'ils soient situés sur le bus local 3 ou sur un bus distant, qui
<Desc/Clms Page number 21>
sont effectivement capables d'héberger le module de commande du nouvel équipement B. Par exemple, cette liste complète comprend les équipements référencés A et PI sur le bus 1, et C sur le bus 3.
Au cours d'une étape référencée 26, le maître local final 27 sélectionne, au sein de la liste complète élaborée à partir des réponse des passerelles distantes (PI) et des équipements locaux (C), l'équipement qui est le plus à même de jouer le rôle d'équipement hôte. Par exemple, l'équipement hôte sélectionné est l'équipement référencé A du bus distant 1.
On présente, en relation avec la figure 3, une variante du mécanisme de sélection de l'équipement hôte, mise en ceuvre lorsque le maître local final élu sur le bus local 3 n'est pas une passerelle.
Les étapes référencées 21,22a, 22b et 26 font partie du protocole de gestion de modules de commande (en anglais,"DCM Management Protocol") décrit dans la norme HAVi 1.1.
Comme décrit précédemment en relation avec la figure 1, au cours de l'étape référencée 21, le nouvel équipement B est connecté au bus 3 local, ce qui provoque un "bus reset". Un équipement du bus 3 local est alors désigné comme maître local initial, en fonction de son identifiant GUID
Ce maître local initial élit alors un maître local final (en anglais"Final Leader"), référencé 27. Dans l'exemple particulier de la figure 3, le maître 27 est le gestionnaire de module de commande ("DCM Manager") de l'équipement référencé C du bus local 3.
La passerelle référencée P3 du bus local 3 est appelée disciple 28.
Concomitamment à cette élection du maître 27, tous les équipements du bus local 3 reçoivent une notification 29 les informant de la connexion du nouvel équipement B sur le bus.
Au cours de l'étape référencée 22a, le maître local final 27 prend l'initiative de la gestion de l'installation du module de commande de ce nouvel équipement B. Il envoie des requêtes d'hébergement 22a ("DMInquiry") vers tous les disciples 28 du bus local 3 (en l'espèce, à la passerelle P3), l'identifiant GUID du nouvel équipement B (ou"Guest ID") étant passé comme paramètre de la requête d'hébergement 22a.
<Desc/Clms Page number 22>
La passerelle P3 du bus local 3 envoie alors (23) la requête d'hébergement, sous forme d'un message propriétaire ("PROP. DMInquiry (Guest ID,...)"), vers chacune des passerelles distantes.
Au cours d'une étape référencée 24, chaque passerelle distante (PI) transmet (24a) la requête d'hébergement ("DMInquiry (Guest ID,...)"), sur le bus auquel elle est connectée, aux gestionnaires de modules de commande des équipements qui la connaissent (dans un mode de réalisation préférentiel de l'invention, qui sont 1394.1) (A, D), et reçoit (24b) leurs réponses ("DMInquiry response"). Comme décrit précédemment en relation avec la figure 2, les équipements n'ayant pas connaissance de la passerelle (dans un mode de réalisation préférentiel de l'invention, qui ne sont pas 1394.1) sont ignorés au cours de cette étape, puisqu'ils ne seraient en effet pas capables de contrôler le nouvel équipement B, qui n'est pas connecté au même bus qu'eux.
La passerelle PI, à partir des réponse reçues, élabore une liste des équipements de son bus 1 qui sont effectivement capables d'héberger le module de commande du nouvel équipement B, et la transmet (25) à la passerelle P3 du bus local 3, sous forme d'un message propriétaire ("PROP. DMInquiry responses"). Chaque passerelle distante procède de la même manière, de façon que la passerelle P3 du bus local 3 obtienne une liste de tous les équipements distants du réseau, qui sont effectivement capables d'héberger le module de commande du nouvel équipement B.
Si l'une au moins des listes reçues des passerelles distantes n'est pas vide, la passerelle locale P3 présélectionne, au sein de cette liste, un équipement hôte préférentiel, dont elle mémorise l'identifiant GUID, au cas où elle recevrait ultérieurement une commande d'installation du module de commande dans cet équipement hôte, de la part du maître local final 27.
Les critères de sélection utilisés pour ce faire par la passerelle locale P3 sont similaires aux critères définis dans la norme HAVi 1.1 pour la sélection, par un maître local final, d'un équipement hôte, sur un bus local, au sein d'une liste comprenant le maître local final lui-même et les disciples locaux ayant répondu positivement à une requête d'hébergement. Ces critères sont par exemple liés au type de l'équipement HAVi (IAV ou FAV), et à la capacité de cet équipement à accéder au réseau mondial Internet
<Desc/Clms Page number 23>
(notamment pour télécharger des programmes de module de commande depuis ce réseau).
Au cours d'une étape référencée 22b, la passerelle locale P3 répond au maître local final 27, en lui indiquant qu'elle est (ou non, si les listes reçues des passerelles distantes sont toutes vides) capable d'installer un module de commande pour le nouvel équipement B.
Au cours d'une étape référencée 26, le maître local final 27 sélectionne, parmi toutes les réponses reçues de la passerelle locale P3 et des équipements de type IAV ou FAV du bus local 3 autres que la passerelle P3, l'équipement qui est le plus à même de jouer le rôle d'équipement hôte (par exemple, A). En d'autres termes, le maître local final 27 sélectionne l'équipement hôte au sein d'une liste comprenant l'équipement hôte présélectionné par la passerelle locale P3 et l'ensemble des disciples 28 du bus local 3 qui ont répondu positivement à la requête d'hébergement du maître local final 27. En effet, bien que cela ne soit pas illustré sur la figure 3, le maître local final 27 recevrait également des réponses aux requêtes d'hébergement envoyées aux équipements de type IAV ou FAV du bus local 3 autres que la passerelle P3, si de tels équipements existaient.
Ainsi, le jeu de passerelles (PI, P3) proposé dans le cadre de l'invention, permet, par la mise en oeuvre de moyens de communication entre passerelles, la propagation d'une requête d'hébergement d'un bus local vers l'ensemble des bus distants du réseau.
On peut ainsi étendre la recherche des équipements qui sont capables d'héberger le module de commande d'un équipement nouvellement connecté à l'ensemble du réseau, et donc choisir, parmi tous ces équipements, celui qui est le plus approprié pour jouer le rôle d'équipement hôte, même s'il est connecté à un bus distant.
Après qu'un équipement hôte a été sélectionné, il faut procéder à l'installation du programme du module de commande (ou"DCM Code Unit") dans cet équipement. Les figures 4 et 5 illustrent le mécanisme mis en oeuvre par le maître local final 27 du bus local 3, pour procéder à l'installation d'un module de commande dans l'équipement hôte sélectionné A, connecté au bus distant 1, appelé bus hôte.
<Desc/Clms Page number 24>
Dans le cadre de ce mécanisme, un équipement spécifique du bus hôte 1 est élu comme maître hôte final 31 : cet équipement est responsable de la mise en oeuvre des moyens d'installation du module de commande sur le bus hôte 1.
La figure 4 présente un premier mode de réalisation du mécanisme d'installation, lorsque le maître hôte final 31 du bus hôte 1 n'est pas une passerelle du bus hôte 1. En l'occurrence, dans l'exemple de la figure 4, on considère que le maître hôte final 31 est l'équipement référencé D du bus hôte 1 (ou plus exactement, le gestionnaire de module de commande de cet équipement), les équipements référencés A et PI du bus hôte 1 étant respectivement les disciples 32 et 33 de cet équipement maître 31. On considère également que le maître local final 27 du bus local 3 est l'équipement référencé C, comme illustré par la figure 3.
On notera que les étapes référencées 41 et 50 de la figure 4 font partie du protocole de gestion des modules de commande ("DCM Management Protocol") prévu par la norme HAVi 1.1, et ne sont mises en oeuvre que si la passerelle P3 du bus local 3 est un disciple 28 du maître local final 27.
Au cours de l'étape référencée 41, le maître local final 27, à savoir l'équipement référencé C du bus local 3, envoie une requête d'installation ("DMCommand (INSTALL...)") vers le gestionnaire de module de commande de la passerelle locale P3. Cette requête d'installation est par exemple une commande du type INSTALL~URL~PREF, INSTALLURLBAV,INSTALLCODEBAV ou INSTALL.
Sur réception de cette requête d'installation, la passerelle locale P3 du bus local 3 la transmet (42) à la passerelle PI du bus hôte 1 (c'est-à-dire à la passerelle du bus auquel est connecté l'équipement hôte), sous la forme d'un message propriétaire ("PROP Install (Host GUID)"). Ce message propriétaire comprend en outre les identifiants GUID du nouvel équipement B et de l'équipement hôte A.
En effet, la passerelle locale P3 connaît ce dernier identifiant, puisqu'au cours de la sélection de l'équipement hôte décrite en relation avec la figure 3, la passerelle locale P3 a présélectionné un équipement hôte préférentiel et mémorisé son identifiant GUID. Bien que la requête d'installation 41 émise par le maître local final 27 ne véhicule pas
<Desc/Clms Page number 25>
l'identifiant GUID de l'équipement hôte, la passerelle locale P3 sait que cet équipement correspond à l'équipement A qu'elle a précédemment présélectionné.
Sur réception de la requête d'installation en provenance de la passerelle locale P3, la passerelle hôte PI mémorise (43) l'identifiant GUID de l'équipement hôte A véhiculé par cette requête, de façon que cet équipement hôte A soit considéré, au niveau du bus hôte 1, comme l'équipement hôte préférentiel pour héberger le module de commande du nouvel équipement B.
La passerelle hôte PI du bus hôte 1 est un disciple 33, et ne peut donc pas procéder elle-même à l'installation du module de commande dans l'équipement hôte.
Elle transmet donc la requête d'installation à ses moyens internes de fourniture d'informations, pour que ces derniers la transfèrent (44) sous forme de commande "DMCommand (INSTALL~INV...) au maître hôte final 31.
Cette commande ne comprend pas l'identifiant de l'équipement hôte A dans lequel il faut procéder à l'installation du module de commande. Le maître hôte final 31 procède donc à l'installation du module de commande telle que décrite dans la norme HAVi 1.1, au niveau du bus hôte 1, de manière à déterminer au préalable l'identifiant de l'équipement hôte choisi pour cette installation. Au cours d'une étape référencée 45, il envoie donc des requêtes d'hébergement ("DMInquiry (Guest ID...)") vers tous les gestionnaires de module de commande des équipements potentiellement capables d'héberger le module de commande du bus hôte 1, à savoir vers l'équipement référencé A et vers la passerelle hôte PI du bus hôte 1. Il reçoit leurs réponses ("DMInquiry response"), à partir desquelles il sélectionne (46) l'équipement hôte, en tenant notamment compte des préférences mémorisées par la passerelle hôte PI au cours de l'étape référencée 43 (c'est-à-dire de l'identifiant GUID de l'équipement hôte A préférentiel mémorisé).
Le maître hôte final 31 peut alors procéder à l'installation 47 du module de commande du nouvel équipement B dans l'équipement hôte A sélectionné : il lui envoie une requête d'installation sous la forme d'une commande"DMCommand (INSTALL...)", et l'équipement hôte A lui confirme le succès de l'installation en lui répondant par un message de type"DMCommand (INSTALLED)".
<Desc/Clms Page number 26>
Figure img00260001
On rappelle que l'équipement hôte sélectionné, dans un autre exemple que celui de la figure 4, pourrait être le maître hôte final 31 lui-même, la passerelle hôte PI, ou tout autre équipement du bus hôte 1 qui a connaissance de la passerelle PI, de façon à pouvoir envoyer des messages de type 1394 (ou de type 1394. 1) au nouvel équipement contrôlé B. Dans un mode de réalisation préféré de l'invention, l'équipement hôte sélectionné est de type 1394. 1, de façon à pouvoir envoyer des messages de type 1394. 1 au nouvel équipement contrôlé B.
Dans l'exemple de la figure 4, la passerelle hôte PI a également souscrit au service de notification de l'installation d'un module de commande, et reçoit donc une notification 48 "DcmInstallIndication (Guest ID,...) " de la part du maître hôte final 31, lui confirmant que le module de commande du nouvel équipement B a bien été installé sur le bus hôte 1.
Au cours de cette même étape référencée 48, la passerelle hôte PI peut alors vérifier que le module de commande a été installé sur l'équipement hôte préférentiel dont il avait mémorisé l'identifiant GUID au cours de l'étape référencée 43. Pour ce faire, il envoie un message"DMInquiry (Guest ID,...)"à l'équipement hôte préférentiel A, qui lui répond par un message de confirmation"DMInquiry response".
La passerelle hôte PI émet alors (49) une notification de résultat à la passerelle locale P3 du bus local 3, sous forme d'un message propriétaire"PROP. Installed (Host GUID)", dont un paramètre est l'identifiant GUID de l'équipement hôte A, dans lequel a été installé le module de commande.
La passerelle locale P3 du bus local 3, si elle est un disciple 28 du maître local final 27, transmet alors le message propriétaire à ses moyens de fourniture d'informations, de façon que ces derniers le transmette (50), sous forme d'une commande de type"DMCommand"au maître local final 27 du bus local 3 (en l'espèce, l'équipement référencé C du bus local 3). Cette commande peut être de type INSTALLED ou NOT~INSTALLED, comme défini par la norme HAVi 1. 1, selon que l'installation du module de commande a ou non réussi.
La figure 5 présente une variante de réalisation du mécanisme d'installation du module de commande, lorsque le maître hôte final 31 du bus hôte 1 est la passerelle hôte P1. Les étapes référencées 41 et 50 sur la figure 5 sont décrites dans le protocole de
<Desc/Clms Page number 27>
gestion des modules de commande de la norme HAVi 1.1 ("DCM Management Protocol"), et ne sont mises en oeuvre que si la passerelle locale P3 du bus local 3 est un disciple 28.
Ce mécanisme est très proche de celui décrit précédemment en relation avec la figure 4, mais est simplifié du fait que la passerelle hôte PI du bus hôte 1 est élue comme maître hôte final 31.
Le maître local final 27, à savoir l'équipement référencé C du bus local 3, envoie (41) une requête d'installation ("DMCommand (INSTALL...)") vers la passerelle locale P3, du type INSTALL~URL~PREF, INSTALLURLBAV, INSTALLCODEBAV ou INSTALL.
La passerelle locale P3 du bus local 3 la transmet (42) à la passerelle PI du bus hôte 1, sous la forme d'un message propriétaire ("PROP Install (Host GUID)"), comprenant les identifiants GUID du nouvel équipement B et de l'équipement hôte A.
En effet, comme indiqué précédemment, la passerelle locale P3 connaît ce dernier identifiant, puisqu'au cours de la sélection de l'équipement hôte décrite en relation avec la figure 3, la passerelle locale P3 a présélectionné un équipement hôte préférentiel et mémorisé son identifiant GUID.
Sur réception de la requête d'installation en provenance de la passerelle locale P3, la passerelle hôte PI procède à l'installation 47 du module de commande du nouvel équipement B dans l'équipement hôte A présélectionné : il lui envoie (47a) une requête d'installation sous la forme d'une commande"DMCommand (INSTALL...)", et l'équipement hôte A lui confirme (47b) le succès de l'installation en lui répondant par un message de type"DMCommand (INSTALLED)".
La passerelle hôte PI émet alors (49) une notification de résultat à la passerelle
Figure img00270001

locale P3 du bus local 3, sous forme d'un message propriétaire"PROP. Installed (Host GUID)", dont un paramètre est l'identifiant GUID de l'équipement hôte A, dans lequel a été installé le module de commande.
La passerelle locale P3 du bus local 3, si elle est un disciple 28 du maître local final 27, transmet alors le message propriétaire à ses moyens de fourniture d'informations, de façon que ces derniers le transmette (50), sous forme d'une commande de type"DMCommand"au maître local final 27 du bus local 3 (en l'espèce,
<Desc/Clms Page number 28>
l'équipement référencé C du bus local 3). Cette commande peut être de type INSTALLED ou NOT~INSTALLED, comme défini par la norme HAVi 1.1, selon que l'installation du module de commande a ou non réussi.
Dans le cas où l'équipement hôte sélectionné selon le procédé des figures 2 et 3 est une passerelle d'un bus distant (par exemple la passerelle hôte PI du bus hôte 1), il peut s'avérer avantageux d'installer le module de commande du nouvel équipement B, non pas sur cette passerelle PI, mais sur une autre passerelle du réseau, par exemple sur la passerelle locale P3 du bus local 3. Les passerelles de l'invention présentent pour ce faire des moyens de chargement du programme du module de commande.
Cependant, les programmes des modules de commande (ou"Code Unit") étant généralement spécifiques de la plate-forme associée, ce mécanisme de chargement à distance (ou"upload") de l'invention ne peut être mis en oeuvre que si les deux passerelles (à savoir ici les passerelles hôte PI et locale P3) ont été produites par le même fabricant.
La figure 6 présente plus en détails le rôle des passerelles dans le mécanisme d'installation d'un module de commande, mettant en oeuvre les moyens de chargement de programme du module de commande, du système de l'invention.
On notera que les étapes référencées 41 et 50 sur la figure 6 sont décrites dans le protocole de gestion de modules de commande de la norme HAVi 1.1 ("DCM Management Protocol"), et ne sont mises en oeuvre que si la passerelle locale P3 est un disciple 28 du maître local final 27 du bus local 3.
Le maître local final 27, à savoir l'équipement référencé C du bus local 3, envoie (41) une requête d'installation ("DMCommand (INSTALL...)") vers la passerelle locale P3, du type INSTALL~URL~PREF, INSTALLURLBAV, INSTALLCODEBAV ou INSTALL.
La passerelle locale P3 du bus local 3 la traite, la transforme en requête de programme de module de commande, puis la transmet (51) à la passerelle PI du bus hôte 1, sous la forme d'un message propriétaire ("PROP DCM request (Host GUID)"), comprenant l'identifiant GUID de l'équipement hôte A, à savoir ici la passerelle hôte P1.
Au cours de cette même étape référencée 51, la passerelle hôte PI, qui contient le programme du module de commande du nouvel équipement B, transfert ce
<Desc/Clms Page number 29>
programme à la passerelle locale P3, sous la forme d'un message propriétaire"PROP.
DCM Code Unit Download".
La passerelle locale P3 installe alors (47) le module de commande du nouvel équipement B en local, puis transmet (50), via ses moyens de fourniture d'informations, une commande de type"DMCommand"au maître local final 27 du bus local 3 (en l'espèce, l'équipement référencé C du bus local 3). Cette commande peut être de type INSTALLED ou NOT-INSTALLED, comme défini par la norme HAVi 1.1, selon que l'installation du module de commande a ou non réussi.
On présente désormais, en relation avec les figures 7a et 7b, un exemple de mode de réalisation du contrôle d'un nouvel équipement, connecté à un premier bus, et dont le module de commande a été installé sur un deuxième bus distant, par un module fonctionnel élémentaire, appelé module émetteur.
Pour que le module émetteur soit capable de contrôler l'équipement B, il faut en effet qu'il puisse envoyer des messages au module de commande du nouvel équipement B, même si ce module de commande est situé sur un bus distant.
La communication, au sein du système de l'invention, entre deux modules fonctionnels élémentaires hébergés par deux équipements connectés à des bus distincts est notamment décrite dans une demande de brevet français conjointe, déposée le même jour que la présente demande, par le même déposant, et ayant pour titre"Système et procédé de gestion d'une communication entre un module émetteur et au moins un module destinataire, au sein d'un réseau audiovisuel domestique". Les enseignements de cette demande conjointe sont incorporés ici par référence.
Comme expliqué en détail dans cette demande de brevet conjointe, les passerelles gèrent deux types de connexions d'équipements au niveau de leurs piles HAVi : celles qui se font sans passer par les passerelles ( solution basée sur 1394.1 , avec utilisation des adresses réelles des modules fonctionnels élémentaires impliqués). celles qui se font via les passerelles ( solution basée sur des proxys de modules fonctionnels élémentaires , avec utilisation des adresses de ces proxys).
<Desc/Clms Page number 30>
On considère l'exemple des figures 7a et 7b, où un nouvel équipement référencé 73, de type BAV ou LAV, vient d'être connecté à un bus local B2. Le bus local B2 est relié au bus distant BI par un pont référencé 74, conforme à la norme 1394.1. Chaque porte de ce pont est aussi une passerelle référencée PI, P2 pour chacun des bus référencés BI, B2.
Selon le mécanisme d'installation de module de commande décrit précédemment en relation avec les figures 2 à 5, un équipement de type IAV ou FAV référencé 81 du bus distant Bl a été sélectionné comme équipement hôte, et héberge donc le module de commande référencé 71 du nouvel équipement 73.
Un équipement référencé 75, appelé équipement émetteur, connecté au même bus local B2 que le nouvel équipement référencé 73, souhaite contrôler ce dernier.
La figure 7a illustre le cas où l'équipement émetteur 75 est conforme à la norme 1394.1.
L'équipement 81 qui héberge le module de commande 71 (ou SE pour l'anglais "Software Element") est également conforme à la norme 1394.1. L'équipement émetteur 75, via son module d'application 70 (ou AM pour l'anglais"Application Module"), peut donc envoyer directement, au module de commande 71 du nouvel équipement 73, des messages de type HAVi 76 encapsulés dans des paquets 1394. 1 77.
Le module de commande 71 étant hébergé par un équipement 81 conforme à la norme 1394.1, il peut en outre envoyer un message propriétaire 78 au nouvel équipement 73, de façon par exemple à émettre une commande de type AV/C (par exemple un code de lecture"PLAY") vers ce nouvel équipement 73. Les commandes de type AV/C sont définies dans la norme AV/C Digital Interface Command Set, General Specifications, version 3.0 ; 15 avril 1998 .
Dans ce mode de réalisation, fondé sur une solution basée sur 1394.1, la communication entre le module émetteur 70 et le module de commande 71, qu'on peut encore appeler module destinataire, se fait donc sans passer par les passerelles PI et P2, car les deux modules 70 et 71 qui communiquent sont tous deux hébergés par un équipement conforme à la norme 1394.1.
La figure 7b illustre le cas où l'équipement émetteur 75 n'est pas conforme à la norme 1394.1.
<Desc/Clms Page number 31>
L'équipement 81 qui héberge le module de commande 71 peut quant à lui être ou non conforme à cette norme 1394.1. Dans un mode de réalisation préféré de l'invention, l'équipement 81 est de type 1394. 1.
Selon cette solution basée sur des proxys de modules fonctionnels élémentaires, on crée, sur le bus local B2, un proxy pSE 72 (pour l'anglais"proxy Software Element") du module de commande 71, de façon que ce proxy 72 soit visible pour tous les équipements HAVi du bus local B2.
Sur l'exemple de la figure 7b, le pSE 72 est hébergé par la passerelle P2 du bus local B2.
De même, on crée, sur le bus distant Bl, un proxy pAM 80 (pour l'anglais "proxy Application Module") du module d'application 70, de façon que ce proxy 80 soit visible pour tous les équipements HAVi du bus distant Bl. Ce pAM 80 est hébergé par la passerelle PI du bus distant B 1.
L'équipement émetteur 75, via son module d'application 70, peut donc envoyer au proxy 72 du module de commande 71, des messages de type HAVi 76 encapsulés dans des paquets 1394 79.
Ces messages sont ensuite transmis du proxy 72 à la passerelle PI (ou plus exactement au programme propre à la passerelle PI, appelé HBPM), puis de la passerelle PI au module de commande 71, sous forme de messages HAVi.
En retour, lorsque le module de commande 71 souhaite répondre au module d'application 70, il envoie un message HAVi 76 au proxy pAM 80 du module d'application 70. Ce message est transmis à la passerelle P2 (ou plus exactement à son HBPM), puis transféré par cette dernière au module d'application 70, sous forme de message HAVi.
Le module de commande 71 peut en outre envoyer un message propriétaire 78 au nouvel équipement 73, de façon par exemple à émettre une commande de type AV/C (par exemple une commande de lecture de type"PLAY") vers ce nouvel équipement 73.
Dans ce mode de réalisation, fondé sur une solution mettant en oeuvre des proxys de modules fonctionnels élémentaires, la communication entre le module émetteur 70 et le module de commande 71, qu'on peut encore appeler module destinataire, se fait donc en passant par les passerelles PI et P2, qui hébergent respectivement un proxy 80 du
<Desc/Clms Page number 32>
module d'application 70 et un proxy 72 du module de commande 71, et rendent ainsi visible, sur le bus local B2, le module de commande 71 pourtant hébergé sur le bus distant Bl, et, sur le bus distant Bl, le module d'application 70 pourtant hébergé sur le bus local B2.
Le rôle de la passerelle P2 (respectivement PI) dans ce mécanisme consiste notamment, lorsqu'un message HAVi est reçu du module de commande 71 (respectivement du module d'application 70), grâce aux moyens de communication entre passerelles, à opérer une traduction d'adresses, de façon à permettre au module émetteur 70 de communiquer par la suite avec le module destinataire 71. Le message HAVi, en provenance du module de commande 71, via le proxy du module émetteur 80, est ainsi transmis aux moyens de fourniture d'informations de la passerelle P2, ces derniers transférant ensuite le message au module émetteur 70, en changeant notamment l'adresse source, de celle du module de commande 71, en celle du proxy de module de commande 72.
La traduction inverse, pour un message en provenance du module émetteur 70, et à destination du module de commande 71, est bien sûr également effectuée par la passerelle PI.
Le module émetteur 70 peut donc communiquer avec le module destinataire 71, par la mise en oeuvre du proxy 72 du module destinataire et du proxy 80 du module émetteur.
Il est également à noter que, dans une première variante, si le module destinataire n'a pas besoin de répondre au module émetteur, le mécanisme de proxy peut être mis en oeuvre dans un seul sens (pas de proxy du module émetteur).
On peut aussi, dans certains cas particuliers, mettre en oeuvre le mécanisme de proxy dans un seul sens (pas de proxy du module émetteur), même si le module destinataire a besoin de répondre au module émetteur. Il s'agit des cas où le module récepteur sait conserver (afin de retrouver seul) l'adresse du module émetteur, par exemple en mémorisant l'association d'une adresse source (src) comprise dans un
Figure img00320001

paquet de type 1394 émis par le module émetteur, et d'une adresse source (SEIDsrc) comprise dans un message HAVi émis par ce même module émetteur.

Claims (27)

REVENDICATIONS
1. Système de gestion d'un réseau audiovisuel domestique permettant l'interconnexion d'une pluralité d'équipements, dans lequel : - ledit réseau comprend au moins deux bus, sur chacun desquels peut être connecté au moins un desdits équipements, et au moins un premier équipement spécifique formant pont, interconnectant lesdits au moins deux bus, - ledit réseau est conforme à une première norme relative à l'interconnexion d'équipements via des bus numériques eux-mêmes interconnectés par des ponts, - les équipements, y inclus les ponts, sont conformes à une seconde norme d'interopérabilité entre équipements, définissant une couche intermédiaire 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, - une pluralité de modules fonctionnels élémentaires (SE) est hébergée par ladite pluralité d'équipements, chacun desdits équipements étant commandé par un module fonctionnel élémentaire spécifique, dit module de commande (DCM), - au moins un deuxième équipement spécifique formant passerelle (HBP) est connecté à chaque bus, - les passerelles comprennent des moyens de communication entre passerelles leur permettant d'avoir une vision dudit système au sens de ladite seconde norme, - ledit système comprend en outre : * des moyens de recherche, via lesdits moyens de communication entre passerelles, d'équipements effectivement capables d'héberger un module de commande d'un équipement, appelé nouvel équipement, nouvellement connecté à un bus, dit bus local, ladite recherche portant sur l'ensemble des équipements potentiellement capables d'héberger ledit module, connectés aux autres bus du réseau, dits bus distants, et ayant connaissance d'au moins une des passerelles desdits bus distants ; * des moyens, activés si le résultat de la recherche n'est pas nul, de sélection d'un équipement, dit équipement hôte, parmi celui ou ceux résultant de la recherche, en fonction d'au moins un critère fonctionnel prédéterminé ; * des moyens d'installation, dans ledit équipement hôte, dudit module de commande.
<Desc/Clms Page number 34>
2. Système selon la revendication 1, dans lequel lesdits moyens de recherche permettent au préalable d'effectuer ladite recherche parmi l'ensemble des équipements potentiellement capables d'héberger ledit module de commande et connectés audit bus local, de façon que, si au moins un équipement connecté audit bus local, dit équipement local, est identifié au cours de ladite recherche, lesdits moyens de sélection sélectionnent ledit au moins un équipement local comme équipement hôte.
3. Système selon la revendication 1, dans lequel lesdits moyens de recherche permettent également d'effectuer ladite recherche simultanément parmi l'ensemble des équipements potentiellement capables d'héberger ledit module de commande et connectés audit bus local.
4. Système selon l'une quelconque des revendications 1 à 3, dans lequel, au sein des équipements connectés auxdits bus distants, ladite recherche ne porte que sur les équipements conformes à ladite première norme.
5. Système selon l'une quelconque des revendications 1 à 4, comprenant des premiers moyens d'élection d'un troisième équipement spécifique dudit bus local, dit maître local final, destiné à initier la mise en ceuvre desdits moyens de recherche et à mettre en oeuvre lesdits moyens de sélection.
6. Système selon la revendication 5, dans lequel ledit maître local final est une passerelle dudit bus local, dite passerelle locale.
7. Système selon la revendication 3 et l'une quelconque des revendications 5 et 6, dans lequel lesdits moyens de recherche comprennent eux-mêmes : dans ledit maître local final : * des moyens de diffusion d'une requête d'hébergement, vers les équipements du bus local potentiellement capables d'héberger le module de commande du nouvel équipement, et de réception des réponses fournies par lesdits équipements du bus local ; * des moyens, activés si ledit maître local final n'est pas une passerelle dudit bus local, dite passerelle locale, d'émission de la requête d'hébergement vers ladite passerelle locale, et de réception d'une réponse fournie par ladite passerelle locale ; dans ladite passerelle locale :
<Desc/Clms Page number 35>
* des moyens, activés si ladite passerelle locale n'est pas ledit maître local final, de réception de ladite requête d'hébergement en provenance du maître local final et de réponse audit maître local final ; * des moyens de diffusion de la requête d'hébergement vers les passerelles desdits bus distants, appelées passerelles distantes, et de réception des réponses fournies par lesdites passerelles distantes ; * des moyens, activés si au moins une des réponses fournies par lesdites passerelles distantes est positive, de présélection d'un équipement d'un desdits bus distants effectivement capable d'héberger ledit module de commande, en fonction dudit au moins un critère fonctionnel prédéterminé ; dans chaque passerelle distante : * parmi les moyens de communication entre passerelles, des moyens de réception de la requête d'hébergement et des moyens de diffusion de ladite requête vers les équipements du bus distant auquel est connectée ladite passerelle distante, qui sont potentiellement capables d'héberger le module de commande dudit nouvel équipement et ayant connaissance de ladite passerelle distante ; * des moyens de réception des réponses fournies par les équipements du bus distant ; * parmi les moyens de communication entre passerelles de ladite passerelle distante, des moyens de transmission des réponses des équipements du bus distant sous forme d'une liste d'équipements du bus distant effectivement capables d'héberger ledit module de commande en réponse à ladite passerelle locale.
Figure img00350001
8. Système selon la revendication 7, dans lequel ladite requête d'hébergement comprend un identifiant du nouvel équipement.
9. Système selon l'une quelconque des revendications 7 et 8, dans lequel ladite passerelle locale comprend également des premiers moyens, activés si ladite passerelle locale n'est pas ledit maître local final, de mémorisation d'un identifiant dudit équipement présélectionné,
<Desc/Clms Page number 36>
en vue de l'éventuelle installation du module de commande du nouvel équipement dans ledit équipement présélectionné, si ledit équipement présélectionné est sélectionné par ledit maître local final comme équipement hôte.
10. Système selon l'une quelconque des revendications 1 à 9, comprenant des seconds moyens d'élection d'un quatrième équipement spécifique, dit maître hôte final, du bus auquel est connecté l'équipement hôte, dit bus hôte.
11. Système selon la revendication 10, dans lequel ledit maître hôte final est une passerelle dudit bus hôte, dite passerelle hôte.
12. Système selon l'une quelconque des revendications 10 et 11, dans lequel lesdits moyens d'installation comprennent eux-mêmes : dans la passerelle locale, parmi les moyens de communication entre passerelles : * des moyens de transmission d'une requête d'installation dudit module de commande, comprenant l'identifiant dudit équipement présélectionné, vers ladite passerelle hôte ; * des moyens de réception d'une confirmation d'installation, comprenant l'identifiant dudit équipement hôte, en provenance de ladite passerelle hôte ; * des moyens, activés si la passerelle locale n'est pas le maître local final, de transmission d'une confirmation d'installation simplifiée, ne comprenant pas l'identifiant de l'équipement hôte, au maître local final ; dans la passerelle hôte, parmi les moyens de communication entre passerelles : * des moyens de réception de la requête d'installation dudit module de commande en provenance de ladite passerelle locale ; * des moyens de transmission de la confirmation d'installation, vers ladite passerelle locale ; * des moyens, activés si la passerelle hôte n'est pas le maître hôte final, de transmission d'une requête d'installation simplifiée, ne comprenant pas l'identifiant de l'équipement présélectionné, au maître hôte final ; dans ledit maître hôte final, des moyens de commande pilotant des moyens d'instanciation du module de commande dans l'équipement hôte.
13. Système selon la revendication 12, dans lequel lesdits moyens d'installation comprennent en outre, dans ledit maître local final, des moyens, activés si le maître
<Desc/Clms Page number 37>
local final n'est pas la passerelle locale, d'émission de ladite requête d'installation vers la passerelle locale, et des moyens de réception de ladite confirmation d'installation, fournie par ladite passerelle locale.
14. Système selon l'une quelconque des revendications 12 et 13, dans lequel lesdits moyens d'installation comprennent également les moyens suivants, qui sont activés si la passerelle hôte n'est pas le maître hôte final : dans la passerelle hôte : * des seconds moyens de mémorisation de l'identifiant dudit équipement présélectionné ; * des moyens de réception d'une notification d'installation, comprenant l'identifiant du nouvel équipement, en provenance du maître hôte final ; * des moyens de vérification que ledit module de commande a bien été installé dans ledit équipement présélectionné ; dans ledit maître hôte final, des moyens de mise en oeuvre d'un mécanisme, prévu par ladite seconde norme d'interopérabilité, de sélection d'un équipement hôte tenant notamment compte de l'identifiant de l'équipement présélectionné, mémorisé par ladite passerelle hôte.
15. Système selon l'une quelconque des revendications 1 à 14, dans lequel ladite seconde norme d'interopérabilité entre équipements est la norme HAVi (en anglais "Home Audio Video interoperability").
16. Système selon l'une quelconque des revendications 1 à 15, dans lequel ladite première norme, relative à l'interconnexion d'équipements via des bus numériques euxmêmes interconnectés par des ponts, est la norme 1394.1.
17. Système selon l'une quelconque des revendications 1 à 16, dans lequel au moins un desdits deuxièmes équipements spécifiques formant passerelles (HBP) est également compris dans un desdits premiers équipements spécifiques formant pont.
18. Système selon l'une quelconque des revendications 1 à 17, dans lequel : au moins deux passerelles sont connectées à un bus donné, - le système comprend des moyens de sélection de l'une desdites au moins deux passerelles, dite passerelle sélectionnée, de façon que seule la passerelle sélectionnée joue effectivement le rôle de passerelle sur ledit bus donné.
<Desc/Clms Page number 38>
19. Système selon l'une quelconque des revendications 1 à 17, dans lequel : au moins deux passerelles sont connectées à un bus donné, - le système comprend des moyens permettant de faire coopérer lesdites au moins deux passerelles, de façon que lesdites au moins deux passerelles jouent ensemble le rôle d'une unique passerelle sur ledit bus donné.
20. Système selon l'une quelconque des revendications 1 à 19, comprenant en outre des moyens, activés si les moyens d'installation ont permis l'installation du module de commande dans un équipement hôte qui est une passerelle, dite passerelle hôte, de chargement d'un programme du module de commande dudit équipement hôte dans la passerelle locale, de façon à installer ledit module de commande dans ladite passerelle locale.
21. Système selon la revendication 20, dans lequel les moyens de chargement comprennent eux-mêmes : dans le maître local final, des moyens, activés si le maître local final n'est pas la passerelle locale : * d'émission d'une requête d'installation du module de commande vers la passerelle locale ; * de réception d'une confirmation d'installation, fournie par lesdits moyens de fourniture d'informations de la passerelle locale ; dans la passerelle locale : * parmi lesdits moyens de communication entre passerelles, des moyens de transmission d'une requête de chargement de programme vers ladite passerelle hôte, et de réception dudit programme du module de commande en provenance de la passerelle hôte ; * des moyens d'instanciation dudit module de commande, à partir dudit programme reçu, dans ladite passerelle locale ; * parmi lesdits moyens de fourniture d'informations, des moyens de transmission de la confirmation d'installation audit maître local final ; dans la passerelle hôte, parmi lesdits moyens de communication entre passerelles, des moyens de transmission du programme du module de commande vers la passerelle locale, en réponse à ladite requête de chargement.
<Desc/Clms Page number 39>
22. Système selon l'une quelconque des revendications 1 à 21, dans lequel ledit équipement hôte, les passerelles, le maître local final et le maître hôte final, sont conformes à la première norme, de façon qu'un module émetteur, hébergé dans un équipement, dit équipement émetteur, éventuellement connecté à un bus distinct dudit bus hôte et/ou dudit bus local, transmette, sans passer par les passerelles, en vue de communiquer avec et/ou de contrôler le nouvel équipement : - des paquets (paquets 1394) contenant des informations de routage permettant auxdits paquets d'atteindre le nouvel équipement, vers ledit nouvel équipement, - des messages conformes à la seconde norme (messages HAVi), vers le module de commande hébergé par l'équipement hôte, ledit équipement émetteur étant également conforme à la première norme.
Figure img00390001
23. Système selon l'une quelconque des revendications 1 à 21, dans lequel les passerelles comprennent des moyens de gestion de proxys de modules fonctionnels élémentaires, de façon qu'un module émetteur, hébergé dans un équipement, dit équipement émetteur, éventuellement connecté à un bus distinct dudit bus hôte et/ou dudit bus local, transmette en passant par les passerelles, en vue de communiquer avec et/ou de contrôler le nouvel équipement : - des paquets (paquets 1394) contenant des informations de routage permettant auxdits paquets d'atteindre le nouvel équipement, vers ledit nouvel équipement, - des messages conformes à la seconde norme (messages HAVi), vers le module de commande hébergé par l'équipement hôte, en utilisant le proxy du module de commande, ledit équipement émetteur n'étant pas conforme à la première norme.
24. Système selon l'une quelconque des revendications 1 à 21, dans lequel les passerelles sont conformes à la première norme et comprennent des moyens de gestion de proxys de modules fonctionnels élémentaires, de façon qu'un module émetteur, hébergé dans un équipement, dit équipement émetteur, éventuellement connecté à un bus distinct dudit bus hôte et/ou dudit bus local, transmette, en vue de communiquer avec et/ou de contrôler le nouvel équipement :
<Desc/Clms Page number 40>
- des paquets (paquets 1394) contenant des informations de routage permettant auxdits paquets d'atteindre le nouvel équipement, vers ledit nouvel équipement, * sans passer par les passerelles, si l'équipement émetteur est conforme à la première norme, * en passant par les passerelles, si l'équipement émetteur n'est pas conforme à la première norme, - des messages conformes à la seconde norme (messages HAVi), vers le module de commande hébergé par l'équipement hôte : * sans passer par les passerelles, si l'équipement émetteur et l'équipement hôte sont conformes à la première norme, * en passant par les passerelles et en utilisant le proxy du module de commande, si l'équipement émetteur et/ou l'équipement hôte n'est (ne sont) pas conforme (s) à la première norme.
25. Procédé de gestion de l'installation d'un module de commande, au sein d'un système selon l'une quelconque des revendications 1 à 24, ledit procédé comprenant : * une étape de recherche d'équipements effectivement capables d'héberger un module de commande d'un équipement, appelé nouvel équipement, nouvellement connecté à un bus, dit bus local, ladite étape de recherche portant sur l'ensemble des équipements potentiellement capables d'héberger ledit module, connectés aux autres bus du réseau, dits bus distants, et ayant connaissance d'au moins une des passerelles desdits bus distants ; * une étape, mise en oeuvre si le résultat de la recherche n'est pas nul, de sélection d'un équipement, dit équipement hôte, parmi celui ou ceux résultant de la recherche, en fonction d'au moins un critère fonctionnel prédéterminé ; * une étape d'installation, dans ledit équipement hôte, dudit module de commande.
26. Programme d'ordinateur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution des étapes du procédé selon la revendication 25, lorsque ledit programme est exécuté sur un ordinateur.
27. Produit programme d'ordinateur, adapté à la gestion de l'installation d'un module de commande, au sein d'un système selon l'une quelconque des revendications 1 à 24,
<Desc/Clms Page number 41>
ledit produit programme d'ordinateur comprenant des instructions de code de programme enregistré sur un support utilisable dans un ordinateur comprenant : des moyens de programmation lisibles par ordinateur pour effectuer l'étape de recherche d'équipements effectivement capables d'héberger un module de commande d'un équipement, appelé nouvel équipement, nouvellement connecté à un bus, dit bus local, ladite étape de recherche portant sur l'ensemble des équipements potentiellement capables d'héberger ledit module, connectés aux autres bus du réseau, dits bus distants, et ayant connaissance d'au moins une des passerelles desdits bus distants ; des moyens de programmation lisibles par ordinateur pour effectuer l'étape, mise en oeuvre si le résultat de la recherche n'est pas nul, de sélection d'un équipement, dit équipement hôte, parmi celui ou ceux résultant de ladite recherche, en fonction d'au moins un critère fonctionnel prédéterminé ; des moyens de programmation lisibles par ordinateur pour effectuer l'étape d'installation, dans ledit équipement hôte, dudit module de commande.
FR0201175A 2002-01-28 2002-01-28 Systeme et procede de gestion de l'installation d'un module de commande d'un equipement, au sein d'un reseau audiovisuel domestique Expired - Fee Related FR2835372B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR0201175A FR2835372B1 (fr) 2002-01-28 2002-01-28 Systeme et procede de gestion de l'installation d'un module de commande d'un equipement, au sein d'un reseau audiovisuel domestique

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0201175A FR2835372B1 (fr) 2002-01-28 2002-01-28 Systeme et procede de gestion de l'installation d'un module de commande d'un equipement, au sein d'un reseau audiovisuel domestique

Publications (2)

Publication Number Publication Date
FR2835372A1 true FR2835372A1 (fr) 2003-08-01
FR2835372B1 FR2835372B1 (fr) 2004-04-09

Family

ID=27619799

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0201175A Expired - Fee Related FR2835372B1 (fr) 2002-01-28 2002-01-28 Systeme et procede de gestion de l'installation d'un module de commande d'un equipement, au sein d'un reseau audiovisuel domestique

Country Status (1)

Country Link
FR (1) FR2835372B1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1009139A2 (fr) * 1998-12-08 2000-06-14 Sony Corporation Méthode pour attribuer des modules logiciels
WO2000076131A1 (fr) * 1999-06-02 2000-12-14 Thomson Licensing S.A. Procedes de pontage d'un sous-reseau a interactivite audio-video domestique (havi) et d'un sous-reseau a autoconfiguration universelle (upnp), et dispositif de mise en oeuvre de ces procedes

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1009139A2 (fr) * 1998-12-08 2000-06-14 Sony Corporation Méthode pour attribuer des modules logiciels
WO2000076131A1 (fr) * 1999-06-02 2000-12-14 Thomson Licensing S.A. Procedes de pontage d'un sous-reseau a interactivite audio-video domestique (havi) et d'un sous-reseau a autoconfiguration universelle (upnp), et dispositif de mise en oeuvre de ces procedes

Also Published As

Publication number Publication date
FR2835372B1 (fr) 2004-04-09

Similar Documents

Publication Publication Date Title
IES20050770A2 (en) A server device for a media processing network
FR2859341A1 (fr) Methode de controle entre appareils connectes a un reseau heterogene et appareil implementant la methode
EP3149917B1 (fr) Dispositif et procede pour passerelle de mise a jour consistente des services d&#39;un reseau domestique
EP2107723B1 (fr) Commande d&#39;un dispositif a distance par un terminal
EP1446922A2 (fr) Systeme et procede de gestion d&#39;applications dediees a des appareils connectes a un reseau-maison
FR2866173A1 (fr) Procedes et systeme d&#39;initialisation et de validation de l&#39;etablissement ou du transfert d&#39;une connexion dans un reseau de communication, terminaux et boitier de telecommande correspondants.
EP1074117B1 (fr) Procede de gestion d&#39;objets dans un reseau de communication et dispositif de mise en oeuvre
FR2908196A1 (fr) Procede de transfert de donnees multimedia
FR2835372A1 (fr) Systeme et procede de gestion de l&#39;installation d&#39;un module de commande d&#39;un equipement, au sein d&#39;un reseau audiovisuel domestique
FR2884943A1 (fr) Procede de gestion de commande au sein d&#39;un reseau de communication, dispositif de controle, produit programme d&#39;ordinateur et moyen de stockage correspondants
WO2012010803A1 (fr) Mise a disposition d&#39;informations par un terminal mobile dans un reseau
FR2835373A1 (fr) Systeme et procede de gestion de l&#39;etablissement d&#39;une connexion de flux, au sein d&#39;un reseau audiovisuel domestique
FR2835370A1 (fr) Systeme et procede de gestion d&#39;une communication entre un module emetteur et au moins un module destinataire, au sein d&#39;un reseau audiovisuel domestique
FR2837045A1 (fr) SYSTEME ET PROCEDE DE GESTION DE TRANSFERT D&#39;INFORMATIONS SUR UN RESEAU CONFORME A UNE NORME DE TRANSMISSION DE DONNEES, NOTAMMENT LA NORME UPnP, MACHINE D&#39;INTERFACAGE ET D&#39;EMULATION ET PROGRAMME D&#39;ORDINATEUR CORRESPONDANTS
FR2856874A1 (fr) Procede et systeme de reservation d&#39;au moins une ressource d&#39;un appel controlable par un controleur au sein d&#39;un reseau, programme d&#39;ordinateur correspondant
FR2848056A1 (fr) Procedes d&#39;insertion et de traitement d&#39;informations pour la synchronisation d&#39;un noeud destinataire a un flux de donnees traversant un reseau de base d&#39;un reseau heterogene, et noeuds correspondants
EP2577915B1 (fr) Partage d&#39;informations de contexte de restitution entre dispositifs de pilotage
FR3086478A1 (fr) Gestion du fonctionnement d&#39;une telecommande lors de la reception d&#39;un appel telephonique.
EP2282475B1 (fr) Procédé et dispositif de restitution d&#39;un contenu multimédia
FR2918241A1 (fr) Procede, serveur et application pour le partage de contenus personnels entre terminaux d&#39;usager(s)
EP4568212A1 (fr) Procede et dispositif de gestion d une mise a jour d un dispositif terminal dans un reseau de telecommunication.
FR2876238A1 (fr) Procede et dispositif de gestion de l&#39;enregistrement d&#39;un flux audio video au sein d&#39;un reseau de communication, et produit programme d&#39;ordinateur correspondant
FR2906097A1 (fr) Procedes d&#39;echange de donnees securises, produit programme d&#39;ordinateur, moyen de stockage et dispositifs correspondants.
FR2828357A1 (fr) Procede de traitement de signaux de telecommande au sein d&#39;un reseau audiovisuel domestique, signal, dispositifs et programme d&#39;ordinateur correspondants
FR2826814A1 (fr) Procede d&#39;utilisation a distance de moyens de reception de signaux audiovisuels appartenant a un reseau audiovisuel domestique primaire, passerelles, procede d&#39;allocation de ressources correspondants

Legal Events

Date Code Title Description
ST Notification of lapse

Effective date: 20140930