Analyse du mod`ele

On se propose ici de montrer comment on peut utiliser notre mod`ele TLA et le model-checker TLC pour ´etudier l’ordonnan¸cabilit´e du syst`eme. Les diff´erentes tˆaches du mod`ele AADL pr´esent´e ont les propri´et´es temporelles suivantes :

Syst PL PF AOCS AOCS ACC COMP

MAN

Type P´erio P´erio P´erio P´erio Ap´er Ap´er Ap´er

P´eriode 125 125 125 125 Temps 25 18 12 35 12 10 8 d’ex´ecution Priorit´e 205 195 185 55 35 40 41 ´ Ech´eance 100 100 100 100 80 80 80

Le syst`eme pr´esent´e est ordonnan¸cable. Normalement le model-checker ne donne pas d’informations lorsque les propri´et´es d’un syst`eme sont va-lid´ees. Il indique juste que la v´erification est r´eussie et le nombre d’´etats g´en´er´es (310 dans notre cas). Afin de pouvoir observer le comportement du syst`eme, on a ajout´e au code TLA des directives permettant de suivre

6.1. MOD `ELE D’ANALYSE D’ORDONNANCEMENT SIMPLE 115

l’´evolution de l’´evaluation de la v´erification. Ainsi, `a chaque activation de tˆache, d´ebut ou reprise d’ex´ecution, verrouillage ou lib´eration d’une res-source, et fin d’ex´ecution, on demande `a TLC de nous afficher une partie de l’´etat du syst`eme. L’op´eration permettant de demander `a TLC d’afficher une chaine de caract`ere se nomme PrintT. On ajoute a l’op´eration Dispatch l’ac-tion suivante : PrintT( dispatch of the task , th, date ,now). Lors de chaque activation de tˆache TLC affichera donc la ligne correspondante ; la variable th repr´esente le thread activ´e, la variable now nous permet de suivre l’enchaˆınement temporel des actions. Lorsque une tˆache prend la res-source processeur, on affiche le message start of the task, suivi du nom de la tˆache et de la date. `A la terminaison d’une tˆache, on donne le nom de la tˆache, la date ansi que le temps restant avant son ´ech´eance. Enfin, lors-qu’une resource est v´erouill´ee ou relach´ee on affiche le nom de la ressource, le nom de la tˆache qui y acc`ede et la date.

<< "dispatch of the task", "aocs", "date", 0 >> << "dispatch of the task", "pf", "date", 0 >> << "dispatch of the task", "pl", "date", 0 >> << "dispatch of the task", "syst", "date", 0 >> << "start of the task", "syst", "date", 0 >>

<< "end of the task", "syst", "date", 25, "laxity", 75 >> << "start of the task", "pl", "date", 25 >>

<< "end of the task", "pl", "date", 43, "laxity", 57 >> << "dispatch of the task", "comp", "date", 43 >>

<< "dispatch of the task", "acc", "date", 43 >> << "start of the task", "pf", "date", 43 >>

<< "end of the task", "pf", "date", 55, "laxity", 45 >> << "start of the task", "aocs", "date", 55 >>

<< "end of the task", "aocs", "date", 90, "laxity", 10 >> << "dispatch of the task", "aocs_man", "date", 90 >> << "start of the task", "comp", "date", 90 >>

<< "lock resource", "sd", "comp", "date", 92 >> << "release resource", "sd", "comp", "date", 94 >>

<< "end of the task", "comp", "date", 100, "laxity", 23 >> << "start of the task", "acc", "date", 100 >>

<< "lock resource", "sd", "acc", "date", 102 >> << "release resource", "sd", "acc", "date", 104 >>

<< "end of the task", "acc", "date", 108, "laxity", 15 >> << "start of the task", "aocs_man", "date", 108 >>

<< "end of the task", "aocs_man", "date", 120, "laxity", 50 >> << "dispatch of the task", "aocs", "date", 125 >>

<< "dispatch of the task", "pf", "date", 125 >> << "dispatch of the task", "pl", "date", 125 >> << "dispatch of the task", "syst", "date", 125 >>

<< "start of the task", "syst", "date", 125 >>

<< "end of the task", "syst", "date", 150, "laxity", 75 >> << "start of the task", "pl", "date", 150 >>

<< "end of the task", "pl", "date", 168, "laxity", 57 >> << "dispatch of the task", "comp", "date", 168 >>

<< "dispatch of the task", "acc", "date", 168 >> << "start of the task", "pf", "date", 168 >>

<< "end of the task", "pf", "date", 180, "laxity", 45 >> << "start of the task", "aocs", "date", 180 >>

<< "end of the task", "aocs", "date", 215, "laxity", 10 >> << "dispatch of the task", "aocs_man", "date", 215 >> << "start of the task", "comp", "date", 215 >>

<< "lock resource", "sd", "comp", "date", 217 >> << "release resource", "sd", "comp", "date", 219 >>

<< "end of the task", "comp", "date", 225, "laxity", 23 >> << "start of the task", "acc", "date", 225 >>

<< "lock resource", "sd", "acc", "date", 227 >> << "release resource", "sd", "acc", "date", 229 >>

<< "end of the task", "acc", "date", 233, "laxity", 15 >> << "start of the task", "aocs_man", "date", 233 >>

<< "end of the task", "aocs_man", "date", 245, "laxity", 50 >> << "dispatch of the task", "aocs", "date", 250 >>

<< "dispatch of the task", "pf", "date", 250 >> << "dispatch of the task", "pl", "date", 250 >>

Ces informations nous permettent de d´efinir la figure 6.2. Cette figure est cr´e´ee manuellement mais on peut tr`es bien imaginer une g´en´eration au-tomatique de cette figure `a partir de la trace TLC. Dans cette figure on voit que les tˆaches p´eriodiques sont ex´ecut´ees en premier. `A la fin de la tˆache PL, les tˆaches ACC et COMP sont activ´ees. De mˆeme, `a la fin de la tˆache AOCS, on active la tˆache AOCS MAN. Ces tˆaches sont ap´eriodiques, elles sont activ´ees par une simple r´eception d’´ev´enement.

On peut rendre ce syst`eme non ordonnan¸cable, il suffit par exemple d’augmenter la priorit´e des tˆaches ACC et COMP pour qu’elles soient ex´ecu-t´ees avant la tˆache AOCS. Dans ce cas, TLC produit une trace dont le dernier ´etat est reproduit ici. TLC affiche l’ensemble des variables du syst`eme sous la forme d’une conjonction. On va par exemple retrouver les variables d´efi-nissants l’´etat de chaque thread :

– ready = {”aocs”},

– computing thread = aocs, – awaiting resource = {},

– awaiting dispatch = {”pf ”, ”pl ”, ”syst”, . . .}.

On peut regarder le contenu des ports du syst`eme `a cet instant, ainsi l’expression :

6.1. MOD `ELE D’ANALYSE D’ORDONNANCEMENT SIMPLE 117 acc comp aocs pf pl syst aocs_man 0 25 43 55 90 100 108 120 125

Fig. 6.2 – Ordonnancement du syst`eme g´en´er´e par TLC.

iep delivered = [aocs man calc 7→ 0, comp comp 7→ 1, acc acc 7→ 1]

nous indique que le port calc ne contient aucun ´el´ement, et que les ports comp et acc en contiennent un. On voit sur la derni`ere ligne que l’horloge associ´ee `a l’´ech´eance de la tˆache AOCS est pass´ee `a -1. Ceci signifie dans notre mod`ele que cette tˆache n’a pas pu respecter son ´ech´eance.

STATE125 : < Actionline659, col 3toline681, col 69ofmoduleThreads > ∧ currentMode =“mode1”

∧ last output port time = [aocs 7→ − 1, pf 7→ − 1, pl 7→ − 1, syst 7→ − 1, aocs man7→ − 1, comp 7→ − 1, acc 7→ − 1]

∧ now = 101

∧ out event buffer = [aocs calc 7→ false, pl acc 7→ true, pl comp 7→ true] ∧ event data connection = [syst TC port 7→ {“aocs TC port”,

“pf TC port”, “pl TC port”}] ∧ awaiting mode = {} ∧ ready = {“aocs”}

∧ awaiting dispatch = {“pf”, “pl”, “syst”, “aocs man”, “comp”, “acc”} ∧ out data fresh = [aocs dt 7→ false]

∧ triggering events = [aocs 7→ {}, pf 7→ {}, pl 7→ {}, syst 7→ {}, aocs man7→ {}, comp 7→ {}, acc 7→ {}]

∧ internal mode = [aocs 7→“mode aocs”, pf 7→“mode pf”, pl 7→“mode pl”, syst 7→“mode syst”, aocs man 7→“mode aocs man”,

comp7→“mode comp”, acc 7→“mode acc”]

∧ event connection = [aocs calc 7→ {“aocs man calc”}, pl acc 7→ {“acc acc”}, pl comp7→ {“comp comp”}]

∧ internal state = [aocs 7→ 0, pf 7→ 0, pl 7→ 18, syst 7→ 25, aocs man7→ 0, comp 7→ 0, acc 7→ 0]

∧ last access resource = (h“sd”, “comp”i :> 4 @@ h“sd”, “acc”i :> 4) ∧ iedp delivered = [aocs TC port 7→ h i, pf TC port 7→ h i, pl TC port7→ h i]

∧ computing thread =“aocs” ∧ awaiting resource = {}

∧ out data buffer = [aocs dt 7→ 11]

∧ out event fresh = [aocs calc 7→ false, pl acc 7→ true, pl comp 7→ true] ∧ AccessedBy = [sd 7→“bot thread”]

∧ out event data buffer = [syst TC port 7→ 7]

∧ iep event cpt = [aocs man calc 7→ 0, comp comp 7→ 0, acc acc 7→ 0] ∧ last input port time = [aocs 7→ − 1, pf 7→ − 1, pl 7→ − 1, syst 7→ − 1, aocs man7→ − 1, comp 7→ − 1, acc 7→ − 1]

∧ iep delivered = [aocs man calc 7→ 0, comp comp 7→ 1, acc acc 7→ 1] ∧ idp fresh = [aocs man dt 7→ false]

∧ idp delivered = [aocs man dt 7→ 11]

∧ out event data fresh = [syst TC port 7→ false]

∧ iedp fresh = [aocs TC port 7→ false, pf TC port 7→ false, pl TC port7→ false]

∧ idp env = [aocs man dt 7→ 11]

∧ actual Priority = [bot thread 7→ 0, aocs 7→ 55, pf 7→ 185, pl 7→ 195, syst 7→ 205, aocs man 7→ 0, comp 7→ 60, acc 7→ 61]

∧ currentTransition =“bot trans”

∧ iep fresh = [aocs man calc 7→ false, comp comp 7→ true, acc acc 7→ true] ∧ period timer = [aocs 7→ 24, pf 7→ 24, pl 7→ 24, syst 7→ 24]

∧ data connection = [aocs man dt 7→“aocs dt”]

∧ iedp event data queue = [aocs TC port 7→ h7i, pf TC port 7→ h7i, pl TC port7→ h7i]

∧ execution timer = [aocs 7→ 28, pf 7→ 12, pl 7→ 18, syst 7→ 25, aocs man7→ 0, comp 7→ 10, acc 7→ 8]

∧ deadline timer = [aocs 7→ − 1, pf 7→ 0, pl 7→ 0, syst 7→ 0, aocs man7→ 0, comp 7→ 22, acc 7→ 22]

La trace compl`ete de l’ex´ecution amenant `a cet ´etat est constitu´e par 125 ´etats similaires `a celui-ci. Il est toutefois possible de demander `a TLC de n’afficher que les variable modifi´ees entre deux ´etats. Une trace compl`ete donne suffisamment d’informations pour d´eduire le comportement du mod`ele AADL. Dans l’optique de proposer un outil plus complet, on peut envisager d’utiliser ces informations pour pr´esenter ce comportement graphiquement.