recherche:projets:syncomp:meetings:meeting130415
Ceci est une ancienne révision du document !
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/meeting130415.1428921513.txt.gz · Dernière modification : 2015/04/13 10:38 de tigli