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.
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 …