Mod´elisations

5.3.1 Automates temporis´es

La figure 5.1 présente la modélisation d’une des voies parallèles et celle des barrières

au moyen d’automates temporisés. Les automates présentés ici peuvent être directement

implant´es pour UPPAAL ; afin de les tester avec Kronos, un travail d’adaptation est

n´ecessaire et nous obtenons des automates plus complexes qu’il ne nous paraˆıt pas utile

de pr´esenter ici.

.

Far

t≤aM

Before

t≤eM

Inside

·|app!|t:=0

t≥am|·|t:=0

t≥em|exit!|·

clock t

.

Open

g≤g_M

GoDown

Closed

g≤gM

GoUp

·|down?|g:=0

g≥gm|·|·

·|up?|g:=0

g≥gm|·|· ·|down?|g:=0

−|down?|·

·|down?|·

clock g

Figure 5.1 — A gauche, l’automate^` Train, mod´elisant une voie et le train

associé, qui utilise un chronomètret. À droite, l’automateGates, représentant

les barri`eres ; il utilise un chronom`etreg.

L’automate pour une voie démarre dans l’état Far(les états initiaux sont dessinés en

gras). Lorsqu’un train passe au niveau du premier capteur, l’automate passe dans l’´etat

Beforeen émettant le signal app! et en remettant à zéro le chronomètret. Il peut rester

dans cet état tant quet≤aM; àt=aM au plus tard, il doit passer dans l’étatInsidequi

mod´elise le fait que le train se trouve entre les barri`eres ; cette transition n’est possible

que sit≥am et remettà zéro sans émettre aucun signal. De même, l’automate passe à

nouveau à l’étatFar pourt∈[em, eM] en émettant le signal exit!.

Le fonctionnement de l’automate sp´ecifiant les barri`eres est similaire. Remarquons

que cet automate peut recevoir un signal down? depuis n’importe lequel de ses ´etats.

Par contre, il ne peut recevoir up? que lorsque la barrière est fermée. Le nom des états

indique sans ambigu¨ıté ce qu’ils représentent au niveau du système concret. Ceci n’est

pas réaliste du point de vue de la modélisation mais constitue plutôt une propriété qu’on

devrait vérifier. Dans ce cas et dans celui du contrôleur, certains signaux incontrôlables

ne sont pas pris en compte dans tous les ´etats (alors qu’ils devraient l’ˆetre). Nous avons

fait le choix de cette version peu r´ealiste afin de garder une sp´ecification simple nous

permettant d’illustrer notre propos sans alourdir l’aspect technique.

Le contrôleur doit tenir compte des spécificités de la barrière au niveau de la réception

des signaux. Son fonctionnement est assez simple : chaque fois qu’il re¸coit un signalapp?

(qui se synchronise avec leapp! ´emis par un automateTrain), il incr´emente un compteur

et envoie un signal down! aux barri`eres dans un d´elai compris dans [cm, cM]. Lorsqu’il

re¸coit un signalexit?, le contrôleur décrémente la même variable, si elle tombe à zéro, le

dernier train vient de quitter les barri`eres et un signalup! leur est envoy´e. La figure 5.2

donne l’automate mod´elisant le contrˆoleur.

.

Idle

c≤cM AppDown

c≤cM ExitUp

·|app?|c:=0 c≥cm|down!|n:=n+1

n=1|exit?|c:=0

c≥cm|up!|n:=0

n>1|exit?|n:=n−1

clock c, int n:=0

Figure 5.2 —L’automate temporiséController représentant le contrôleur. Il

utilise une variable entièreninitialisée à zéro et un chronomètrec.

Le syst`eme complet est obtenu comme le produit synchronis´e dencopies de l’automate

Train (nomm´ees Traini, pour 1 ≤ i ≤n) et des automates Gates et Controller. Nous

obtenons un automate permettant l’ex´ecution entrelac´ee de tous ceux qui le composent

avec synchronisation sur les actions telles que app! etapp?.

La propriété de sécurité et d’absence de blocage peut s’exprimer par une formule de

logique temporelle (dans une variante de CTL) :

∀¤³

¬deadlock´

∧³

(Train₁.Inside∨ · · · ∨Trainn.Inside)⇒Gates.Closed´

,

qui peut se traduire ainsi :« Il est toujours vrai que le syst`eme n’est pas bloqu´e et que

si l’un des automatesTraini est dans l’´etatInsidealors l’automate Gates est dans l’´etat

5.3.2 M-nets

La spécification avec des M-nets est calquée sur celle avec les automates temporisés

donn´ee plus haut. Pour chaque ´etat, nous aurons une place (un jeton dans celle-ci

cor-respondant `a l’activation de l’´etat) et pour chaque transition de l’automate, nous aurons

une transition d’un M-net d´epla¸cant un jeton d’une place `a une autre. Les transitions

portent les mêmes actions et les mêmes gardes. Il existe quand même quelques différences

notables :

• nous pouvons repr´esenter toutes les voies (avec les trains) par un seul M-net, les

différents trains étant représentés par différents jetons ;

• le contrˆoleur n’utilise pas une variable enti`ere mais stocke le nombre de trains

dans ses places (ce qui a le mˆeme effet) ;

• nous avons en plus une horloge causale et les transitions portent des actions pour

communiquer avec elle ;

• les contraintes de temps spécifiées dans les états avec les automates sont ici

sp´e-cifi´ees au niveau de l’horloge ;

• les M-nets devant être ex-restreints, le système global démarre avec une action

silencieuse synchronisant l’initialisation de tous les M-nets le composant.

Nous utilisons une horloge causale très similaire à celle présentée figure 4.2 (page 67)

mais légèrement adaptée à notre problème. En particulier, puisque le système n’est pas

destiné à s’arrêter, l’horloge n’a pas de transition pour terminer, et sa transition

d’ini-tialisation est synchronis´ee avec les transitions initialisant les autres M-nets composant

le syst`eme. De plus, nous fixons le nombre de compteurs que l’horloge peut manipuler

et nous les assignons de la fa¸con suivante :

• le M-net représentant le contrôleur à l’identificateur 0, nous fixons doncm0=^df cM;

• le M-net mod´elisant les barri`eres utilise l’identificateur 1 et nous posonsm1 =^df gM;

• chaque train utilise deux identificateurs puisqu’il n´ecessite deux maximums (aM

eteM) qui sont fixés dans l’horloge. Les trains étant numérotés de 1 à n, le train

iutilise le compteur 2ipour son approche et le compteur 2i+ 1 pour son d´epart,

ce qui implique m2i

df

=aM etm2i+1=^df eM.

L’horloge causale que nous utilisons est donn´ee figure 5.3.

.

⇐

⇒

gates,trains,ctrl Time

tic

V

i≤ncci6=mi

[

clock(id,c,c⁰)

{(0,ω),...,(nc,ω)}

{(0,c0),...,(nc,c_nc)} {(0,c0+1),...,(nc,c_nc+1)}

(id,c)

(id,c0)

Figure 5.3 — L’horloge causaleHr utilis´ee pour le passage `a niveau. Nous

avonsnc

df

= 2n+ 1 o`unest le nombre de voies parall`eles et le type de la place

interne est{(id, iid)|1≤id ≤nc, iid ∈ {0,1, . . . , mid, ω}}.

Les autres éléments de la spécification sont donnés sur la figure 5.4. Nous pouvons y

reconnaˆıtre les automates transform´es comme nous l’avons d´ecrit plus haut.

.

⇒

⇐

[

gates Open \down,clock(1,g,0) _GoDown \down

clock(1,g,ω)

g≥gm

Closed

\

down

c

up,clock(1,g,0)

GoUp

clock(1,g,ω) g≥gm

\

down,clock(1,g,0)

.

⇐

⇒

\

trains Far app,clock(y,t,0)

y=2i

Before

clock(y,t,ω),clock(y⁰,t⁰,0)

(t≥am)∧(y=2i)∧(y0=2i+1)

Inside

exit,clock(y⁰,t⁰,ω)

(t0≥em)∧(y0=2i+1)

{1,...,n}

i i

i

.

⇐

⇒

d

ctrl

Idle

d

app,clock(0,c,0)

AppDown

down,clock(0,c,ω)

c≥cm

d

exit,clock(0,c,0)

ExitUp

up,clock(0,c,ω)

c≥cm

d

exit

x≥2

0 x

x−1

x

x x

x+1

1

0 Figure 5.4 — De haut en bas, les M-nets Ng,Nt et Nc sp´ecifiant

respecti-vement les barri`eres, les voies avec leurs trains et le contrˆoleur. Les places

Far, Beforeet Inside ont le type{1, . . . , n}et les places AppDownet Idleont

le type {0, . . . , n}.

Nous obtenons le système complet en composant en parallèle tous ces réseaux et en

synchronisant sur toutes les actions visibles :

Nr= (NgkNtkNckHr)sc{clock,down,up,app,exit,gates,trains,ctrl} .

Par rapport à la spécification à base d’automates temporisés, celle-ci peut sembler plus

des r´eseaux de Petri, pour lesquels les transitions sont des nœuds alors qu’il ne s’agit

que d’arcs dans les automates. Cependant, il est vrai qu’il faut ajouter les actions pour

communiquer avec l’horloge et que les valeurs des param`etres sont calcul´ees dans les

gardes. La mod´elisation est donc un peu plus complexe avec les M-nets ; en revanche

nous pouvons repr´esenter la concurrence (et non seulement l’entrelacement) alors que

c’est impossible avec les automates. Cet exemple n’exploite pas cette possibilit´e car nous

avons cherch´e `a calquer les M-nets sur les automates correspondants pour mettre en

valeur la ressemblance des sp´ecifications.

Nous vérifions la sécurité du système en testant qu’il n’existe pas de marquage M

accessible `a partir du marquage d’entr´ee deNr tel que

(M(Inside)6=∅)∧(M(Closed) =∅) ,

ce qui s’exprime dans le formalisme de MARIA par :

reject !(place Inside equals empty)

&& (place Closed equals empty) && fatal;

L’absence de blocage peut aussi ˆetre directement exprim´ee par la clause :

deadlock fatal;

Ces deux clauses sont testées à mesure que le graphe de marquage est généré ; si l’une

ou l’autre est violée, la génération est stoppée et l’erreur est signalée (c’est l’utilité du

mot-cleffatal).

Dans le document Modèles composables et concurrents pour le temps-réel (Page 85-89)

5.3.1 Automates temporis´es

La figure 5.1 présente la modélisation d’une des voies parallèles et celle des barrières

au moyen d’automates temporisés. Les automates présentés ici peuvent être directement

implant´es pour UPPAAL ; afin de les tester avec Kronos, un travail d’adaptation est

n´ecessaire et nous obtenons des automates plus complexes qu’il ne nous paraˆıt pas utile

de pr´esenter ici.

.

.

Far

t≤aM

Before

t≤eM

Inside

·|app!|t:=0

t≥am|·|t:=0

t≥em|exit!|·

clock t

.

.

Open

g≤gM

GoDown

Closed

g≤gM

GoUp

·|down?|g:=0

g≥gm|·|·

·|up?|g:=0

g≥gm|·|· ·|down?|g:=0

−|down?|·

·|down?|·

clock g

Figure 5.1 — A gauche, l’automate` Train, mod´elisant une voie et le train

associé, qui utilise un chronomètret. À droite, l’automateGates, représentant

les barri`eres ; il utilise un chronom`etreg.

L’automate pour une voie démarre dans l’état Far(les états initiaux sont dessinés en

gras). Lorsqu’un train passe au niveau du premier capteur, l’automate passe dans l’´etat

Beforeen émettant le signal app! et en remettant à zéro le chronomètret. Il peut rester

dans cet état tant quet≤aM; àt=aM au plus tard, il doit passer dans l’étatInsidequi

mod´elise le fait que le train se trouve entre les barri`eres ; cette transition n’est possible

que sit≥am et remettà zéro sans émettre aucun signal. De même, l’automate passe à

nouveau à l’étatFar pourt∈[em, eM] en émettant le signal exit!.

Le fonctionnement de l’automate sp´ecifiant les barri`eres est similaire. Remarquons

que cet automate peut recevoir un signal down? depuis n’importe lequel de ses ´etats.

Par contre, il ne peut recevoir up? que lorsque la barrière est fermée. Le nom des états

indique sans ambigu¨ıté ce qu’ils représentent au niveau du système concret. Ceci n’est

pas réaliste du point de vue de la modélisation mais constitue plutôt une propriété qu’on

devrait vérifier. Dans ce cas et dans celui du contrôleur, certains signaux incontrôlables

ne sont pas pris en compte dans tous les ´etats (alors qu’ils devraient l’ˆetre). Nous avons

fait le choix de cette version peu r´ealiste afin de garder une sp´ecification simple nous

permettant d’illustrer notre propos sans alourdir l’aspect technique.

Le contrôleur doit tenir compte des spécificités de la barrière au niveau de la réception

des signaux. Son fonctionnement est assez simple : chaque fois qu’il re¸coit un signalapp?

(qui se synchronise avec leapp! ´emis par un automateTrain), il incr´emente un compteur

et envoie un signal down! aux barri`eres dans un d´elai compris dans [cm, cM]. Lorsqu’il

re¸coit un signalexit?, le contrôleur décrémente la même variable, si elle tombe à zéro, le

dernier train vient de quitter les barri`eres et un signalup! leur est envoy´e. La figure 5.2

donne l’automate mod´elisant le contrˆoleur.

.

.

Idle

c≤cM AppDown

c≤cM ExitUp

·|app?|c:=0 c≥cm|down!|n:=n+1

n=1|exit?|c:=0

c≥cm|up!|n:=0

n>1|exit?|n:=n−1

clock c, int n:=0

Figure 5.2 —L’automate temporiséController représentant le contrôleur. Il

utilise une variable entièreninitialisée à zéro et un chronomètrec.

Le syst`eme complet est obtenu comme le produit synchronis´e dencopies de l’automate

Train (nomm´ees Traini, pour 1 ≤ i ≤n) et des automates Gates et Controller. Nous

obtenons un automate permettant l’ex´ecution entrelac´ee de tous ceux qui le composent

avec synchronisation sur les actions telles que app! etapp?.

La propriété de sécurité et d’absence de blocage peut s’exprimer par une formule de

logique temporelle (dans une variante de CTL) :

∀¤³

¬deadlock´

∧³

g≤g_M

Figure 5.1 — A gauche, l’automate^` Train, mod´elisant une voie et le train

(Train₁.Inside∨ · · · ∨Trainn.Inside)⇒Gates.Closed´

• le M-net représentant le contrôleur à l’identificateur 0, nous fixons doncm0=^df cM;

• le M-net mod´elisant les barri`eres utilise l’identificateur 1 et nous posonsm1 =^df gM;

=aM etm2i+1=^df eM.

clock(id,c,c⁰)

{(0,c0),...,(nc,c_nc)} {(0,c0+1),...,(nc,c_nc+1)}

gates Open \down,clock(1,g,0) _GoDown \down