WWWoT (Wiki Wiki WoT)

carac

Anonymous (anonymous@undisclosed.example.com) — 2011-04-22T14:42:45+00:00

Caractérisation des protocoles de communication

A TERMINER

Bien que les réseaux de l'Internet repose exclusivement sur le protocole IP et qu'une grande majorité des  applications s'appuient sur le protocole TCP (réf?), il existe dans la littérature, des protocoles de communication pour tous les critères d'exigence qu'une application communicante puisse souhaiter.

Internet tel qu'il a été conçu il y a bientôt 30 ans permet aujourd'hui encore de supporter un grand nombre d'applications (ex: transfert de fichier fiable, téléphonie, visioconférence, jeux en ligne, etc). Chacune de ces applications ont des exigences particulières en terme de performance et de tolérance aux critères inhérent aux réseaux de transport de données (ex: Débit, délai, taux de perte, taux d'erreurs, gigue, …). Aujourd'hui il est nécessaire d'adapter les protocoles de transport de données pour mieux exploiter les caractéristiques du réseaux physique actuels, mieux répondre aux exigences des applications et mieux s'adapter a un contexte de transport susceptible d'évoluer au cours du temps (mobile ou réseaux hétérogènes).

Dans le cadre de ce projet, nous souhaiterions que le choix du mode de transmission (canal et protocole) entre l'agent et l'objet soit sélectionné de façon autonome par le système. Ces choix seront fait en fonction des critères d'exigences de l'application et de la disponibilité des technologies de communication disponible. Ce choix ne sera pas définitif. On autorise le passage d'un mode de transmission à un autre, en fonction de l'évolution de l'environnement ou des services disponibles en cours de fonctionnement.

— Jean-Patrick Gelas 2011/04/22 14:41

cr_18_avril_2011

Anonymous (anonymous@undisclosed.example.com) — 2011-04-22T14:21:28+00:00

Réunion du 18 avril 2011

Participants : JP Gelas, L. Médini, M. Mrissa

Excusé : JP Jamont

Discussion sur les problématiques de chacun

JPG : choix des protocoles de haut niveau (niveau transport, mais a priori, on resterait sur de l'IP). Il s'agit de choisir à la volée le protocole le plus adapté à une situation donnée (types de données à transférer¹⁾, environnement²⁾, qualité de service…).

MM : monitoring des échanges de données (récupération de données sur les échanges, l'environnement, la QoS) ; adaptation de la SOA au multi-protocole. Notion de service adaptatif (protocol switching).

LM : moteur d'adaptation sémantique à partir de “connaissances contextuelles” (informations + sémantique) issues de différentes sources (agent : tâche ; objet : ressources et contexte spécifique de l'objet ; environnement : contexte plus général) ; application de règles utilisant les connaissances issues du service de monitoring ; certaines règles d'adaptation pourront être distribuées pour être traitées à la source de la donnée (objet ou avatar) et seule la “connaissance utile” est envoyée au moteur d'adaptation.

* JPJ : à faire…

Discussion sur l'architecture et sur la communication entre l'avatar et l'objet

Choix d'architecture : le moteur d'adaptation peut être centralisé (une instance pour tous les couples avatar ; objet)) ; dans ce cas, l'architecture est de type ESB. À l'inverse, une instance de moteur peut être définie pour chaque couple : plus proche du P2P. De façon à avoir une architecture plus flexible, on s'orienterait plutôt vers la seconde alternative.

Cette solution permettrait de “distribuer” le moteur d'adaptation avec un traitement local des règles concernant les données recueillies par l'objet et un envoi des résultats de ces traitements à l'avatar pour ne faire circuler entre l'objet et l'avatar que les informations intéressantes au regard de la situation courante.

Il faut donc définir un moyen de transmettre les règles, les connaissances d'adaptation, [éventuellement le code de traitement de ces connaissances,] les commandes de [négociation et de] changement de protocole, et l'“acknowledgement”. Au final, il s'agit donc de déterminer un protocole d'échange de connaissances d'adaptation et de contrôle du protocole de communication entre avatar et objet.

Figure 1. détail d'une architecture de communication entre avatar et objet discutée le 18 avril 2011.

¹⁾

contrôle, vidéo…

²⁾

alimentation disponible

innorobo

Anonymous (anonymous@undisclosed.example.com) — 2014-03-10T11:03:50+00:00

Réunion de préparation Innorobo

Date : 10 mars 2014 Participants : L. Médini, M. Mrissa, A. Boukhlif, H.M. Diallo, R. Desmargez, J. Martin, J. Taws.

Objectif de la réunion

Préparer la/les démonstrations Innorobo.

Décisions

On fait deux démos :

Jordan + Jonathan : Démo de fonctionnalité identique pour deux robots (NXT, EV3), communication en BT, serveur Jetty + Websockets. Interface : une partie contrôle et une partie visualisation (canvas).
Alexandre + Hady + Rémy : Découverte et invocation de fonctionnalités. La pf et l'avatar tourneront sur la même machine.

Déroulement

Alexandre, Hady et Rémy reprennent l'interface client + le serveur en WebSockets de Jordan et Jonathan.

Dates des démos (à confirmer)

Mercredi 19 (avant 15h), jeudi 20 à partir de 10h.

jean-patrick_gelas

Anonymous (anonymous@undisclosed.example.com) — 2011-04-22T14:39:16+00:00

Pour me contacter :

email : jpgelas@ens-lyon.fr
Ph (ENS) : 04 7272 8228
Ph (UCB) : 04 2623 4451
Mobile : 06 80 48 86 93

Liens vers mes contributions sur ce Wiki :

— Jean-Patrick Gelas 2011/04/22 14:29

projet_v0

Anonymous (anonymous@undisclosed.example.com) — 2011-04-18T14:32:06+00:00

Discussions projet WoT des 4 et 5 avril 2011

Ce document relate les différentes discussions entre Lionel Médini (rédacteur) et Jean-Patrick Gelas, Michaël Mrissa puis Jean-Pierre Jamont entre le 4 et le 5 avril. L’objectif est de proposer un projet concret sur une application robotique en lien avec le WoT. Même si toutes les problématiques de recherche n’y sont pas présentes, c’est déjà un point de départ pour afficher une activité sur le WoT.

But du projet

Genèse

On est partis de la possibilité de caractériser des protocoles en fonction d’éléments de contexte pour mettre en place un service Web de monitoring des communications entre un objet et son avatar (cf. CR de la réunion du 15 novembre 2011)³⁾.

Problématique

Si l’objet correspondant à un avatar est suffisamment polyvalent, il peut accomplir plusieurs tâches. Pour chacune d’elles, un protocole sera plus adapté qu’un autre. Pourtant, plusieurs protocoles peuvent être éventuellement employés pour cette communication. Il est donc important de sélectionner le protocole de communication le plus pertinent pour une communication donnée et en fonction du contexte (état de l’objet, bande passante, importance pour l’avatar…).

Proposition

Afin de permettre à chacun de nous de traiter une problématique qui l’intéresse, nous proposons l’architecture illustrée ci-dessous. Elle intègre la communication réseau entre un objet (« O ») et son avatar (« A ») à l’aide d’un des protocoles pertinents implémentés par ces deux éléments. Le choix du protocole est réalisé par un « gestionnaire de protocole » fournissant un service de monitoring de l’objet à son avatar. Ce service est contextualisé à l’aide d’un moteur d’adaptation prenant en compte une description sémantique du contexte (« situation »), et appliquant des règles d’adaptation.

Figure 1. schéma approximatif d'une architecture qui contenterait tout le monde...

Compétences des différents intervenants académiques

JP. Gelas : caractérisation des protocoles de communication en fonction de paramètres + modification des protocoles de communication à la volée ?
JP. Jamont : multi-agents et agents conversationnels (la couche « cloud ») + simulation hybride logiciel-matériel (les autres agents sont simulés dans un premier temps)
M. Mrissa : [architectures orientées] services et service de monitoring + partage de service entre les agents et le provider de protocoles ?
L. Médini : adaptation sémantique au contexte + règles d’adaptation en fonction des situations contextuelles

Modus operandi

On se met d’accord sur le contenu de la proposition (ce document)
On rédige quelque chose d’un peu plus précis que ce document :
- biblio et problématique scientifique pour chacun de nous
- scénario
On contacte une boîte qui fait des robots qui pourraient convenir à cette proposition ; contacts suite au salon innorobo :
- Robopolis (www.robopolis.com) : sparx
- POB (http://www.pob-technology.com/)
On rédige une réponse pour l’appel à projets Région (si ça se confirme) pour l’été

A faire

En attendant, chacun de nous envoie une réf. sur ce sur quoi il travaille en rapport avec ce projet, pour que les autres en aient une vision plus précise.

³⁾

Les avatars sont dans le cloud et discutent entre eux. Ils se fournissent mutuellement des services à travers les objets qu’ils représentent.

start

Anonymous (anonymous@undisclosed.example.com) — 2013-04-22T15:18:26+00:00

Page principale du projet WoT du LIRIS / Homepage of the LIRIS WoT project

Membres du projet / Project members

Lionel Médini (LIRIS/UCBL)
Michael Mrissa (LIRIS/UCBL)
Jean-Paul Jamont (LCIS/INP)
Jean-Patrick Gelas (LIP/UCBL)

Description du projet / Project description

En construction / More about the WoT project very soon…

Documents (in French)

Présentation faite à Imaginove pour la labellisation du projet ANR ASAWoO (29/01/2013)
Présentation faite au workshop ROS d'Innorobo 2013 (21/03/2013)
Vidéo de présentation des résultats du projet de recherche de Thibaud Houel et Tanguy Raynaud-Gallonet (étudiants de master informatique de Lyon 1), à Innorobo 2013 (21/03/2013)
Présentation faite aux journées SEmba 2013 (04/04/2013)