Afficher les différences entre les messages, événements et données Stateflow
Cet exemple compare le comportement des messages, événements et données dans Stateflow®.
Diagrammes d’expéditeur
Ce modèle dispose de trois diagrammes d’expéditeur : DataSender, EventSender et MessageSender. Chaque diagramme d’expéditeur possède un état. Dans l’action de saisie de l’état, les diagrammes attribuent une valeur aux données, envoient un événement par appel de fonction ou envoient un message.
Diagrammes de récepteur
À chaque diagramme d’expéditeur correspond un diagramme de récepteur. Chaque diagramme de récepteur dispose d’un diagramme d’état avec les états A0, A1, A2 et A3. L’événement implicite after(3,sec) déclenche la transition de A0 vers A1. Les données, l’événement ou le message du diagramme d’expéditeur correspondant commandent les transitions entre A1, A2 et A3.
Sortie de scope
Chaque diagramme de récepteur dispose d’une sortie d’état actif activée et connectée à un scope. Le scope montre quels états sont actifs pour chaque pas de temps. Cette sortie met en évidence la différence de comportement entre les données, événements et messages de sortie.
Comportement des données
Le diagramme DataSender attribue une valeur de 1 aux données de sortie M, qui est reliée comme une entrée du diagramme DataReceiver.
Le diagramme DataReceiver s’exécute une fois à chaque pas de temps. Au début de la simulation, l’état A0 est actif. Au pas de temps t=3, la transition de A0 vers A1 se produit. Au pas de temps t=4, le diagramme teste si M est égal à 1. La condition est vraie donc le diagramme transitionne de A1 vers A2. Au pas de temps t=5, M est toujours égal à 1, donc le diagramme transitionne de A2 vers A3. Sur le scope, vous voyez que DataReceiver change d’état trois fois.
Une fois que les données sont attribuées à une valeur, elles maintiennent cette valeur tout au long de la simulation. Ainsi, chaque fois que DataReceiver évalue la condition [M == 1], la transition vers un nouvel état se produit.
Comportement d’un événement
Le diagramme EventSender utilise la commande send(M) pour envoyer un événement en sortie par appel de fonction pour activer le diagramme EventReceiver.
Le diagramme EventReceiver s’exécute uniquement lorsque l’événement en entrée M active le diagramme. Au début de la simulation, l’état A0 est actif. La transition de A0 vers A1 est basée sur une logique temporelle en durée absolue et n’est pas valide au pas de temps t=0. A0 reste actif et le diagramme est désactivé. Étant donné que EventSender n’envoie l’événement M qu’une seule fois, EventReceiver ne se réactive pas. Sur le scope, vous voyez que EventReceiver ne quitte jamais A0.
Comme les événements ne restent pas valides durant les pas de temps, le diagramme de réception n’a qu’une chance de répondre à l’événement. Lorsque EventSender envoie l’événement, EventReceiver n’est pas prêt à y répondre. La possibilité pour EventReceiver de réaliser la transition en réponse à l’événement est perdue.
Comportement d’un message
Le diagramme MessageSender utilise la syntaxe send(M) pour envoyer un message via le port de message de sortie. Le message est placé dans la file d’attente des messages d’entrée du diagramme MessageReceiver. Le message reste dans la file d’attente jusqu’à ce que MessageReceiver l’évalue.
Le diagramme MessageReceiver s’exécute une fois à chaque pas de temps. Au début de la simulation, l’état A0 est actif. Au pas de temps t=3, la transition de A0 vers A1 se produit. Au pas de temps t=4, le diagramme détermine que M est présent dans la file d’attente ; il réalise alors la transition à A2. À la fin du pas de temps, le diagramme supprime M de la file d’attente. Au pas de temps t=5, aucun message n’est présent dans la file d’attente, le diagramme ne réalise donc pas la transition à A3. A2 reste l’état actif. Sur le scope, vous voyez que MessageReceiver change d’état seulement deux fois.
Contrairement aux événements, les messages sont mis en file d’attente. Le diagramme de réception peut choisir de répondre à un message à tout moment après son envoi. Contrairement aux données, le message ne reste pas valide indéfiniment. Le message est détruit à la fin du pas de temps.
