Les observateurs de propriétés

Une des principales et plus grandes difficultés rencontrées dans notre travail a été l’analyse et l’exploitation des résultats de vérifications des bonnes propriétés des réseaux de Petri. En particulier, dans des contextes d’utilisateurs non-spécialistes en modélisation, selon ce type de formalisme, il convient de réaliser une interface facilitant l’interprétation des résultats. D’un autre côté, TINA est un outil très spécialisé qui contient beaucoup de fonctionnalités, que le concepteur – non-spécialiste - ne saura pas exploiter complètement.

Considérons l’analyse des « bonnes propriétés » des réseaux de Petri [Jim00] qui peuvent révéler dans quelques cas des caractéristiques associées au système qu’ils décrivent :

• « Un réseau de Petri est dit vivant pour un marquage donné si à partir d’un marquage accessible quelconque, toute transition peut être sensibilisée après une séquence de tir appropriée. Pour le système physique modélisé, la vérification de cette propriété du modèle indique la non-existence de situations de blocage.

• Quelle que soit l’évolution du réseau de Petri borné, il existe une limite finie au nombre de jetons dans le réseau. Cette propriété peut être liée à la capacité limité de calcul ou de traitement d’un système.

• Dans un réseau réinitialisable, il est toujours possible de trouver une séquence de tir qui ramène au marquage initial. Cette propriété est très utile lorsqu’on modélise (et c’est très souvent le cas) des systèmes à caractère cyclique ou répétitif. ».

• A un niveau général, un marquage du réseau de Petri peut être interprété comme un état global du système et un changement du marquage correspond à une transition d’état.

La vérification des bonnes propriétés pourrait être un premier élément de vérification pour le concepteur. L’outil va attirer son attention sur les places ou transitions identifiées comme problématiques. Nous avons fait en sorte que HiLeS Designer affiche des alertes en indiquant les

possibles sources de problèmes, mais la correction de ces anomalies est une tâche réservée au concepteur.

Malheureusement, la tâche de récupération et d’interprétation des résultats s’avère compliquée, et, lorsque l’on n’est pas un spécialiste, il est très facile de se « noyer » dans la complexité des fichiers de sortie générés par TINA. Voyons ci-dessous les résultats de l’analyse du réseau de la Figure 3-7a.

Tina version 2.6.7 -- 05/28/04 -- LAAS/CNRS mode -R

INPUT NET --- parsed net exemple_TINA

4 places, 6 transitions net exemple_TINA tr Tr_1 Pl_1 -> Pl_2 tr Tr_2 Pl_2 -> Pl_3 tr Tr_3 Pl_2 -> Pl_4 tr Tr_4 Pl_3 -> Pl_1 tr Tr_5 Pl_4 -> Pl_1 tr Tr_6 Pl_3 Pl_4 -> Pl_1 pl Pl_3 (1) pl Pl_4 (1) 0.000s REACHABILITY ANALYSIS --- bounded 14 marking(s), 26 transition(s) MARKINGS: 0 : Pl_3 Pl_4 1 : Pl_1 Pl_4 2 : Pl_2 Pl_4 3 : Pl_4*2 4 : Pl_1 Pl_2 5 : Pl_2*2 6 : Pl_2 Pl_3 7 : Pl_3*2 8 : Pl_1 Pl_3 9 : Pl_1*2 10 : Pl_1 11 : Pl_2 12 : Pl_3 13 : Pl_4 REACHABILITY GRAPH: 0 -> Tr_4/1, Tr_5/8, Tr_6/10 1 -> Tr_1/2, Tr_5/9 2 -> Tr_2/0, Tr_3/3, Tr_5/4 3 -> Tr_5/1 4 -> Tr_1/5, Tr_2/8, Tr_3/1 5 -> Tr_2/6, Tr_3/2 6 -> Tr_2/7, Tr_3/0, Tr_4/4 7 -> Tr_4/8

8 -> Tr_1/6, Tr_4/9 9 -> Tr_1/4 10 -> Tr_1/11 11 -> Tr_2/12, Tr_3/13 12 -> Tr_4/10 13 -> Tr_5/10 0.000s LIVENESS ANALYSIS --- not live

0 dead marking(s), 4 live marking(s) 0 dead transition(s), 5 live transition(s) STRONG CONNECTED COMPONENTS: 1 : 0 1 2 3 4 5 6 7 8 9 0 : 10 11 12 13 SCC GRAPH: 1 -> Tr_4/1, Tr_5/1, Tr_6/0, Tr_1/1, Tr_2/1, Tr_3/1 0 -> Tr_1/0, Tr_2/0, Tr_3/0, Tr_4/0, Tr_5/0 0.000s ANALYSIS COMPLETED ---

Il s’agit encore d’un exemple très simple dans lequel la lisibilité reste accessible pour identifier facilement les bonnes propriétés. Cependant, dans des modèles plus grands, les états à évaluer peuvent générer des fichiers très longs ou même faire diverger la simulation. Cette complexité, ainsi que la difficulté de traduire les « bonnes propriétés » en « propriétés métier » nous ont amené à chercher des moyens plus conviviaux d’utilisation. De plus, la seule analyse des bonnes propriétés de réseau de Petri ne garantit pas une correspondance directe avec les caractéristiques opérationnelles du système. C’est pour cela que le besoin de réaliser d’autres analyses s’impose. En gros, l’objectif, au-delà du fait que le réseau soit borné, vivant ou reinitialisable, est de vérifier qu’il représente bien le comportement attendu du système.

Nous avons donc réfléchi à ce problème et nous avons conçu et développé une première version d’un mécanisme qui vise à rendre plus aisé l’usage de cet outil. L’idée est de pouvoir vérifier des propriétés concrètes à un ou plusieurs endroits du projet. Sur cette base le concepteur doit pouvoir « poser des questions » liées à son domaine de connaissances et associées au comportement du système. Ces questions doivent pouvoir s’associer aux éléments de description fournis par HiLeS, notamment les places et transitions des réseaux de Petri et les blocs contenant d’autres sous réseaux à l’intérieur. Notre proposition est de mettre en place des « observateurs » permettant de vérifier des conditions de fonctionnement très précises du système en bénéficiant de la représentation système de HiLeS. En pratique, au niveau de l’interface graphique de HiLeS Designer, les objets ayant un observateur associé sont étiquetés avec des « lunettes bleues » tel que l’illustre la Figure 3-8.

La mise en œuvre des observateurs n’a pas que des effets sur l’interface graphique. Au niveau de la passerelle HiLeS Designer – TINA, elle implique des modifications de structure des netlist. Il a fallu rajouter des lignes à la fin du fichier correspondantes aux observateurs et aux propriétés à vérifier.

Figure 3-8. Illustration des observateurs représentés par des lunettes à coté des places dans un projet HiLeS Designer 0.

Afin d’illustrer de manière générale cette implémentation, reprenons l’exemple de la Figure 3-7a : Nous définissons un observateur sur la place Pl_4. Ensuite, en utilisant l’interface HiLeS Designer, nous y associons la propriété (PR_A) à vérifier. Notre outil génère donc, une netlist légèrement modifiée incluant ces observateurs. Sur la Figure 3-9a, nous montrons une capture d’écran de HiLeS Designer avec un observateur sur la place Pl_4. A droite (Figure 3-9b) de l’image, la netlist incluant en dernière ligne, on peut lire la propriété PR_A que l’on souhaite vérifier. TINA va pouvoir interpréter cette version de netlist dite « augmentée ».

net Watchpoint_Analysis_exemple_tina2 tr Tr_1 [0,w[ Pl_1 -> Pl_2 tr Tr_2 [0,w[ Pl_2 -> Pl_3 tr Tr_3 [0,w[ Pl_2 -> Pl_4 tr Tr_4 [0,w[ Pl_3 -> Pl_1 tr Tr_5 [0,w[ Pl_4 -> Pl_1 tr Tr_6 [0,w[ Pl_3 Pl_4 -> Pl_1 pl Pl_3 (1) pl Pl_4 (1) pr PR_A Pl_4

a. Un observateur sur la place Pl_4 b. Netlist équivalente du réseau.

Figure 3-9. Exemple de génération d’une netlist lorsqu’il y a des observateurs associés. Ici, l’observateur est placé sur Pl_4

Ainsi, en phase opérationnelle et grâce à ce principe des observateurs, l’utilisateur de HiLeS Designer pourra « poser » des questions simples et concrètes sur le comportement temporel général du système en cours de conception :

• des statistiques sur l’occurrence d’événements :

o Les listes d’occurrences des événements

o La liste des événements parallèles et concurrents

• la détermination de la nature cyclique du système,

• la détermination des blocages,

• l’estimation de la séquence globale du système en regroupant des événements consécutifs,

• la vérification de l’occurrence des conséquences suite à un événement particulier,

• événements non atteignables,

• ou bien la génération d’un graphe simplifié du comportement du système permettant de « lire » plus facilement ce que le réseau représente.