Outils pour utilisateurs

Outils du site


Panneau latéral

Accueil

Select other language :


Apprentissage

Enseignements

Enseignements Département Informatique SI5 et Master IFI

Enseignements Département Bâtiment Polytech'Nice

Autres Formations française et étrangère

Activités administratives, Ingénierie et Innovation Pédagogiques

Apprentissage Département Informatique SI5/Master 2 ingénierie informatique EUR DS4H


Recherche

Valorisation de la Recherche

Dépôts Logiciels à l’Agence de Protection des Programme (APP)

Valorisation des résultats de recherche et transfert

Diffusion de la Culture scientifique et Technologique

Communications de presse

Séminaire ENSI Tunis

Pédagogie Innovante

Relations industrielles et socio-économique

Organisation de Manifestations

  • Conférence sur les FabLabs, Alexandre Schneider, Professeur Agrégé en Génie Mécanique, Université de Reims Champagne-Ardenne Web
  • Journées UbiMob'14 Site Web

Animation de la Recherche

U-Santé

Privé

Outils

Sources d'Informations

recherche:projets:syncomp:meetings:meeting130415

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

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.
recherche/projets/syncomp/meetings/meeting130415.txt · Dernière modification: 2015/04/13 12:49 par tigli