De B0_Uppaal vers Uppaal

Cette section présente les étapes de transformation des spécifications B en automates Uppaal. Nous vérifions ensuite l’absence de blocage sur ces automates, en exploitant le vérificateur de l’outil Uppaal.

5.2.1 Extension de Uppaal

Le langage de modélisation de Uppaal a été étendu récemment par de nouvelles fonctionnalités. Parmi ces nouveautés, nous pouvons citer les fonctions (qui ne peuvent pas référencer d’horloges), le quantifi- cateur universel “forall” et la déclaration de type “typedef”, que nous allons utiliser dans notre modéli- sation.

Fonction ::= Type Id ’(’Paramètres’)’ Bloc Bloc ::= ’{’Déclarations Action* ’}’ Action ::= Bloc | ’;’ | Expression ’;’ | BoucleFor | Iteration | BoucleWhile | BoucleDoWhile | ActionIf | ActionReturn

BoucleFor ::= ’for’ ’(’ Expression ’;’ Expression ’;’ Expression ’)’ Action Iteration ::= ’for’ ’(’ Id ’:’ Type ’)’ Action

BoucleWhile ::= ’while’ ’(’ Expression ’)’ Action

BoucleDoWhile ::= ’do’ Action ’while’ ’(’ Expression ’)’ ’;’ ActionIf ::= ’if’ ’(’ Expression ’)’ Action [ ’else’ Action ] ActionReturn ::= ’return’ [ Expression ] ’;’

Le quantificateur “forall” peut être utilisé dans les expressions en respectant la syntaxe suivante:

’forall’ ’(’ Id ’:’ Type ’)’ Expression

Avant de donner le code Uppaal de la machine preemptiveuppaal qui exprime l’ordonnancement de plusieurs tâches, nous présentons les principes de transformation des substitutions B.

5.2.2 Principe de la transformation

Rappelons que l’automate doit tourner le plus vite possible afin d’éviter les deadlocks, et assurer que tous les processus puissent accéder au processeur avant d’atteindre leur délai critique. Le principe de traduction se base sur les règles suivantes:

 L’automate Uppaal comprend un état nommé start à partir duquel sont réalisées les transitions associées aux opérations B.

 La garde de l’opération SKIP spécifiant une propriété portant sur l’instant suivant, est traduite par un invariant de place Uppaal présent dans tous les états de l’automate, et exprimé sur l’instant courant.

 L’état start est le seul état dans lequel le temps peut s’écouler.

 Des états intermédiaires sont associés au séquencement de B (“;”). Ils doivent être déclarés comme committed, afin de garantir l’atomicité de la séquence d’action et l’exécution en temps nul.

 Si une transition contient une communication, le canal correspondant doit être déclaré comme urgent.

 Pour chaque transition sortant d’un état, il faut ajouter dans l’invariant de cet état que les hor- loges ne dépassent pas la borne minimale des gardes temporisées associées à cette transition. Plus précisément, pour une transition SELECT k^GTHEN . . . END, on ajoute à l’invariant le prédicatG) k.

Le tableau de la figure 5.1 illustre la traduction des substitutions B en Uppaal. Cette transformation est progressive. De manière générale, le point de départ est une opération B (cas 6 et 7). Initialement, une substitution est traduite par un automate comportant un état unique start et une transition étiquetée par

la substitution associée à l’opération. Ces transitions sont progressivement éliminées en introduisant des états intermédiaires e1, e2, . . . et des instructions Uppaal. Chaque transformation traduit une construction B et se termine lorsque l’instruction B se limite à une affectation.

Notons que les cas 4 et 5 considèrent que les substitutions S et S’ sont des séquences d’affectations ou d’appels d’opérations. Pour les cas 3 et 5, il faut assurer qu’il n’y a pas de blocage dans les états intermédiaires e’, c’est à dire que la disjonction des gardes des transitions issues de ces états doit donc être vraie. Nous devons également vérifier les obligations de preuveI^G)fis(S)etI )[S℄(G

0 ) fis(S

0

))respectivement pour les cas 2 et 5 où I est l’invariant de place de l’état start.

Cas Substitution B Description Uppaal

1 2 3 4 5 e1 e2

IF P THEN S1 ELSE S2 END

xcbjvkq<bnwscvkj cvn<kl!cwv e2 e1 guard P S1 guard !P S2 2 2 3 start e2

SELECT G THEN S END

xcbjvkq<bnwscvkj start e2 guard G S 3 2 xcbjvkq<bnwscvkj e1 e2 S1;S2 e2 e’ S1 C e1 S2 4 3 e1 e2 S .... e2 assign S e1 .... 5 2 3 start e2

S; SELECT G’ THEN S’ END

xcbjvkq<bnwscvkj e2 start assign S e’ C S’ invariant G’ 6 2 3 , Opérations externes: Op = S wgdjsfgjsfj xfcgjfhjsd start S sync Op? 7 2 3 b Opérations internes: Op = S wcghwsgjsgw qdfhqgdjhq start S

Tableau 5.1: Transformation B/Uppaal des substitutions

5.2.3 Exemples

Après avoir présenté les principes de traduction B0_Uppaal/Uppaal, nous illustrons les substitutions principales par des exemples.

Exemple 1: Traitement du IF

L’instruction “IF not empty^itop= pp THEN pop ELSE cl(pp):= 0 END” peut être traduite en Uppaal par le schéma de la figure 5.7.

!empty && itop == pp pop()

empty or itop != pp cl[pp] = 0

s5 start

s5 -> start { guard !empty && itop==pp; assign pop(); },

s5 -> start { guard empty or itop!=pp; assign cl[pp]=0; }

Figure 5.7: Transformation du IF en automate Uppaal

Exemple 2: Traitement du SELECT

L’instruction “SELECT cl(running)comp(running)^running_is_last= TRUE THEN mazkt_remov- e_last(running) END” peut être exprimée en Uppaal par le schéma de la figure 5.8.

cl(running) >= comp(running) && running_is_last maz(), t_remove_last(running)

start

start -> start { guard (cl[running] >= comp[running]) && running_is_last;

assign maz(),

t_remove_last(running); }

Figure 5.8: Transformation du SELECT en automate Uppaal

Exemple 3: Séquences et conditions Considérons les instructions B suivantes:

comp(pp):= duration(pp)

; IF ((cld(running)-cld(pp))  (delay(ruuning)-delay(pp))) THEN

push(running) k running:= pp

END

Ce bloc peut être modélisé par l’automate Uppaal de la figure 5.9

Exemple 4: SELECT imbriqué

Pour illustrer ce cas en Uppaal, nous considérons l’instruction suivante:

elect(pp) =

SELECT cl(running) >= comp(running) ^ pp 2 support - {running}

THEN

t_remove(running)

; SELECT max = true THEN IF not empty THEN

comp(itop) := comp(itop) + comp(running) END

comp[pp] = duration[pp] start s1 s2 cld[running]-cld[pp] <= delay[running]-delay[pp] push(running), running = pp cld[running]-cld[pp] > delay[running]-delay[pp] C

start -> s1 { assign comp[pp]= duration[pp]; },

s1 -> s2 { guard cld[running]-cld[pp] <= delay[running]-delay[pp]; assign push(running),

running= pp; },

s1 -> s2 { guard cld[running]-cld[pp] > delay[running]-delay[pp]; }

Figure 5.9: Tansformation des séquences et conditions en automate Uppaal

Cette instruction peut être exprimée en Uppaal par le schéma de la figure 5.10, où la transition depuis start n’est possible que si l’invariant de l’état intermédiaire s3 est satisfait. Ainsi, l’effet de bord réalisé par t_remove n’est exécuté que si la séquence des deux transitions est réalisée.

C support[pp] = true &&

pp != running && cl[running] >= comp[running] t_remove(running) !empty comp[itop] = comp[itop]+comp[running] empty

start -> s3 { guard support[pp] == true && pp != running

&& cl[running] >= comp[running]; assign t_remove(running); },

s3 -> s4 { guard !empty;

assign comp[itop]= comp[itop]+comp[running]; },

s3 -> s4 { guard empty; } s3 {max}

start s3 s4

max

Figure 5.10: Transformation du SELECT imbriqué en automate Uppaal

Après avoir présenté les principes de transformation appliqués à certains exemples, nous allons ef- fectué la traduction de notre modélisation B des ordonnanceurs en automates Uppaal.