Outils pour utilisateurs

Outils du site


recherche:projets:syncomp:meetings:meeting270415

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision
Révision précédente
recherche:projets:syncomp:meetings:meeting270415 [2015/04/27 11:12]
tigli
recherche:projets:syncomp:meetings:meeting270415 [2015/04/27 13:00] (Version actuelle)
tigli
Ligne 13: Ligne 13:
   * 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)   * 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  ​   * Définition d'une Application Ambiante i : App_i, associée à un ensemble de Things et donc un ensemble de Devices  ​
-  ​Définition ​de Thing et Propriétés ​des Devices ​attachés ​à une Thing  ​à mettre ​en évidence ​+ 
 +  ​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 ...)    * 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 ...) 
  
  
-== Modélisation ​Synchrone ​d'un Système Ambiant ​==+== 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 ​  
 + 
  
-  * Modélisation comportementale synchrone des devices ​ 
-  * Modélisation d'un Thing comme un ensemble de contraintes d'​interaction,​ sous hypothèse synchrone, entre devices 
-  * Les App_i sont associées à un type. (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) 
  
  
Ligne 39: Ligne 81:
   * jusqu'​où aller pour démontrer la contribution dans les papier type de la conf Middleware (pour la dernière partie du papier) ​   * 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) ​   * 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}}
  
recherche/projets/syncomp/meetings/meeting270415.1430125968.txt.gz · Dernière modification: 2015/04/27 11:12 par tigli