Brevet FR2930108A1 — publié le 20091016

Système et procédé de communication distribué et modulaire comprenant au moins un serveur, au moins un terminal distant, et au moins un terminal mobile capable de communiquer avec le terminal distant relié en réseau audit serveur L'invention porte sur un système et un procédé de communication distribué et modulaire comprenant au moins un serveur, au moins un terminal distant, et au moins un terminal mobile capable de communiquer avec le terminal distant relié en réseau audit serveur. II existe des architectures distribuées et modulaires par exemple basées sur un logiciel d'intercommunication tel qu'URBI. Les architectures existantes ne permettent cependant pas d'avoir des applications logicielles de connexion et d'appel de fonction, appelées "proxies" en langue anglaise, capables de déterminer automatiquement quel type de connexion utiliser ~o parmi une pluralité de connexions possibles, telles des connexions locales ou à distance. En outre, un logiciel d'intercommunication tel qu'URBI ou MSRS ne permet d'appeler à distance uniquement des fonctions écrites dans leur langage respectif URBI ou MSRS, ce qui implique un manque de flexibilité de 15 telles architectures. Un but de l'invention est de proposer une architecture qui résout les problèmes mentionnés ci-avant. Selon un aspect de l'invention, il est proposé un système de communication distribué et modulaire comprenant au moins un serveur, au 20 moins un terminal distant, et au moins un terminal mobile capable de communiquer avec le terminal distant relié en réseau audit serveur. Le serveur, le terminal fixe et le terminal mobile comprennent respectivement au moins un moyen de mise en relation dédié à au moins un module comprenant au moins une série d'instructions mettant en oeuvre une fonction 25 logicielle par exécution par un processeur. Un module comprenant une série d'instructions mettant en oeuvre une fonction logicielle nécessitant un appel à une autre série d'instructions mettant en oeuvre une fonction logicielle d'un autre module, comprend un moyen d'interface de connexion et d'appel de fonction adapté pour sélectionner automatiquement, parmi un ensemble prédéterminé de types de connexion, le type de connexion adapté à la localisation sur le réseau de communication du module comprenant la fonction appelée. Un tel système permet de choisir automatiquement le type de connexion à utiliser en fonction de la localisation sur le réseau de la fonction appelée. Ainsi, ce paramétrage est effectué sans intervention de l'utilisateur du terminal distant, et de manière optimisé. On a alors un logiciel réparti sur le réseau. Dans un mode de réalisation, ledit moyen d'interface de connexion et d'appel de fonction est adapté pour faire une requête au moyen de mise en relation du module appelant pour connaître la localisation sur le réseau du module comprenant la fonction appelée. Le moyen d'interface de connexion et d'appel peut ainsi connaître automatiquement sur quel terminal ou serveur du réseau la fonction appelée est située, et même dans quel module de quel moyen de mise en relation. Selon un mode de réalisation, un moyen de mise en relation est adapté pour transmettre à des rnoyens de mise en relation enfants une requête de localisation d'une fonction sur le réseau reçu d'un moyen de mise en relation parent. Ainsi, les moyens de mise en relation se transmettent des informations perrnettant de localiser une fonction appelée par une autre 25 fonction. Dans un mode de réalisation, un moyen de mise en relation comprend une suite d'instructions mémorisées exécutables par un processeur pour déterminer un ensemble de paramètres caractéristiques d'un de ses modules. 30 Un moyen de mise en relation peut donc exécuter une fonction fournissant un ensemble détaillé d'informations concernant ses modules, et ainsi retourner un ensemble détaillé d'informations concernant la fonction appelée. Par exemple, ledit ensemble de paramètres comprend les noms des fonctions du module, et/ou les paramètres d'appel des fonctions du module, et/ou l'adresse ip du moyen de mise en relation lié au module distant contenant la fonction à appeler, et/ou le numéro de port moyen de mise en relation lié audit module, le type du système d'exploitation utilisé par le terminal ou la plateforme serveur comprenant ledit module, et/ou le langage informatique dudit module, et/ou l'identifiant du processus du moyen de mise en relation dudit module, et/ou des options de sécurité, et/ou le type de connexion à utiliser. Selon un mode de réalisation, le système comprend, en outre, des moyens de mémorisation et de gestion de paramètres représentatifs de l'état du terminal mobile, adaptés pour mettre à jour les valeurs desdits paramètres sur réception d'un événement externe, et pour informer un module, sur demande préalable, d'une mise à jour d'un desdits paramètre mémorisé. Il est ainsi possible d'avoir à tout instant une représentation de l'état du terminal mobile, et sur demande, d'informer certaines fonctions de modifications de valeurs de certains paramètres, qui pourront en fonction des évolutions de ces paramètres déterminer des actions à faire. En outre, lesdits moyens de mémorisation et de gestion sont adaptés pour mérnoriser des valeurs successives de certains paramètres pendant un délai de référence. Ainsi un module peut avoir accès à l'évolution de certains paramètres sur un intervalle de temps prédéterminé. Dans un mode de réalisation, ledit terminal mobile est un robot humanoïde. Un robot peut être qualifié d'humanoïde lorsqu'il possède certains 30 attributs de l'apparence humaine tels qu'une tête, un tronc, deux bras, deux jambes, deux pieds et deux mains. Selon un mode de réalisation, un moyen d'interface de connexion et d'appel de fonction est adapté pour utiliser un logiciel d'intercommunication capable d'appeler une fonction d'un module localisé sur un terminal ou serveur différent, ladite fonction étant mise en oeuvre par exécution sur un processeur d'une suite d'instructions écrites en un langage informatique choisi parmi une pluralité de langages informatiques. Par exemple, ledit logiciel d'intercommunication est SOAP, CORBA, XML-RPC ou ICE. De tels logiciels d'intercommunication permettent des 10 communications distantes multi-plateformes et multi-langages. Selon un autre aspect de l'invention, il est également proposé un procédé de communication entre au moins un serveur, au moins un terminal distant, et au moins un terminal mobile capable de communiquer avec le terminal distant relié en réseau audit serveur, dans lequel une fonction d'un 15 module de fonctions utilise un moyen d'interface de connexion et d'appel de fonction pour appeler une fonction d'un module de fonctions localisé sur un terminal ou serveur différent. Dans un mode de mise en oeuvre, lors de ladite utilisation d'interface de connexion et d'appel de fonction, on effectue une requête au 20 moyen de mise en relation du module appelant pour connaître la localisation sur le réseau du module comprenant la fonction appelée. Selon un mode de mise en oeuvre, on mémorise et on gère des paramètres représentatifs de l'état du terminal mobile, adaptés pour mettre à jour les valeurs desdits paramètres sur réception d'un événement externe, et 25 pour informer un module, sur demande préalable, d'une mise à jour d'un desdits paramètres mémorisés. Dans un mode de mise en oeuvre, ledit terminal distant est un robot humanoïde. Dans la suite de la description, le terminal mobile est un robot 3o humanoïde, mais l'application s'applique à tout autre terminal distant tel un téléphone portable ou un ordinateur portable. L'invention sera mieux comprise à l'étude de quelques modes de réalisation décrits à titre d'exemples nullement limitatifs et illustrés par le dessin annexé sur lequel la figure illustre schématiquement un système selon un aspect de l'invention, et son procédé de fonctionnement. Sur la figure est représenté très schématiquement un premier robot humanoïde RH1 communiquant avec un premier terminal distant TD1, par exemple par liaison sans fil pour des raisons de mobilité. On entend par terminal distant un terminal distant de la plate-forme serveur PFS, fournissant, par l'intermédiaire d'un réseau de communication, l'accès à un service web SW, dédié à ce type de robot humanoïde RH1. Bien entendu, les liaisons de communication entre éléments du système peuvent être filaires, et les terminaux mobiles peuvent être, en variante, des téléphones portables ou des ordinateurs portables. Un deuxième robot humanoïde RH2 communique avec un deuxième terminal distant TD2, pal- exemple également par liaison sans fil de manière à ne pas entraver la mobilité du robot humanoïde RH2. Les terminaux distants TD1 et TD2 et la plateforme serveur PFS sont reliés en réseau par l'intermédiaire du réseau de communication RC. Pour le service web de la plateforme serveur PFS ainsi que pour les terminaux distants TD1 et TD2, e1: que pour les robots humanoïdes RH1 et RH2, un seul module respectif de mise en relation B5, B2, B4, BI et B3 dédié à au moins un module comprenant au moins une série d'instructions mettant en oeuvre une fonction logicielle par exécution par un processeur. Les modules respectifs M51, M52, M21, M22, M41, M42, M11, M12, M31, M32 des modules de mise en relation B5, B2, B4, BI et B3 sont sur cet exemple représentés au nombre de deux par module de mise en relation, mais ce nombre peut être différent et quelconque pour chaque module de mise en relation. Nous allons maintenant illustrer un exemple nullement limitatif de fonctionnement du système imaginé par un utilisateur du premier terminal distant TD1 possédant le premier robot humanoïde RH1. Il peut, par exemple, au moyen d'une application logicielle embarquée sur le premier terminal distant TD1, ou accessible sur la plateforme serveur PFS depuis le premier terminal distant TD1, telle que décrit dans les demandes de brevets français FR 100420 et FR 102017 Par exemple il réalise simplement, aux moyens d'outils graphique de 'application logicielle, une application pour son robot, dans laquelle le robot va marcher pendant 10 secondes puis dire "Bonjour à tous". Cette application est par exemple téléchargée dans le premier robot humanoïde RH1 sous forme d'un module, par exemple le module M11, puis déclenchée par l'utilisateur par l'intermédiaire du premier terminal distant TD1. Le premier robot humanoïde RH1 déclenche le module M11 qui doit utiliser en premier une fonction "Marche". Le module M11 utilise alors un module d'interface de connexion et d'appel de fonction ou proxy P1 qui effectue une requête au module de mise en relation BI auquel est lié le module M11. Le module de mise en relation BI effectue des requêtes à destination de ses propres modules et des modules de mise en relation du réseau auquel il est directement relié (modules de mise en relation enfants) qui répètent cette opération de manière itérative, jusqu'à ce qu'un module de mise en relation du réseau réponde à la requête avec la localisation de la fonction appelée qu'il a dans un module. La réponse à la requête étant également transmise de manière itérative par les modules de mise en relation parents (en sens inverse) jusqu'au module de mise en relation BI directement lié au proxy P1 ayant besoin de se connecter et d'appeler cette fonction. Par exemple, la fonction demandée pour la marche est localisée dans le module M41 du deuxième terminal distant TD2. En retour le module de mise en relation B4 a retourné les paramètres d'appels de la fonction "marche", qui, par exemple, contiennent un paramètre Durée de type entier en secondes représentant la durée pendant laquelle le robot va marcher, et un paramètre Exclusif, de type booléen, représentant la marche exclusive ou non du robot, i.e. si on autorise Ile robot à faire une autre action ou non pendant qu'il marche. Dans cet exemple, on appelle la fonction marche avec le paramètre Durée valant 10 et le paramètre Exclusif valant 1, car on veut qu'il parle après avoir marché 10 seconde dans cet exemple. Le module d'interface de connexion et d'appel P1 peut donc effectuer la connexion et l'appel de la fonction "marche" avec les paramètres souhaités, à distance, comme si elle était située en local. Les modules d'interface de connexion et d'appels de fonction utilisent un logiciel d'intercommunication capable d'appeler une fonction d'un module localisé sur un terminal ou serveur différent, la fonction pouvant être écrite par une série d'instruction dans un langage informatique différent de celui du module appelant. Les proxies utilisent, pais exemple, le logiciel d'intercommunication SOAP. On a donc une architecture de communication inter-plateformes et inter-langages. Une fois cette fonction délocalisée "marche" effectuée, le module M11 doit faire appel à une fonction "parle". Un autre module d'interface de connexion et d'appel de fonction ou proxy P2 effectue une requête au module de mise en relation BI auquel est lié le module M11. Le module de mise en relation B1 effectue une requête à destination de ses propres modules M11 et M12 dans un premier temps, par l'intermédiaire d'une fonction réalisée sous la forme d'une suite d'instructions mémorisées, qui va, par exemple, retourner la présence de cette fonction "parle" dans le module M12. Le module de mise en relation BI informe le module d'interface de connexion et d'appel de fonction P2 qui peut alors appeler directement, par un appel de type appel local la fonction "parle" du module M12, avec comme paramètre, par exemple, le texte à dire "bonjour", ce paramètre ayant été transmis au proxy P2 par le module de mise en relation B1. En outre, le système comprend un module de mémorisation et de gestion STM (dirninutif de "Short Term Memory" en langue anglaise) de paramètres représentatifs de l'état du terminal mobile, en l'occurrence du robot humanoïde RH1, adaptés pour mettre à jour les valeurs desdits paramètres sur réception d'un événement externe, et pour informer un module, sur demande préalable, d'une mise à jour d'un desdits paramètre mémorisé. Aussi le module prévenu pourra engager une action en fonction des modifications de paramètres dont il a été informé. En relation avec l'exemple préalablement décrit, par exemple, le module de mémorisation et de gestion STM peut mémoriser l'état d'un paramètre représentatif de l'apparition de quelqu'un détecté par un détecteur de mouvement du robot RH1. Lorsque ce paramètre passe d'un état représentatif de personne dans l'environnement immédiat du robot à un état représentatif de quelqu'un présent dans l'environnement immédiat du robot, sur demande effectuée préalablement par le module M11, le module de mémorisation et de gestion STM prévient, par un événement ou signal ce changement de valeur. Le module M11 peut, alors par exemple, déclencher automatiquement le déclenchement successif décrit précédemment (les fonctions "marche" et "parle"). Dans l'exemple de la figure 1, le module de mémorisation et de gestion STM fait partie du terminal distant TD1, mais, en variante, il peut faire partie de l'autre terminal distant TD2, de la plate-forme serveur PFS, ou d'un robot humanoïde RH1 ou RH2. Le module de mémorisation et de gestion STM est également capable de stocker en mémoire une évolution temporelle de certains paramètres sur des intervalles de 1:emps respectifs de référence. Ainsi, un module du système peut, en outre, avoir accès à l'évolution des valeurs de ces paramètres depuis une certaine durée, et tenir compte de ces évolutions dans les actions à mener. En variante, les modules des fonctions appelées peuvent être localisée sur la plate-forme serveur PGS, sur un robot humanoïde RH1, RH2 ou sur un terminal distant TD1, TD2 du réseau de communication RC. Ainsi, la présente invention permet d'avoir un programme réparti sur le réseau, et un fonctionnement identique du terminal mobile, qu'il fasse un appel local ou distant à une fonction. En outre, la présente invention permet également d'avoir un ensemble de paramètres mémorisés représentatifs de l'état du terminal mobile, et de pouvoir tenir compte d'évolutions de cet état pour déclencher automatiquement certaines actions. De surcroît, le module de mémorisation et de gestion peut également enregistrer une évolution de valeurs de paramètres durant un intervalle de temps prédéterminé, ce qui permet à un module d'avoir accès à un historique de l'évolution de ces paramètres. REVENDICATIONS1. Système de communication distribué et modulaire comprenant au moins un serveur (PFS), au moins un terminal distant (TD1, TD2), et au moins un terminal mobile (RH1, RH2) capable de communiquer avec le terminal distant (TD1, TD2) relié en réseau (RC) audit serveur (PFS), caractérisé en ce que : le serveur (PFS), le terminal fixe (TD1) et le terminal mobile (RH1) comprennent respectivement au moins un moyen de mise en relation (B1, B2, B5) dédié à au moins un module (M11, M12, M21, M22, M51, M52) comprenant au moins une série d'instructions mettant en oeuvre une fonction logicielle par exécution par un processeur; et un module (M11) comprenant une série d'instructions mettant en oeuvre une fonction logicielle nécessitant un appel à une autre série d'instructions mettant en oeuvre une fonction logicielle d'un autre module (M41, M12), comprend un moyen d'interface de connexion et d'appel de fonction (P1, P2) adapté pour sélectionner automatiquement, parmi un ensemble prédéterminé de types de connexion, le type de connexion adapté à la localisation sur le réseau de communication (RC) du module (M41, M12) comprenant la fonction appelée. 2. Système selon la revendication 1, dans lequel ledit moyen d'interface de connexion et d'appel de fonction (P1, P2) est adapté pour faire une requête au moyen de mise en relation (B1) du module appelant (M11) pour connaître la localisation sur le réseau (RC) du module comprenant la fonction appelée. 3. Système selon l'une des revendications précédentes, dans lequel un moyen de mise en relation (E31, B2, B3, B4, B5) est adapté pour transmettre à des moyens de mise en relation enfants une requête delocalisation d'une fonction sur le réseau (RC) reçu d'un moyen de mise en relation parent. 4. Système selon l'une des revendications précédentes, dans lequel un moyen de mise en relation (B1, B2, B3, B4, B5) comprend une suite d'instructions mémorisées exécutables par un processeur pour déterminer un ensemble de paramètres caractéristiques d'un de ses modules (M11, M12, M21, M22, M31, M32, M41, M42, M51, M52). 5. Système selon la revendication 4, dans laquelle ledit ensemble de paramètres comprend les noms des fonctions du module (M11, M12, M21, M22, M31, M32, M41, M42, M51, M52), et/ou les paramètres d'appel des fonctions du module, et/ou l'adresse ip du moyen de mise en relation (B1, B2, B3, B4, B5) lié au module distant contenant la fonction à appeler, et/ou le numéro de port moyen de mise en relation lié audit module, le type du système d'exploitation utilisé par le terminal (TD1, TD2, RH1, RH2) ou la plateforme serveur (PFS) comprenant ledit module, et/ou le langage informatique dudit module, et/ou l'identifiant du processus du moyen de mise en relation dudit module, et/ou des options de sécurité, et/ou le type de connexion à utiliser. 6. Système selon l'une des revendications précédentes, comprenant, en outre, des moyens de mémorisation et de gestion (STM) de paramètres représentatifs de l'état du terminal mobile (RH1), adaptés pour mettre à jour les valeurs desdits paramètres sur réception d'un événement externe, et pour informer un module (M11), sur demande préalable, d'une mise à jour d'un desdits paramètre mémorisé. 7. Système selon la revendication 6, dans lequel lesdits moyens de 30 mémorisation et de gestion (STM) sont adaptés pour mémoriser des valeurs successives de certains paramètres pendant un délai de référence. 8. Système selon l'une des; revendications précédentes, dans lequel ledit terminal mobile est un robot humanoïde (RH1, RH2). 9. Système selon l'une des revendications précédentes, dans lequel un moyen d'interface de connexion et d'appel de fonction (P1, P2) est adapté pour utiliser un logiciel d'intercommunication capable d'appeler une fonction d'un module (M41) localisé sur un terminal ou serveur différent, ladite fonction étant mise en oeuvre par exécution sur un processeur d'une suite d'instructions écrites en un langage informatique choisi parmi une pluralité de langages informatiques. 10. Système selon la revendication 9, dans lequel ledit logiciel d'intercommunication est SOAP, CORBA, ou ICE. 11. Procédé de communication entre au moins un serveur (PFS), au moins un terminal distant (TD1, TD2), et au moins un terminal mobile (RH1, RH2) capable de communiquer avec le terminal distant (TD1, TD2) relié en réseau (RC) audit serveur (PFS), caractérisé en ce qu'une fonction d'un module de fonctions utilise un moyen d'interface de connexion et d'appel de fonction (P1, P2) pour appeler une fonction d'un module de fonctions localisé sur un terminal ou serveur différent. 12. Procédé selon la revendication 11, dans lequel, lors de ladite utilisation d'interface de connexion et d'appel de fonction (P1, P2), on effectue une requête au moyen de mise en relation (B1) du module appelant (M11) pour connaître la localisation sur le réseau (RC) du module comprenant la fonction appelée. 13. Procédé selon la revendication 11 ou 12, dans lequel on mémorise et on gère des paramètres représentatifs de l'état du terminalmobile (RH1), adaptés pour mettre à jour les valeurs desdits paramètres sur réception d'un événement externe, et pour informer un module (M11), sur demande préalable, d'une mise à jour d'un desdits paramètres mémorisés. 14. Procédé selon l'une des revendications 11 à 13, dans lequel ledit terminal distant est un robot humanoïde (RH1, RH2).