Stateflow par l’exemple

Stateflow [Sta] est une extension de Simulink (boîte à outils de Matlab) qui offre un outil de développement et de conception pour des systèmes complexes dont la loi de commande peut évoluer de manière discrète et discontinue en fonction de l’état du système (système possédant des modes de fonctionne- ment) ou pour des logiques de surveillance (protocoles par exemple). En Sta- teflow, il est possible de créer des tables de vérité grâce au bloc Truth Table ou encore des diagrammes d’états avec le bloc Chart. Une table de vérité per- met de modéliser des conditions et des actions complexes tandis qu’un dia- gramme d’états simplifie la représentation des transitions complexes entre les états.

Inspirée des automates, la notation des diagrammes d’états (statechart) a été proposée par Harel [Har87] et a ensuite été adoptée par différents langages de modélisation (Uml 2 [Sel06], Statemate [Val92], Stateflow, etc.). Un dia- gramme Stateflow est une machine à état décrite, entre autres, par des états, transitions, jonctions, événements, conditions et actions.

Étant donné que nos travaux concernent principalement Simulink, nous présentons brièvement les concepts de base des diagrammes Stateflow qui sont la source des événements de type function-call.

Considérons le diagramme d’états Stateflow présenté dans la figure3.10. Il est utilisé comme référence pour expliquer les différents concepts d’un dia- gramme Stateflow.

EtatA EtatC EtatC1 1 EtatC2 2 EtatB H EtatB2 EtatB1 EtatB3 transition_par_defaut transitionBC transitionCB [cond2] [cond1] 2 evenmt [cond1]{func1()}/func2() transitionB1B3 1 Transi'on par défaut  État exclusif (OR)  Jonc'on 

Label de transi'on  _{Condi'on  Ac'on de}  

condi'on  Ac'on de 

 transi'on  Jonc'on de  l’historique  Transi'on  État parallèle (AND)  Événement 

Fig. 3.10 – Structure générale d’un diagramme d’états en Stateflow

État : Il décrit une étape dans l’exécution d’un système piloté par les événe- ments. Un état, peut contenir d’autres états, et être actif ou non selon les conditions et les événements qui se sont produits depuis le démarrage du système.

Stateflow dispose de deux états : exclusif (OR) et parallèle (AND). Dans un diagramme, ou dans un état exclusif (OR), un seul de ces états est actif lorsque l’état parent ou le diagramme est actif. Tandis qu’un état à sous-états parallèles peut avoir plusieurs états actifs simultanément quand l’état parent est actif.

Par exemple, lorsque EtatA est actif, EtatB et EtatC sont mutuelle- ment exclusifs. EtatB et EtatC sont alors appelés des décompositions exclusives (OR). Elles sont représentées graphiquement par des rectangles continus.

De même, quand EtatC est actif, les états EtatC1 et EtatC2 sont ac- tifs en même temps. Ils sont alors appelés états parallèles (AND) et sont représentés par des rectangles discontinus.

Événement : Ce sont les événements qui pilotent l’exécution d’un diagramme. Les événements n’ont pas de représentation graphique. Ils apparaissent dans un diagramme à travers leur libellé. Par exemple, evnmt est l’évé- nement déclencheur de la transition entre EtatB3 et la jonction.

Jonction : Une jonction est un point de décision pour la (les) transition(s). Elle est utilisée pour factoriser ou combiner les transitions afin de décrire plus simplement le comportement du système représenté. Elle est semblable à un état mais une transition ne peut s’arrêter dans une jonction, elle

doit être suivie immédiatement d’une autre transition ou elle doit être annulée.

La jonction d’historique (History Junction), quand elle est associée à un état, indique que ce dernier possède une mémoire. Cela signifie que lors- qu’un état à mémoire est réactivé, son sous-état actif lors de sa dernière désactivation est également réactivé.

Dans la figure3.10, la jonction d’historique dans EtatB indique que lors- qu’une transition active EtatB, le sous-état qui sera activé est celui qui était actif parmi EtatB1, EtatB2 et EtatB3, lorsque EtatB a été désac- tivé.

Une transition par défaut n’a pas d’état source, elle indique l’état qui sera activé lorsque son parent l’est également. Par exemple, les transitions qui déclenchent EtatA, EtatB et EtatB1 sont des transitions par défaut. Une transition peut être labellisée par l’événement déclencheur. Par exemple, transitionCB, le label de la transition qui relie EtatC à EtatB, est en fait un événement. Une transition peut également être la- bellisée par une condition ou par une action.

Condition : Une condition est une expression booléenne spécifiant qu’une

transition se déroulera lorsque cette expression booléenne est évaluée à vrai. Dans la figure3.10, cond1 représente une expression booléen qui, évaluée à vrai, déclenche la transition entre EtatB1 et la jonction.

Action : Les actions font partie de l’exécution d’un diagramme Stateflow.

Une action peut être exécutée comme une partie d’une transition ou comme une action au sein d’un état. Une action peut être l’appel d’une fonction, la diffusion d’un événement vers Simulink par exemple, l’affec- tation d’une valeur à une variable, etc.

Une transition peut contenir une action conditionnelle (par exemple,

{func1()}dans la figure 3.10) et/ou une action de transition (comme func2()).

Supposons, dans la figure 3.10, que le diagramme est inactif, l’état EtatB3est actif et l’événement evnmt survient. Le diagramme d’états est alors activé et déclenche une transition valide pour l’événement evenmt. Une transition valide de EtatB3 vers la jonction est détectée. La condition cond1 est vraie, alors l’action de conditionnelle{func1()}

est activée et exécutée. EtatB3 qui est encore actif termine ses ac- tions (exit_action()) et devient inactif. Ensuite l’action de transition func2()est exécutée. La condition cond2 est fausse. Donc la transition entre la jonction et EtatB2 n’est pas valide. Par conséquent, une action après un délai (dur_action()) de l’état EtatB3 est exécutée en gar- dant ce dernier actif. Le diagramme d’états redevient inactif en attendant d’être activé par un nouvel événement.

L’action liée à un état dépend des modalités d’activation. Ces modalités sont résumées dans la figure3.11.

entry désigne que l’action ent_action() est exécutée une fois que l’état EtatBest devenu actif ;

during indique que l’action dur_action() est exécutée lorsque l’état

EtatBest déjà actif et qu’un événement quelconque survient sans désac- tiver l’état EtatB ;

EtatB/ 

entry: ent_ac.on();   during: dur_ac.on();  exit: exit_ac.on(); 

on transi.onCB: on_ac.on(); 

Fig. 3.11 – Les actions associées à un état

exit indique que l’action exit_action() s’exécute juste avant que l’état EtatBne devienne inactif. Après exécution de l’action exit_action(), l’état EtatBdevient inactif ;

on est semblable au mode during sauf que c’est la transition transitionCB qui déclenche l’exécution de l’action on_action().

Enfin les données consommées ou produites par un diagramme Stateflow sont explicitées dans la configuration de ce dernier. Cela consiste à préciser si une donnée est locale, constante, une sortie d’un bloc Simulink, une en- trées d’un bloc Simulink, etc. De même, il est possible de définir les sorties du diagramme comme des événements déclencheurs de blocs Simulink (voir figure3.9) ou inversement définir ses entrées comme des événements.

Ainsi, les diagrammes Stateflow agissent comme des blocs Simulink. In- tégrés dans un circuit, les diagrammes d’états sont alimentés par des blocs Simulink et produisent des sorties consommées par d’autres blocs Simulink. En particulier, lorsqu’il s’agit de contrôler une partie du système dans le cadre des applications de commande, le bloc Trigger mis à l’intérieur d’un dia- gramme Stateflow sert à l’activer selon la condition du signal d’entrée comme le montre la figure3.12.

Fig. 3.12 – Trigger un diagramme Stateflow

Comme les diagrammes Stateflow sont intégrés dans les modèles Simu- linksous la forme de blocs atomiques, nous ne parlons que de circuits Simu- linkde façon plus générale.