Composition des ´el´ements Pola

Il est temps de donner la s´emantique de composition des ´el´ements du langage Pola. En r´ealit´e elle est tr`es simple, puisqu’elle se contente des deux op´erations ◦ et⊙. La juxtaposition de r´eseaux ◦

est utilis´ee pour la composition des ´el´ements d´eclaratifs, tandis que ⊙ est utilis´ee pour composer un comportement au reste du syst`eme.

Chaque ´el´ement d´eclaratif est traduit dans un motif x qui sont regroup´es dans un ensembles M. De mˆeme tous les comportements sp´ecifiques sont stock´es dans l’ensemble C. La s´emantique de la sp´ecification du mod`elePola est donn´e par la composition suivante, dont le r´esultat est le r´eseau de Petri P :

P = (^K

y∈C

y)⊙(x∈Mx) (5.13) Tous les noms de places et de transitions des comportements sont prot´eg´es (c’est-`a-dire qu’il ne peut y avoir de conflits de noms entre les comportements et entre les motifs et les comportements), par cons´equent seule la composition par ´etiquette peut rendre ces r´eseaux interd´ependant du r´eseau g´en´er´e donnant la s´emantique du cœur d´eclaratif du langage.

La composition des motifs du cœur d´eclaratif est accomplie par la fusion des places qui servent d’interface aux motifs.

5.8 Conclusion

Nous avons donn´e dans ce chapitre la s´emantique du langage Polaen terme de r´eseaux de Petri `a inhibitions/permissions. Notre objectif initial ´etait d’appr´ecier, en ce faisant, l’ad´equation desipTPN

pour la mod´elisation du sous-ensemble des syst`emes temps r´eel dont le p´erim`etre est d´efini parPola. Nous avons vu que le formalisme desipTPN permet effectivement de donner une s´emantique `aPola. Seule la s´emantique des politiques dynamiques n’a pas ´et´e donn´ee, mais il a ´et´e remarqu´e que certaines de ces politiques dynamiques sont traduisibles, tandis que pour d’autres, cette traduction est tr`es vraisemblablement impossible `a donner.

Nous avons ´egalement vu que la s´emantique d’un ordonnanceur en ipTPN est hautement explosif, ce qui correspond `a la forte combinatoire de l’´el´ement allocation. Dans cette traduction, la combinatoire est report´ee dans le mod`ele, mais pourrait ˆetre sˆurement d´eport´ee uniquement dans l’analyse en utilisant des donn´ees et des structures de contrˆole plus flexibles pour sp´ecifier cet ordonnanceur de mani`ere plus concise.

113

Chapitre 6

L’outil Pola : Etudes de cas et

exp´erimentations

La s´emantique du langagePolapermet de donner une repr´esentation du langage exprim´ee selon le formalisme des r´eseaux de PetriipTPN. La traduction issue de la s´emantique donn´ee dans le chapitre pr´ec´edent, ainsi que la chaˆıne de v´erification automatique a fait l’objet d’une impl´ementation que nous pr´esentons dans ce chapitre. La v´erification desipTPN n’´etant pas encore suffisamment mature, nous avons pr´ef´er´e utiliser une impl´ementation ant´erieure n’utilisant qu’une variante de la relation d’inhibition, la relation de priorit´e utilis´ee dans [BPV07]. La traduction dePola dans ce formalisme n’est que partielle, car il souffre de probl`emes de composition, mais permet n´eanmoins la v´erification des cas d’´etudes propos´es. Le lecteur pourra oublier ce fait au cours de la lecture du chapitre, tout en gardant `a l’esprit que les nombres issus de la v´erification ne sont donc qu’indicatifs. En effet, la traduction utilisant uniquement la relation de priorit´e introduit des comportements passagers ´etrangers `

a la s´emantique de Pola qui ne sont pr´esents qu’`a des fins de codage de la s´emantique, grossissant ainsi la taille du graphe de comportement.

La chaˆıne de v´erification de l’outil Pola est exp´eriment´ee sur des exemples reprenant les cas d’´etudes ´etudi´es dans le chapitre 4. Ces mod`eles sont d´eclin´es en variations nous permettant d’exhiber des facteurs de complexit´e et de donner une estimation des limites de l’approche automatique.

6.1 Architecture

Le but d’un langage sp´ecifique est de permettre `a l’utilisateur d’utiliser un langage le plus proche s´emantiquement des syst`emes qu’il a `a mod´eliser et `a v´erifier. Une attention toute particuli`ere a ´et´e apport´ee pour que ce soit le seul langage qu’il ait `a manipuler : il serait dommage qu’il soit oblig´e de manipuler d’autres formalismes, pas forc´ement aussi bien adapt´es `a son domaine, lors des ´etapes de la chaˆıne de v´erification. Ceci est bien sˆur une ligne de conduite id´eale qu’il n’est pas toujours possible de tenir. N´eanmoins ce but a conditionn´e la construction de notre architecture. Puisque seul le langage

Polaest suppos´e connu, tout le reste du processus de v´erification doit ˆetre au maximum d´eduit. La premi`ere ´etape de la chaˆıne de v´erification consiste en la g´en´eration d’un r´eseau de Petri tem-porel (avec les extensions n´ecessaires). Associ´e `a ce r´eseau, une batterie de formuleLTLest extraite du mod`elePola, selon les propri´et´es attendues dans le mod`ele. Le r´eseau est ensuite pass´e en entr´ee d’un explorateur d’´etats, permettant la construction d’un graphe d’´etats exhaustif, repr´esentant l’ensemble des comportements du syst`eme et pr´eservant la logiqueLTL. La validit´e des formules g´en´er´ees un peu plus tˆot est alors v´erifi´ee par unmodel checker. Le r´esultat de la v´erification de l’ensemble des formules est alors transmis `a l’utilisateur.

L’architecture que nous venons de pr´esenter est r´esum´e par le sch´ema de la figure 6.1.

Ceci donne l’aspect id´eal du processus automatique. Mais cette automaticit´e n’est pas toujours possible. Deux raisons (et un troisi`eme moins importante) `a cela.

Fig.6.1 – Architecture de l’outil Pola

exploiter la s´emantique est soumis `a une barri`ere th´eorique, appel´ee ind´ecidabilit´e affirmant qu’au del`a d’une certaine expressivit´e, il existe des questions pour lesquelles il n’est plus possible d’utiliser un unique proc´ed´e (un algorithme) y r´epondant `a tous les coups (c’est-`a-dire pour tout mod`ele que l’on a voulu soumettre `a la question1). C’est le cas pour les r´eseaux de Petri temporels utilisant des chronom`etres : il n’est pas possible d’avoir un algorithme (donc terminant au bout d’un temps fini) permettant de donner tous les ´etats accessibles`a coup sˆur. Par contre, il est possible d’avoir un

«algorithme_»donnant une r´eponse (en temps fini) pour certains mod`eles. Le terme desemi-algorithme est pr´ef´er´e et c’est un telsemi-algorithme d’exploration que nous utilisons pour obtenir l’ensemble des comportements d’un r´eseau utilisant des arcs `a chronom`etre.

Il est donc certains mod`eles que notre processus ne pourra pas traiter pour une cause th´eorique, mais en plus de cela, il est un autre probl`eme, pratique cette fois, empˆechant le processus de donner une r´eponse. Lorsqu’on souhaite savoir si le syst`eme respecte telle ou telle propri´et´e, il est pr´esuppos´e que c’est pour tous les cas possibles. C’est-`a-dire que certaines propri´et´es, comme “il n’y a jamais de panne dans le syst`eme”, doivent s’assurer de l’absence de panne pour toutes les ex´ecutions et/ou configurations possibles. Nous l’avons d´ej`a vu, c’est le graphe qui repr´esente le comportement du syst`eme, et c’est `a partir de lui qu’une propri´et´e est contrˆol´ee. Cela signifie qu’il est primordial d’avoir l’ensemble du graphe pour obtenir une r´eponse correcte `a une question du type absence de pannes. Or plus un syst`eme est complexe, plus son graphe de comportement est gros, sans que l’on puisse ni imposer, ni pr´evoir de borne maximale `a la taille du graphe complet. Par contre, la m´emoire dans laquelle est rang´ee ce graphe est, elle, born´ee. D’o`u l’impossibilit´e pratique de stocker en m´emoire certains comportement trop importants (soit par leur complexit´e, soit par leur longueurs, etc. Les causes ´etant tr`es nombreuses). Ce ph´enom`ene est appel´eexplosion combinatoire, en raison du rapport de taille entre le mod`ele que l’on souhaite v´erifier et son graphe de comportement.

Plutˆot qu’un probl`eme de taille m´emoire, il existe une version temporelle de l’explosion combina-toire : l’ensemble des ´etats ´etant si long `a calculer que le coˆut de l’analyse devient prohibitif, mˆeme si le graphe peut effectivement tenir en m´emoire.

Un troisi`eme aspect, moins critique, est que la formule donn´ee en entr´ee du model-checker n’est pas fournie explicitement par l’utilisateur. En effet, comme nous l’avons d´ej`a pr´ecis´e, l’utilisateur n’a pas `a avoir de connaissances sur le langage de formules utilis´e et de plus nous n’avons pas de moyens, `

a l’heure actuelle, de sp´ecifier `a l’int´erieur d’un mod`elePolales propri´et´es attendues. C’est pourquoi nous avons utilis´e des propri´et´es tr`es courantes, utiles dans beaucoup de situations. Pour prendre en compte d’autres propri´et´es, il faut donc ajouter manuellement les formules correspondantes. Mais, une fois cette ´etape accomplie, le processus redevient automatique.

1

6.1. Architecture 115