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 suivi d'Ines =====

Présents : Annie, Stéph, JY, Ines

==== Présentation des premières rédactions ==== 

Relire le texte en anglais qu'elle va nous envoyer ... 

==== Cadre Général : Une approche Middleware originale ==== 

=== Description ===
  * Chaque D (ou autre entité ? utilisateur ? autre ? à réfléchir ?) , vient avec ses N-Uplets : (SApp, D1, .. ,DN, ..., C1, ... , CN) (à réfléchir aussi)   

  * Sujet à clarifier : 
    * le modèle synchrone est un moyen de modéliser le comportement d'une entité, fut-elle logicielle, matériel et même physique (état de luminosité de la chambre) 
    * Si on gère plusieurs dispositifs il convient d'établir leur indépendance ou couplage. En effet deux dispositifs  apparemment indépendants peuvent être couplés par leur impact sur leur environnement (ex. deux lampes dans une pièce sont couplées. En effet si une lampe est éteinte rien ne garantie que l'autre ne soit allumée et donc que la pièce soit non éclairé. L'exemple pourrait être plus percutant)
    * Quelle Méthodologie pour décrire le système qui couple les dispositifs :  
    * 1- une description du Système avec une automate dans lequel on retrouve les dispositifs qui modélisent les dispositifs qui y sont intégrés ? 
    * 2 - une description du Système avec N automates (1 pour chaque dispositif). La dépendance entre les dispositifs se caractérise alors par des contraintes entre eux. Un système est donc isolé SSI les contraintes entre ses dispositifs ne mettent pas en œuvre d'autres dispositifs. Corollaire : Si des contraintes mettent en œuvre des dispositifs de systèmes différents alors il s'agit d'une seul et unique système. 
    * Il faudra bien expliquer l'hypothèse qu'une fois l'automate d'un système défini, ce système est bien isolé au sens des interactions avec les dispositifs d'un autre système. 

=== Référence  === 

The Things in the Internet of Things, Stephan Haller, SAR research Center Zurich,... 

==== Gestion des signaux valués ====

  * Pour éviter la séparation d'une logique basée sur des signaux purs d'une logique purement basée des data, les langages synchrones actuels permettent d'intégrer des signaux valués avec des expressions et des opérateurs booléen (ex i=12). 
  * Ces opérateurs sont souvent spécifiques à un type et donc fournis par défaut sur des types prédéfinis. 
  * L'utilisation d'autres types nécessite une spécification de ces types et des prédicats associés par l'utilisateur (ex. un type énumération, avec un opérateur d'appartenance d'un élément à cet ensemble)
  * En fait si on veut garder de la souplesse dans la chaine d'observation qui nous permettra de modifier "comment" le predicat est évalué alors il vaut mieux revenir au signaux purs en entrée de l'automate (résultats post évaluation / post prédicat). Exemple si je veux pouvoir remplacer un capteur de chute par SUP alors il ne faut pas intègrer pas le prédicat dans l'automate mais  prendre en entrée le signal pure "chute vrai/faux" pour pouvoir wrapper l'un des deux capteurs indifféremment.

==== Schéma de l'outil de design et génération de l'automate =====


{{:recherche:projets:syncomp:meetings:syncom.jpg?200|photo tableau}}

==== Roadmap : ====

  * Clarifier la notion de dispositif et Système Ambiant : Cf. papier ci-dessus
  * Générer dans un Bean un automate avec des signaux d'entrée et de sortie purs à partir de clem
  * L'automate sera celui du dispositif (ex. lampe) 
  * Ajouter des contraintes avec le langage DCL entre deux lampes d'une même pièce 
  * Ces deux lampes / dispositifs font alors parties d'un même système ambiant car couplés ( quelque soit l'état d'une lampe si l'autre est allumée la pièce est allumée). 
  * Calcul de la composition des automates des dispositifs du système pour modéliser les accès concurrent au système + les contraintes associées modélisée sous forme d'automate => model checking
  * Génération du bean de l'automate correspondant (par dispositif ? par système ?) avec événement d'entrée et de sortie pur.
  * Premier test de la chaine de conception / déploiement / exécution logicielle sous WComp ASAP pour se faire une idée des incréments nécessaires.