JY Tigli Homepages

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
===== Meeting 270415 : préparation papier Middleware 2015 =====

=== Deadline Abstract : 13/05/15 === 

=== Deadline Paper : 20/05/15 === 

=== Plan du papier ===


== Modélisation d'un Système Ambiant ==


  * Mettre en évidence la différence entre Device and Things (Cf paper : The Things in the Internet of Things, Stéphane Haller, SAP Research Center Zurich)
  * Définition d'une Application Ambiante i : App_i, associée à un ensemble de Things et donc un ensemble de Devices  

  * Les App_i utilisent un ensemble de devices
  * Les App_i sont associées à des types d'App  
  * Les Devices sont associés à des types de Device (Noter ici, que la notion de Type peut laisser place à des mécanismes de gestion des connaissances basées sur des annotations et raisonnement sémantiques => mettre une ou plusieurs ref .... Cf. Sabine)

  * chaque couple (App_type, Device_type), fournit son lot de contraintes pour le Thing 

  * Illustration : appartement = ensemble de Things, pièce = une Thing, sources lumineuses + autre devices = devices, et application = (ambiance cocoon, ambiance grande lumière, ambiance lumière du jour ...) 


== La composition est gérée grâce au modèles associés au  Thing et ensemble des Types des Devices utilisés ==


  * APPROCHE : Modélisation globale :
    * Modélisation comportementale synchrone des devices : les entrées sont les "actions" possibles sur le Device par les Apps 
    * Chaque device a un Type associé. 
    * Chaque App a un Type associé. 
    * Chaque couple (Type App , Type Device) sont utilisés dans l'expression des contraintes (Cf plus loin). 

    * Les états du Thing sont l'ensemble des états de l'ensemble des devices (produits des automates).La modélisation d'un Thing correspond donc au produit des automates de ses devices. 


  * CONTRIBUTION : Les contraintes sont exprimées avec un langage dont les propriété sont :
    * ne nécessitant pas la connaissance des App_i et Device_j mis en oeuvre à un instant donné 
    * mais, l'ensemble des App_i et Device_j qui pourraient être mises en oeuvre au travers les Types a priori connus.
    * Les contraintes sont in fine, pour chaque Type d'App et Device un ensemble des états du Thing désirés.


  * Illustration : 
    * DESCRIPTION sur le thème confort de vie 
    * Système Ambiant : Appartement  
    * Thing : Séjour 
    * Devices : Lampe_du_salon, Lampe_au_dessus_de_table_du_séjour, Ouverture_Fenêtre (actionneur), Capteur_luminosité_extérieure, Capteur_de_présence ... 
    * Type de App_i : App_grande_luminosité, App_cocoon, App_lumière_du_jour ... 

  * ETAPE 1 : Les automates de Devices (à dessiner sous galaxy) :
    * Une lampe classique (lampe_table) : switch_on, switch_off en entrée is_on, is_off en sortie (automate 1 état)
    * Une lampe impulsionnielle (lampe_salon) : switch en entrée, is_on et is_off  en sortie (automate 2 états) (ne pas oublier un capteur de luminosité à proximité de la lampe impulsionelle) 
    * ...
  * ETAPE 2 : listes des contraintes associées aux (Types d'App, Types de device)

  * PRODUCTION : 
    * Model checking (voir ce que l'on peut valider au niveau statique, ...) 
    * Montrer l'incrémentalité du mécanisme de composition :
      * Ajout de Device sur un Thing 
      * Retrait de Device sur un Thing 
      * Ajout d'App_i 
      * Retrait d'App_i  






== Illustration : ==

Illustrer par une étude d'un accès concurrent à une Thing au travers une ensemble de devices. 

Exemple : Luminaires dans un appartement 
les things sont alors des pièces de l'appartement 
l'utilisation dans luminaires est couplée dans une même pièce. 

== Conclusion et Perspectives ==

=== Questions ouvertes : === 

  * jusqu'où aller pour démontrer la contribution dans les papier type de la conf Middleware (pour la dernière partie du papier) 
  * La notion de Type sur les App_i peut laisser place à des mécanismes de gestion des connaissances basées sur des annotations et raisonnement sémantiques => mettre une ou plusieurs ref .... Cf. Sabine) 
  * Voir plus précisément comment passer dynamiquement le Type d'App_i au Device, à l'exécution ... 

=== Copie Tableau ===

{{:recherche:projets:syncomp:meetings:copie_board_270415_syncomp.jpg?700|Copie Tableau}}
JY Tigli Homepages

Outils pour utilisateurs

Outils du site

Outils de la page
