Brevet FR2859341A1 — publié le 20050304

METHODE DE CONTROLE ENTRE APPAREILS CONNECTES A UN RESEAU HETEROGENE ET APPAREIL IMPLEMENTANT LA METHODE L'invention concerne une méthode de contrôle entre appareils 5 connectés à des réseaux hétérogènes, ainsi que la passerelle implémentant la méthode. L'invention se place dans le cadre d'un réseau hétérogène possédant au moins un premier bus selon un premier protocole, par exemple le protocole IEEE 1394 défini dans le document "IEEE Std 1394-1995 High Performance Bus, 1996-08-30", au moins un second bus selon un autre protocole, par exemple le protocole Ethernet. Les différents bus du réseau hétérogène considéré sont connectés par une passerelle permettant aux appareils connectés sur les différents bus de communiquer entre eux. Les is appareils connectés aux bus sont contrôlables à distance, c'est-à-dire que les services qu'ils offrent sont rendus accessibles sur leur bus, grâce au suivi de normes de contrôle telle que HAVi (Home Audio Video interoperability), dont on peut trouver les spécifications dans le documents suivant "HAVi Specification version 1.1", sur IEEE 1394, ou UPnP (Universal Plug and Play) dont l'architecture est définie dans le document "UPnP Device Architecture 1.0" sur Ethernet. Ces normes de contrôle permettent à un appareil, appelé client, d'interagir et de piloter un autre appareil sur le même bus, appelé appareil cible. La passerelle offre également des services de contrôle permettant à un appareil client, connecté à un des bus d'accéder aux services fournis par un appareil cible, se trouvant, soit sur le même bus soit sur un autre bus du réseau. Cette passerelle peut par exemple répondre aux spécifications OSGi (Open Service Gateway initiative) dont les spécifications peuvent être trouvées dans le document "OSGi Service Platform. Release 3". Ce résultat est obtenu car la passerelle est compatible avec toutes les normes de contrôle utilisées par les différents bus, ces normes étant rendues accessibles de manière uniforme à tous les appareils de tous les bus connectés. Dans un tel réseau, la passerelle est capable d'accéder aux services rendus par les différents appareils présents sur les bus connectés à cette passerelle et donc de les contrôler. Pour ce faire la passerelle utilise la norme propre à chaque bus lui permettant de contrôler les appareils connectés sur ce bus. La passerelle offre également une interface de contrôle des appareils selon un protocole standard, par exemple HTTP (Hyper Text Transfer Protocol). Par ce mécanisme, le contrôle des appareils cibles connectés à tout bus du réseau est possible par tout appareil client possédant un logiciel compatible avec le protocole standard, par exemple un navigateur de page HTML (Hyper Text Markup Language) utilisant le protocole HTTP pour communiquer avec la passerelle. II est donc possible dans le réseau, pour tout appareil client pourvu du navigateur ad hoc, de contrôler tout appareil cible connecté soit sur le même bus soit sur un autre bus, via l'interface de contrôle offerte par la passerelle. Les messages de contrôle et les réponses circulant suivant le protocole standard, par exemple HTTP, entre le client et la passerelle, tandis que les messages de contrôle circulent suivant la norme de contrôle propre à chaque bus entre la passerelle et l'appareil cible. L'invention concerne une méthode de contrôle d'un appareil cible, par un appareil client, dans un réseau hétérogène contenant.au moins un bus selon un premier protocole donné, au moins un second bus selon un second protocole, une passerelle entre les bus offrant des moyens centralisés de contrôle des appareils connectés aux bus pouvant jouer le rôle d'appareil cible, lesdits moyens centralisés de contrôle permettant de contrôler les appareils cibles de chaque bus en utilisant la norme de contrôle propre au bus, lesdits moyens centralisés de contrôle étant rendus accessibles aux appareils pouvant jouer le rôle de clients via un serveur sur la passerelle selon un protocole de communication standard caractérisée en ce que la méthode comporte au moins les étapes suivantes: une étape de transfert conditionnelle d'une application de contrôle de l'appareil cible depuis la passerelle vers l'appareil client; une étape d'exécution de cette application de contrôle, Lorsqu'elle est transférée, par l'appareil client, impliquant un dialogue direct entre les deux appareils, client et cible, selon la norme de contrôle du bus auquel ils sont connectés. Selon un mode de réalisation préférentiel de l'invention, la méthode to comporte, pour un appareil client, une étape préalable d'envoi à la passerelle d'une information de profil indiquant sa capacité à exécuter une application de contrôle selon une norme donnée. Selon un mode de réalisation préférentiel de l'invention, la méthode 15 comporte, pour la passerelle, une étape de prise de décision du transfert d'une application de contrôle vers l'appareil client. Selon un mode de réalisation préférentiel de l'invention, l'étape de prise de décision du transfert de l'application de contrôle est basée sur ladite information de profil et la détection de la présence des deux appareils, client et cible, sur le même bus. Selon un mode de réalisation préférentiel de l'invention, l'application de contrôle est une application JAVA. L'invention concerne également le dispositif passerelle implémentant la méthode. L'invention permet à un client désirant contrôler un appareil cible situé sur le même bus que lui, d'échanger des messages de contrôle directement sur le bus dans le protocole natif de communication de ce bus. Pour ce faire, le client désirant interagir avec un appareil cible se connecte à la passerelle. Cette dernière possède la capacité d'offrir une interface de contrôle de tous les appareils du réseau. Cette interface est offerte de manière uniforme pour tous les appareils cibles du réseau à travers un protocole standard, par exemple des pages HTML dynamiques. C'est la passerelle qui traduit les ordres de contrôle passés par le client en commandes adaptées à la norme de contrôle (HAVi, UPnP ou autre) propre au bus sur lequel est connectée la cible. Ceci permet d'économiser la bande passante du bus et la charge de la passerelle qui ne sert plus d'interface obligée entre le client et la cible lorsque ceux-ci se trouvent sur le même bus. io Bien entendu, cette communication directe ne doit pas remettre en cause le statut des appareils engagés dans une telle communication tel qu'il est connu par la passerelle. Pour ce faire la passerelle recueille sur le bus en question les événements déclenchés par les changements d'état survenant sur les appareils en question de façon à maintenir un statut à jour desdits appareils. D'autres caractéristiques et avantages de la présente invention ressortiront de la description de l'exemple de réalisation qui va suivre, pris à titre d'exemple non limitatif, en référence aux figures annexées dans lesquelles: La figure 1 est un schéma général d'un exemple de réseau hétérogène selon l'invention. La figure 2 est un schéma fonctionnel d'un exemple de passerelle selon l'invention. La figure 3 est un schéma fonctionnel d'un exemple d'appareil source. La figure 4 est un diagramme montrant un exemple de communication selon l'art antérieur connu. La figure 5 est un diagramme montrant le même exemple de 30 communication selon l'invention. La figure 1 représente un schéma général d'un réseau selon un exemple de réalisation. Dans cet exemple, nous avons représenté deux types de bus interconnectés par une passerelle. Il va de soi que l'invention peut comprendre d'autres types de bus selon d'autres protocoles. Dans l'exemple donné nous avons un premier bus selon le protocole IEEE1394 connectant des appareils 8, pouvant être contrôlés selon la norme HAVi. Un second bus est connecté à la passerelle selon le protocole Ethernet, ce second bus connectant des appareils 9, 10 et 11, pouvant être contrôlés suivant la norme UPnP, ce réseau peut également comporter des appareils io non compatibles avec la norme UPnP connectés directement en Ethernet. Ces appareils sont alors des clients mais ne peuvent être eux- même contrôlés par les autres appareils du réseau, ils ne peuvent donc pas être des appareils cibles. La passerelle comporte des interfaces réseau 16 et 17 compatibles avec les bus interconnectés, donc, dans l'exemple donné, des interfaces Ethernet et IEEE1394, au dessus desquelles sont portées des normes de contrôle telles que HAVi et UPnP. Elle comporte en outre un microprocesseur 14 pouvant exécuter les programmes stockés en mémoire morte (Rom) 15 et une mémoire vive de travail (Ram) 13. Ces éléments sont interconnectés par un bus 18. Les appareils connectés ont une architecture voisine. Ils possèdent un processeur 20, de la mémoire vive 19, de la mémoire morte 21 et au moins une interface réseau 22 permettant de les connecter. Ces éléments étant interconnectés via un bus interne 23. Les normes citées ne le sont qu'à titre d'exemple et d'autres normes pourraient être utilisées. La flèche 12 symbolise le contrôle direct de l'appareil cible 11 par l'appareil client 10 selon l'exemple de réalisation de l'invention. Ce contrôle est effectué par une application de contrôle obtenue par l'appareil client 10 auprès de la passerelle selon la méthode décrite à la figure 5. La figure 2 représente les couches principales de logiciels composant la passerelle de notre exemple de réalisation. Nous retrouvons les protocoles de communication du bus telles que Ethernet ou IEEE 1394, au dessus desquelles sont portées les normes de contrôle telles que HAVi ou UPnP. Une couche JAVA disposant des interfaces de communication nécessaires à la communication avec les couches de contrôle permet à des applications JAVA d'utiliser lesdites couches de contrôle présentes (HAVi, UPnP ou autres). Enfin, la passerelle dispose d'un logiciel serveur WEB qui permet à un client distant de naviguer sur des pages de la passerelle. Grâce à la présence de la couche JAVA, il est possible d'avoir sur la passerelle des pages WEB dynamiques utilisant ce langage pour interagir avec des appareils du réseau selon les normes de contrôle disponibles. Il sera donc possible pour un client distant, d'interagir avec une application JAVA io s'exécutant sur le serveur, qui sera à même de dialoguer sur les bus connectés selon la norme de contrôle utilisée par ledit bus. L'application JAVA contenue dans la page pourra également être téléchargée sur le client et exécutée localement. C'est ce transfert de l'application de contrôle en vue de son exécution sur le client qui autorise une communication directe entre le client et la cible. Bien sûr, un langage autre que JAVA pourrait être utilisé, comme par exemple javascript, vbscript, PHP etc. En fait, tout langage interfacé avec la norme de contrôle et pouvant être exécuté par le client en vue d'une exécution locale peut être utilisé. La figure 3 représente les couches principales de logiciels composant un appareil connecté, sur l'un des bus, dans notre exemple de réalisation. Nous trouvons au plus bas niveau le protocole de communication avec le réseau physique qui peut être de l'Ethernet, du IEEE 1394 ou tout autre protocole de communication physique. Au dessus, nous retrouvons la norme de contrôle permettant aux autres appareils du réseau de contrôler l'appareil, cette norme peut être HAVi pour un réseau domestique, ou UPnP sur un réseau Ethernet, ou toute autre norme de contrôle. L'absence de cette norme de contrôle entraîne l'impossibilité pour l'appareil d'être piloté par un autre appareil sur le réseau et donc de jouer le rôle d'appareil cible. Sans cette couche il sera également impossible à l'appareil d'exécuter une application de contrôle pour le pilotage direct d'un appareil cible présent sur le bus. Par contre, cela n'empêche pas l'appareil de pouvoir jouer le rôle d'un client et de piloter un appareil cible via une application de contrôle centrale sur la passerelle. Ce peut être le cas pour des appareils connectés occasionnellement sur le réseau, en particulier via Ethernet, comme par exemple des assistants personnels électroniques, des appareils portatifs de musique MP3 ou autre. Pour pouvoir accéder aux services de la passerelle et au contrôle des autres appareils, un navigateur compatible avec le serveur de la passerelle est encore nécessaire. Ce navigateur, par exemple un navigateur WEB, permet de se connecter au serveur implémenté sur la passerelle et donc d'accéder aux pages de contrôle des appareils cibles du io réseau. La présence d'une implémentation de JAVA possédant l'API (Application Programming Interface) vers la norme de contrôle utilisée sur le réseau va permettre d'exécuter localement des applications de contrôle venant de la passerelle. L'absence de cette couche JAVA ou de l'API JAVA pilotant la norme de contrôle interdira pour cet appareil l'utilisation de is l'application de contrôle en local selon l'exemple de réalisation de l'invention. Dans ce cas l'appareil ne pourra utiliser que la passerelle pour piloter les appareils cibles du réseau. La figure 4 est un diagramme montrant un exemple de communication selon l'art antérieur connu. Dans cet exemple un appareil client, par exemple un moniteur HAVi, veut accéder à un service offert par un appareil cible, par exemple un tuner HAVi, pour afficher un programme, capté par le tuner, sur le moniteur. L'étape 31 consiste pour le client à demander la page des appareils disponibles sur le réseau, il obtient cette page à l'étape 32. L'étape 33 consiste ensuite à sélectionner l'appareil cible choisi, le tuner. II obtient la page des contrôles du tuner par l'étape 34, ce qui lui permet de sélectionner le programme choisi à l'étape 35. L'étape 36 va consister alors pour la passerelle à piloter le tuner selon le programme désiré en lui envoyant les contrôles HAVi permettant la sélection du programme désiré et l'échange de données entre le tuner et le moniteur. Enfin, le changement d'état du tuner va provoquer l'émission d'un événement HAVi qui sera reçu par la passerelle lui permettant de garder en mémoire l'état du tuner, c'est l'étape 37. La figure 5 est un diagramme montrant le même exemple de communication selon l'exemple de réalisation de l'invention. Les étapes 31, 32 et 33 sont similaires à celles de la figure 4. Mais, ici, l'étape 40 va consister pour la passerelle, en réponse à la sélection du tuner, à transmettre avec la page une application JAVA qui va directement s'exécuter sur le client et permettre le contrôle direct du tuner en utilisant le protocole io HAVi. La sélection du programme désiré va donc être interprétée par le programme JAVA qui va générer les contrôles HAVi à destination du tuner. Ces contrôles sont envoyés au tuner directement à l'étape 41 sans passer par la passerelle. Le changement d'état du tuner va toujours provoquer l'émission d'un événement qui sera récupéré par la passerelle comme dans is l'exemple précédent selon une même étape 37. Il nous reste à détailler la façon dont la passerelle sait si elle doit garder le contrôle centralisé et générer des pages permettant au client de piloter les appareils cibles via l'application centrale ou, au contraire, des pages contenant le programme JAVA de contrôle pour exécution sur l'appareil client. Les conditions qui doivent être remplies pour pouvoir décentraliser le contrôle sur le client sont, d'une part que le client et la cible se trouvent sur le même bus, et d'autre part que le client possède les capacités d'exécuter le programme JAVA transmis et possède la couche logicielle interfaçant JAVA avec le protocole de contrôle de haut niveau (HAVi, UPnP, ...). En effet, dans l'exemple de réalisation décrit, les classes JAVA implémentant cette couche d'interface entre JAVA et, par exemple, HAVi, ne sont pas transmises dans le programme JAVA envoyé au client, mais doivent donc être présentes sur le client. Pour que la passerelle possède ces informations lui permettant de décider de cette décentralisation du contrôle, il faut donc que les appareils se connectant au réseau lui envoient une information de profil indiquant ses capacités. Dans l'exemple de réalisation qui nous concerne, cette information de profil peut prendre trois valeurs: HAVi, UPnP et NoControl. La valeur HAVi indique que l'appareil dispose des capacités lui permettant de contrôler des appareils HAVi, il s'agit donc d'un appareil compatible HAVi possédant des capacités JAVA ainsi que la couche d'interface JAVA/HAVi. La valeur UPnP indique que nous sommes en présence d'un appareil io compatible UPnP possédant des capacités JAVA ainsi que la couche d'interface JAVA/UPnP. La valeur NoControl indique un appareil auquel l'une des capacités manque et qui ne peut donc pas faire fonctionner l'application de contrôle JAVA. La passerelle, en présence de ces informations et en fonction également du type de l'appareil cible et de sa localisation, est donc capable de déterminer si elle doit garder un contrôle centralisé ou si il est possible de décentraliser ce contrôle sur l'appareil client. Elle va donc utiliser ses information pour générer soit une page d'interface avec sa propre application centralisée de contrôle, soit pour générer l'application de contrôle pouvant être téléchargée sur le client pour effectuer le contrôle de l'appareil cible. L'exemple de réalisation décrit est non limitatif, il est en particulier possible de réaliser l'invention sur d'autre types de bus, équipés d'autres protocoles de contrôles. Il est également possible d'utiliser d'autres langages que JAVA, comme javascript, vbscript, PHP ou autres, pour l'implémentation des applications de contrôle décentralisées. 2859341 io REVENDICATIONS 1. Méthode de contrôle d'un appareil cible, par un appareil client, dans un réseau hétérogène contenant au moins un bus selon un premier protocole donné, au moins un second bus selon un second protocole, une passerelle entre les bus offrant des moyens centralisés de contrôle des appareils connectés aux bus pouvant jouer le rôle d'appareil cible, lesdits moyens centralisés de contrôle permettant de contrôler les appareils cibles de chaque bus en utilisant une norme de contrôle propre au bus, lesdits io moyens centralisés de contrôle étant rendus accessibles aux appareils pouvant jouer le rôle de clients via un serveur sur la passerelle selon un protocole de communication standard caractérisée en ce que la méthode comporte au moins les étapes suivantes: une étape de transfert conditionnelle d'une application de 15 contrôle de l'appareil cible depuis la passerelle vers l'appareil client; une étape d'exécution de cette application de contrôle, lorsqu'elle est transférée, par l'appareil client, établissant un dialogue direct entre les deux appareils, client et cible, selon la norme de contrôle du bus auquel ils sont connectés. 2. Méthode selon la revendication 1 comprenant, pour un appareil client, une étape préalable d'envoi à la passerelle d'une information de profil indiquant sa capacité à exécuter une application de contrôle selon une norme donnée. 3. Méthode selon la revendication 2 comprenant, pour la passerelle, une étape de prise de décision du transfert d'une application de contrôle vers l'appareil client. 4. Méthode selon la revendication 3 où l'étape de prise de décision du transfert de l'application de contrôle est basée sur ladite information de 2859341 Il profil et la détection de la présence des deux appareils, client et cible, sur le même bus. 5. Méthode selon l'une des revendications 1 à 4 où l'application de 5 contrôle est une application JAVA. 6. Dispositif passerelle entre au moins un bus selon un premier protocole donné et au moins un second bus selon un second protocole, ladite passerelle offrant des moyens centralisés de contrôle des appareils io connectés aux bus pouvant jouer le rôle d'appareil cible, lesdits moyens centralisés de contrôle permettant de contrôler les appareils cibles de chaque bus en utilisant la norme de contrôle propre au bus, lesdits moyens centralisés de contrôle étant rendus accessibles aux appareils pouvant jouer le rôle de clients via un serveur sur la passerelle selon un protocole de communication standard caractérisée en ce que ladite passerelle comporte des moyens de transfert conditionnel d'une partie de ses moyens de contrôle vers un appareil client en vue d'une exécution sur cet appareil pour le contrôle d'un appareil cible. 7. Dispositif passerelle selon la revendication 6 comportant des moyens de prise de décision du transfert d'une application de contrôle vers l'appareil client. 8. Dispositif passerelle selon la revendication 7 où les moyens de 25 prise de décision du transfert de l'application de contrôle vers l'appareil client utilisent une information de profil de l'appareil client indiquant sa capacité à exécuter une application de contrôle. 9. Dispositif passerelle selon la revendication 7 ou 8 où les moyens de prise de décision du transfert de l'application de contrôle vers l'appareil client utilisent la détection de la présence des deux appareils, client et cible, sur le même bus. 10. Dispositif selon l'une des revendications 6 à 9 où l'application de contrôle est une application JAVA.