Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentes Révision précédente | Dernière révision Les deux révisions suivantes | ||
recherche:projets:syncomp:meetings:meeting130415 [2015/04/13 12:16] tigli [Cadre Général : Une approche Middleware originale] |
recherche:projets:syncomp:meetings:meeting130415 [2015/04/13 12:38] tigli [Gestion des signaux valués] |
||
---|---|---|---|
Ligne 29: | Ligne 29: | ||
* Ces opérateurs sont souvent spécifiques à un type et donc fournis par défaut sur des types prédéfinis. | * 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) | * 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}} | ||