This is an old revision of the document!


Modification du Bilan :

  • Cf. les étoiles dans la présentation bilan corrigée (sur SVN et dans page précédente)

Exposé LudoTIC :

TODO plénière :

  • groupe de travail ce jour , LudoTIC, Suez environnement, Lyonnaise des eaux, I3S
  • valider les deux colonnes du tableau avant après des équipements du fontainier
  • valider le scénario de test utilisateur pour la version V1.bis

Planning pour les tests utilisateurs et résultats fin mai :

  • Prototype de preuve de faisabilité V1 (OK)
  • Groupe de Travail LudoTIC, Suez environnement, Lyonnaise des eaux, I3S : Fixer le scénario : navigation jusqu’au point d’intervention (suivi d'identification de la vanne … ) (Mars 2011 TODO plénière ci-dessus)
  • I3S : Spécification du prototype sur le terrain robuste V1.bis et validation du choix de la config présentée aux fontainiers (choix des snapshot au démonstration du prototype V1.bis ?) (mi-avril)
  • Décision Lyonnaise des eaux et Suez environnement : Les tests utilisateurs se feront comment ⇒ Quels utilisateurs pour tester en conséquence ?
  • LudoTIC : Tests utilisateurs avant (durée 3 semaines)
  • Deadline pour LudoTIC (au plus tard Mai 2011)
  • I3S : prise en compte des retours utilisateurs pour le prototype final V2 (deadline Septembre 2011)

Exposé LoginPeople :

  • Stratégie 1 : mise en place d’un Web service dispositifs suite à la validation de l’ADN numérique dont le composant proxy fait partie du pointcut de tous les AAs
  • Stratégie 2 : communication dans l’infrastructure entre Web Service ADN et les autres Web Services avant de les autoriser à apparaître.
  • Question : si le serveur LoginPeople est down ? LoginPeople a une solution.
  • TODO : Réunion I3S / LoginPeople (pb de l'utilisation des drivers pour récupérer l'ADN numérique) [Pb si modification dynamique du Weco pour tester en permanence l'ADN numérique sans passer par les drivers]

Exposé GemAlto :

  • Présentation du device Bluetooth - I2C + équipement ajouté boitier pour RFID (Pb emplacement)
  • Dispositif contient une boussole, deux boutons
  • un système de propriétaire (TUBE) de publication de services
  • donc développements supplémentaires = stratégie avec un bridge UPnP sur Weco
  • TODO :: intégration prototype physique (intégration pile Bluetooth) + RFID intégré + test RFID (février 2011)
  • TODO :: associer un rapport papier D5.1 pour mettre en avant une contribution innovante (scientifique?) (sur la base du document de demande de dépôt de brevet)
  • TODO :: prototype Clef en collaboration avec Suez Environnement et Lyonnaise des eaux

PERSPECTIVES par rapport aux remarques de l'ANR :

  • rajouter au mécanisme de RPC propriétaire (TUBE) une gestion de contrat dynamique (à la UPnP) qui pourrait être un plus brevetable (?)
  • le service UPnP associé pourrait alors récupérer tout aussi dynamiquement le contrat du device

Exposé I3S Prototype pour l'évaluation V2 (final) :

Résumé des TODOs :

  • TODO ::: réaliser le Dispositif Clef de vanne intégrant l'équipement GemAlto
  • TODO ::: Partie haute (au-dessus des AAs) de l'architecture
    • TODO ::: intégration complète de la BdC
    • TODO ::: intégration complète de la Meta IHM
    • TODO ::: intégration complète du gestionnaire de contexte
  • TODO ::: fournir les Web Services Métier au format UPnP ou WS (W3C)
  • TODO ::: intégration du Sécurité de LoginPeople

Planning intermédiaire :

  • Gemalto Fev : Dispositif GemAlto : Mars 2011
  • LoginPeople : Service Sécurité : (pas de deadline fixé par le document A : plutôt Avril 2011)
  • Suez Env : Services Métiers - Avril 2011
  • I3S - IIHM - HADAS : Architecture Soft au dessus Juin 2011

Attention : Prototype v2 pour la deuxième phase d'évaluation de LudoTIC (évaluation terrain) TODO :: Identifier les spécifications du prototype et réaliser le prototype pour mi-avril (version V1 bis)

Pause Repas :

12h30 - 14h

Exposé 5 : prototype architecture V0

  • Avancée du démonstrateur D4.3.2 IIHM (Emeric)
    • <observable (device source)> LINK <device sink>
    • LINK est influencé par l'action considérer (ex. écouter ou voir) en sélectionnant des catégories de devices source et devices sink reliés (LINK)
    • Cas (2) non abordé :
      • Quand l'action (ex. écouter) joue entre un device source destiné a priori à un device sink de différente catégorie (ex. ObservablePosition →(écouter) → DeviceAudio)
      • La génération de l'AA est alors moins triviale (plus Observable.port → DeviceSink.port)
      • PERSPECTIVE ::: Proposition de mise en place de toute une partie simulée en complément de la meta-ihm (en LPN, ou inconique), donc simulation du GdC et d'un environnement (infrastructure simulée) seconde life.
  • Evolution liée de la BdC HADAS (Anis)
    • TODO :: BdC à la capacité d'enrichir les meta-données des dispositifs (ex. localisation dans une chambre est équivalent à la localisation dans la maison)
    • TODO :: La BdC est capable de détecter un changement de contexte, le transmet au GdC qui sélectionne les AAs souhaités.
  • Evolution liée de WComp (meta-données et AA) Rainbow (Vincent)
    • TODO ::: Suite à la remarque d'Anis, le nom est une meta-donnée, on a donc plus qu'une liste de meta-données, il faut donc tolérer des filtres basés sur des expressions régulières sur cahqe meta-données + des opérateurs logiques entre.
    • TODO ::: rajouter les stratégies de sélection des jointputs (n parmi n, 1 parmi nb , …)

TODO :: rajouter à l'interface le What (Device Source ou observable), l'action et le Where (Device Sink) TODO :: doit-on et comment faire évoluer le traitement pour atteindre des cas 2

Exposé 6 AA et gestion du contexte dans le respect des 3 couches à partir de la grammaire du langage pseudo naturel (JY-Gaëtan)

TODO :: Clore le débat sur le GdC :un contexte est associé à un ensemble de prédicats , le nombre de noeuds (situations) correspond au nombre d'états possibles de l'ensemble des prédicats. Chaque situation est associée à une liste d'AA.

TODO :: Faire le travail du LPN vers la liste des prédicats en passant par la BdC (à préparer en équipe Rainbow)

TODO :: Corriger le papier AA structurel et AA Comportemental et envoyer à Grenoble

Exposé 7 : BdC

  • BdC connecté au niveau stratégique pour aligner les observables / device sink abstrait aux concrets
  • TODO :: BdC qui récupère les meta-data dynamiques des Devices (OK)
  • Enrichissement des metadonnées des devices par la BdC : NON (on subit l'infrastructure)
  • TODO :: relation BdC / niveau LPN (OK pour l'action, à faire pour la partie Contexte (matching condition contextuelle LPN vers prédicats) … Cf. travaux futurs)
  • Générer pointcut (après alignement) OK ?
  • TODO :: relation BdC / GdC

TODO ::: Echanges de mails pour clarifier les échanges BdC et reste de l'architecture

Suggestions

  • Publications et Workshops :
    • Workshop à IHM 2011 pour Continuum (Conférence du Lundi 24 octobre 2011 - Jeudi 27 octobre 2011)
      • a voir dans le cadre des Interactions Homme/Machine
    • Publications sur quoi, où et quand (?) :
  • Pour Jacques quels sont les retours à faire à l'ANR : Projets trop courts - trop peu d'infos retournées par l'ANR en cas de refus.
  • Ne pas oublier Demande de prolongement du projet sans incidence financière (Quand la déclencher ? 6 mois ? 12 mois ?)
  • Ne pas oublier les rapports financiers à T0+24
  • TODO ::: Incrémenter les papiers qui tournent (rapport Emeric-Anis-Vincent-Joelle)

Discussions : Deux groupes de travail

LudoTIC - I3S - Suez Environnement - Lyonnaise des eaux :

TODO ::: Fixer une date : doodle de Stéphane

I3S - IIHM - HADAS : Architecture Continuum

TODO ::: Fixer une date :

I3S - LoginPeople

TODO ::: Fixer une date Use Cases à partir desquels on a la liste des devices à mettre en œuvre