Ci-dessous, les différences entre deux révisions de la page.
Prochaine révision | Révision précédente | ||
collaborations_recherche:univ_corte [2014/11/07 11:28] tigli créée |
collaborations_recherche:univ_corte [2014/11/13 09:36] (Version actuelle) capocchi [Minutes des Meeting] |
||
---|---|---|---|
Ligne 18: | Ligne 18: | ||
[[:collaborations_recherche:univ_corte:minutes_161014|Minutes161014 : Sehili/ Capocchi / Tigli]] | [[:collaborations_recherche:univ_corte:minutes_161014|Minutes161014 : Sehili/ Capocchi / Tigli]] | ||
- | + | [[:collaborations_recherche:univ_corte:minutes_071114|Minutes071114 : Sehili/ Capocchi / Tigli]] | |
- | TODO : | + | |
- | - Version 4 SharpDevelop | + | |
- | - Master Ines | + | |
- | + | ||
- | + | ||
- | + | ||
- | Stratégie générée en Python ... | + | |
- | + | ||
- | + | ||
- | -- iron python | + | |
- | -- dans la class Bean en créant un instance de la classe et méthodes python | + | |
- | + | ||
- | les stratégies ... | + | |
- | Second papier pour une conf SimulTech "Colmar" (ref TM) | + | |
- | + | ||
- | Voir PLAN !!! | + | |
- | + | ||
- | + | ||
- | Envoyer le Master d'Ines | + | |
- | + | ||
- | + | ||
- | VOIR SI OK pour la Roadmap ... | + | |
- | VOIR UbiComm ... Nice deadline Février 2015 ... | + | |
- | + | ||
- | + | ||
- | + | ||
- | ==== | + | |
- | + | ||
- | Architecturalement parlant on a trois Beans ... dont un Bean central | + | |
- | + | ||
- | Pb 1 : | + | |
- | + | ||
- | Conformité : du modèle synchrone avec le modèle synchrone encapsulé dans | + | |
- | la machine d'exzcution modélisée en DEVS (machien d'exécution génériqyue | + | |
- | sans notions sméanitques lié à l'uatomate et le dispositifs) | + | |
- | + | ||
- | => permet en rajoutant des propriétés à vérifier au delà de celles | + | |
- | vérfiier dans le model checking de l'automate de | + | |
- | parler de "conformité" | + | |
- | + | ||
- | Pb 2: | + | |
- | + | ||
- | Qui intègre les contraintes de la compositikon ? | + | |
- | + | ||
- | A > c'est l'automate synvhrone qui résulte du produit des automate x | + | |
- | avec l'automate de contrainte | + | |
- | + | ||
- | mes entrées sont on1 / on2 / off 1 / offé pour 2 accès | + | |
- | + | ||
- | ces mon produit d'automate avec ses contraitnes ajoutées : ex : on1-off2 | + | |
- | => on et on2-oof1 => on | + | |
- | qui va résoudre la compostion | + | |
- | validatation par model checking sur l'automate résultatnt | + | |
- | + | ||
- | + | ||
- | B> résoudre les contraintes de la coposition liées aux accés concurrents | + | |
- | dans la mahcine d'exécution sans en tenir copte dans l'automate | + | |
- | + | ||
- | Je dépose dans la stratégie de la machine d'exécution, en plus des | + | |
- | asppects génréqes (ex. DT entre deux décleanchment ... , donc tout | + | |
- | quelque soit le dispotif), des contraintes sur la génération des | + | |
- | événmrents d'entrée de l'automate liées à la sémnatinwque du dispostif | + | |
- | : on1 - off2 => on | + | |
- | on2 - off1 => on | + |