Blif _simul.
Rouge signifie non évalué, sans coloration signifie absent et bleu signifie présent.
Comme le montre l’exécution dans la figure 4.8, au début nous attendons les deux évè-nements "P erson_Inside_Zone_UseReandingT able" et "P erson_Inside_Zone_UseCoffeeCorner". En-suite, nous avons l’évènement "P erson_Inside_Zone_UseReandingT able"dans l’instant logique numéro 1, de même pour l’instant logique numéro 2. Pour le troisième il y a apparition de l’évènement "P erson_Inside_Zone_UseCoffeeCorner" et ainsi de suite. Nous avons pas reconnu le scénario e1 Overlaps e2 jusqu’à la fin de transfert des donnée physiques.
CHAPITRE 4. ÉVALUATION ET RÉSULTATS 46
Figure 4.8 —Réaction de la machine d’exécution vis-à-vis le scénario "Overlaps".
Nous avons élaboré du fichier log (voir figure4.9) quelques portions, dans lesquelles il y a une succession des calculs des instants logiques et les évènements "Outputs" construisant cet instant.
CHAPITRE 4. ÉVALUATION ET RÉSULTATS 47
Figure 4.9 —Fichier log de sortie : Réaction de la machine d’exécution vis-à-vis le scénario
"Overlaps".
CHAPITRE 4. ÉVALUATION ET RÉSULTATS 48
4.5 Modèle de deux scénarios "Before"
syn-chrones
Ce modèle consiste à contrôler deux scénarios en parallèle :
➤ e3 Bef ore e1 est un modèle qui teste que l’évènement e3 arrive et se termine avant l’évènement e1. Il lève une alarme T ERM si c’est le cas.
Nous appliquons ce modèle à la reconnaissance du scénario d’une personne qui doit être à l’entrée avant d’être dans la zone où il y a la table de lecture. On consid`re : e3 Before e1, avec e3 : La personne p1 est à l′entrée et e2 : La personne p1 est à la zone où il y a la table de lecture ; ➤ e1 Bef ore e2 est un scénario qui teste que l’évènement e1 arrive et se termine avant l’évènement e2. Il lève
une alarme T ERM1 si c’est le cas.
Nous appliquons ce modèle à la reconnaissance du scénario d’une personne qui doit être t dans la zone ou il y a la table de lecture avant dêtre dans la zone où il y a le coin caffé.On consid`re : e1 Bef ore e2, avec e1 : La personne p1 est à l zone où il y a la table de lecture et e2 : La personne p1 est à la zone du coin de caf f é.
Nous avons utilisé l’éditeur d’automate Galaxy comme le montre la figure 4.10pour modéliser ces deux modèles des scénarios. Pour obtenir le modèle global qui est la mise en parallèle de ces deux sous modèles, nous avons utilisé les outils décrits précédemment. Nous avons construits les représentations respectives de ces sous deux mod`les sous forme d’automates de Mealy, au format ".blif". Ensuite, l’outil Merge_blif a réalisé la mise en parall`le des deux automates et généré l’automate résultat, également au format ".blif". Enfin, l’outil Blifto nous a permis de générer la représentation en "c" du modèle global, pour dialoguer avec la machine d’exécution.
Figure 4.10 —Modèles de deux scénarios "Before" synchrones (e3 Before e1, e1 Before e2)
en utilisant l’outil Galaxy.
CHAPITRE 4. ÉVALUATION ET RÉSULTATS 49
Figure 4.11 — Simulation du fonctionnement du modèle de deux scénarios "Before"
syn-chrones (e3 Before e1, e1 Before e2) en utilisant l’outil Blif_simul.
Rouge signifie non évalué, sans coloration signifie absent et bleu signifie présent.
En suivant le même démarche que pour les deux scénarios précédents, nous construisons la table de corres-pondance entre les signaux attendus de type booléen du code ".c", généré par l’outil Autom2circuit, et les objets concrets que considèrent la machine d’exécution, comme le montre le tableau4.3.
Comme le montre l’exécution de la machine dans la figure 4.12, au début, les signaux attendus suite à l’exécution à vide de l’automate correspondent aux évènements : "P erson_Inside_Zone_UseReandingT able" et "P erson_Inside_Zone_Entrance". D’une manière constante la machine déclenche une alarme (TERM1) si les données physiques présentent une apparition de l’évènement "P erson_Inside_Zone_Entrance" (qui correspond à e3) avant l’évènement "P erson_Inside_Zone_UseReandingT able" (qui correspond à e1) . De même une autre alarme (TERM) est déclanchée si les données physiques présentent une apparition de l’évènement "P erson_Inside_Zone_UseReandingT able" (qui correspond à e1) avant "P erson_Inside_Zone_UseCoffeeCorner" (qui correspond à e2). Conformément à la sémantique du paral-lèle synchrone, le scénario est terminé et reconnu lorsque les deux alarmes ont été émises.
CHAPITRE 4. ÉVALUATION ET RÉSULTATS 50
Variables booléennes Objets
e1 Person_Inside_Zone_UseReandingTable
(p1,zoneUseReadingTable)
e2 Person_Inside_Zone_UseCoffeeCorner
(p1,zoneUseCoffeeCorner)
e3 Person_Inside_Zone_Entrance
(p1,Entrance)
Tableau 4.3 —Tableau de correspondance du modèle de deux scénarios "Before" synchrones
et parallèle.
Figure 4.12 —Réaction de la machine d’exécution vis-à-vis les deux scénarios "Before"
syn-chrones et parallèle.
CHAPITRE 4. ÉVALUATION ET RÉSULTATS 51
Nous avons extrait du fichier log (voir figure4.13) quelques portions, dans lesquelles il y a une succession des calculs des instants logiques et les évènements "Inputs" construisant cet instant.
Figure 4.13 — Fichier log de sortie : Réaction de la machine d’exécution vis-à-vis les deux
scénarios "Before" synchrones et parallèle.
CHAPITRE 4. ÉVALUATION ET RÉSULTATS 52
4.6 Limites et améliorations
À mesure que l’étude avançait, nous avons pu observer quelques limitations à ce travail, parmi lesquelles : ➤ Un système de reconnaissance d’activités est un système qui réagi immédiatement selon les changements
des statuts des signaux : il est sensible à la présence et à l’absence. De cette façon, nous avons adapté au début de notre étude une méthode qui consiste à considérer que la fin de premier signal n’appariant une autre fois dans un ∆t choisi, mais le fiat qu’un évènement est caractérisé par une date de fin il se peut que cette dernière être en retard si ∆t est achevé, donc nous serons obligé à chaque fois de retardé le fin de l’instant jusqu’au la fin de cet évènement, dans ce cas si le même évènement réapparaisse avant la fin de la première apparition nous risquons de retardé l’instant logique et ce démarche peut être fait infiniment. Pour cela nous avons décidé de traité les trois exceptions citées précédemment ;
➤ Pour tester le bon fonctionnement de la machine d’exécution proposée, nous avons essayé d’avoir des vrais valeurs modélisant une scène du monde réel de diverses sources (capteurs environnementales et plate-forme SUP) et vu les contraintes de temps nous avons obligé de testé q’avec des donnée de SUP provenant du centre hospitalier universitaire de NICE.
Bien que la machine ait réussi à calculer les instants logiques en passant d’une interface asynchrone en une autre synchrone, plusieurs améliorations de cette solution proposée sont envisageables :
➤ En premier lieu, la machine d’exécution peut être un outil plus fiable, générique, et utilisable pour satisfaire n’importe quel besoin de passage de l’asynchrone en synchrone, pour cela nous devons modifier le mode de lecture des données (Flex/Bison : grammaire statique) ;
➤ En deuxième lieu, nous pouvons proposé d’autres fonctionnalités plus intelligentes, de telle façon que la machine d’exécution pourra gérer l’incompatibilité des évènements, ceci sert à raffiner l’instant logique.
4.7 Conclusion
Ce chapitre a été consacré pour tester la réaction de la machine d’exécution vis-à-vis des scénarios bien définis (Before, Overlaps et un modèle de deux Before synchrones), en présence des données élaborées au centre hospitalier de Nice. En effet, ces scénarios sont modélisés à l’aide de Galaxy/Autom2circuit, outils développés par Monsieur Daniel Gaffé dans le cadre de recherche. Enfin nous avons cité les problèmes rencontrés au cours de la conception de la machine d’exécution, et nous avons proposé des idées servant de l’améliorer.