Thesis
Reference
High-level Petri net model checking : the symbolic way
HOSTETTLER, Steve Patrick
Abstract
Although model checking is heavily used in the hardware domain, its use is not mainstream in software engineering yet. Modeling of software system is tedious using low-level formalisms such as Place/Transition Petri Nets. Moreover, usual verification techniques (e.g., state space analysis) are often intractable because of the infamous State Space Explosion. While modeling can be eased by using high-level formalisms such as High- level Petri Nets that make models more concise and more readable, State Space Explosion is still an important challenge. Many authors have tackled this issue on High-level Petri Nets, mostly by either modularizing the system or by reducing the states to consider (e.g., partial orders, symmetries). Most of those approaches encode the state space explicitly, i.e., the required amount of memory is linear to the number of states, which is rapidly intractable due to State Space Explosion. Symbolic Model Checking partially overcomes this problem by encoding the state space in a condensed way using Decision Diagrams and has been success- fully applied to Place/Transition Petri Nets. Albeit very [...]
HOSTETTLER, Steve Patrick. High-level Petri net model checking : the symbolic way. Thèse de doctorat : Univ. Genève, 2011, no. Sc. 4380
URN : urn:nbn:ch:unige-218447
DOI : 10.13097/archive-ouverte/unige:21844
Available at:
http://archive-ouverte.unige.ch/unige:21844
Disclaimer: layout of this document may differ from the published version.
1 / 1
UNIVERSITÉ DE GENÈVE FACULTÉ DES SCIENCES Département d’Informatique Professeur D. Buchs
High-Level Petri Net Model Checking
The symbolic way
THÈSE
présentée à la Faculté des sciences de l’Université de Genève pour obtenir le grade de Docteur ès sciences, mention informatique
par
Steve Hostettler de
France
Thèse No 4380
Genève
Atelier d’impression ReproMail 2012
Remerciements
Cette thèse n’aurait pas été possible sans le concours de nombreuses personnes très importantes.
Pr. Didier Buchs J’aimerai remercier le Pr. Didier Buchs pour m’avoir donné l’opportunité de travailler avec lui et son équipe à l’université de Genève.
Il m’a fourni l’environnement et les ressources pour mener à bien ce projet.
Je lui exprime toute ma reconnaissance pour sa gentiellesse, son amitié et sa persévérance à m’enseigner la beauté et l’utilité des approches formelles.
Il m’a également appris le subtil mélange de conseil et de la supervision nécessaire à la direction d’une thèse afin de ne pas l’étouffer. Il m’a toujours été d’une grande aide lors de mes périodes de doutes.
Ma famille J’aimerai exprimer mon amour et ma gratitude à ma famille et à mes amis ; pour leur aide, leur amour et leur compréhension. Même si ils n’ont pas toujours compris pourquoi j’ai commencé cette thèse, ils n’ont eu de cesse de m’encourager. Un remerciement spécial pourNathalie&Alyssia à qui je dédicace cette thèse. Jour après jour, leur amour et leurs sourires m’ont aidé à finir ce travail.
Les membres du jury Je remercie les membres de mon jury de thèse pour leurs conseils et leurs commentaires avant et pendant la défense de thèse : Pr. J.-M Couvreur, Pr. G. Di Marzo Serugendo, Pr. F. Kordon et le Dr. K. Lampka. Un remerciement spécial pour Didier Buchs et Kai Lampka et leur relecture en profondeur de cette thèse et leurs com- mentaires détaillés qui m’ont permis de l’améliorer.
Mes collègues du laboratoire SMV Ma gratitude va également à mes collègues du laboratoire de modélisation et de vérification de logiciel Software Mo- deling and Validation Laboratory de Genève et plus spécialement à Alexispour son amitié et son énorme travail surAlgebraic Petri Nets Ana- lyzer (AlPiNA). Alexis, AlbanetEdmundoméritent un bonne douzaine de bières (chacun) pour avoir analysé chaque formule et cherché chaque erreur.
Toutes les erreurs restantes sont les miennes.Matteo,Luiset les autres pour i
avoir contribué à la bonne ambiance du groupe et de ce fait au succès de ce travail. J’aimerai également remercier mes co-auteurs pour m’avoir autorisé à utiliser le matériel (surtout, [HML+12]) que nous avons publié ensemble, dans ce manuscrit.
La fondation Hasler Ce travail a été partiellement financé par lafondation Has- lerau travers du projetCOMEDIAde l’initiativeManComnuméro #2107.
Mes anciens collègues Finalement, je remercie Juerg Baumgartner et André Winterhalter pour m’avoir donné mon premier travail d’ingénieur. J’ai beaucoup appris sous leur supervision. Merci à Juerg, Rainer Gempp et Arnaud Simonpour leur confiance (et leur lettre de recommandation) dans ma capacité à mener à bien ce doctorat.
Acknowledgments
This dissertation would not have been possible without the support of numerous important people.
Pr. Didier Buchs I would like to thank Pr. Didier Buchsfor the opportunity to work with him and his team at the University of Geneva. He provided the environment and resources that allowed me to develop the present work. I express my recognition for his friendliness and his perseverance in teaching me the beauty and the usefulness of formal approaches. He also teached the subtil mix of advice and direct supervision that is required to supervise a thesis without stifling it. He has always offered invaluable assistance when I doubted about the direction of this work.
My familly I wish to express my love and gratitude to my beloved relatives; for their understanding & endless love. Even if they did not always understand why I started my PhD, they indefectibly supported and encouraged me. A special thank goes toNathalie&Alyssia to whom I dedicated this thesis.
Day after day, their love and their smiles helped me to complete this work.
The jury members Let me thanks the members of my jury for their useful ad- vises and comments before and during the defense: Pr. J.-M Couvreur, Pr. G. Di Marzo Serugendo, Pr. F. Kordon, and Dr.K. Lampka. A spe- cial thank goes toDidier BuchsandKai Lampkafor their in-depth proof read of the document and their usefull and detailled comments.
My colleagues My gratitude also goes to the members of theSoftware Model- ing and Validation Laboratoryat Geneva and especially toAlexisfor his friendship and the tons of work onAlPiNA.Alexis,Alban, andEdmundode- serve a dozen of beers for having scanned every formula and tracked drown every single possible inconsistencies. Any remaining errors are mine.Mat- teo,Luis, and the others highly contributed to the friendly atmosphere and the group and therefore the success of this work. I also would like to thanks my co-authors for authorising me to use materials in this manuscript (espe- cially, from [HML+12]) that we have published together.
iii
My Ex-colleagues Finally, let me express my gratitude toJuerg Baumgartner and André Winterhalter, for having given me my first job as a software engineer. I learned a lot under their supervision. Thanks toJuerg, Rainer Gempp, andArnaud Simon for their confidence (and letter of reference) in my ability to carry this PhD thesis through.
Hasler fundation This work was partially funded by theCOMEDIAproject of theHasler foundation, ManCom initiative project number #2107.
To Nathalie&Alyssia
Résumé
L’omniprésence des systèmes informatiques, notamment dans les activités humaines sensibles, exige d’en assurer la qualité. C’est-à-dire, de vérifier qu’un système informatique satisfasse aux spécifications imposées par le mandant. Une des façons d’atteindre ce but, est de définir le comportement du système ainsi que ses spécifications à l’aide d’une description formelle. Cette caractérisation précise et univoque du problème est appelée modèle pour les comportements et propriété pour la spécification. Il est dès lors possible, à l’aide d’une vérification formelle, de s’assurer que le comportement du système est conforme à sa spécification.
Malgré son indubitable utilité, la vérification formelle de systèmes logiciels n’est toujours pas d’usage courant dans l’industrie. Modéliser de tels systèmes à l’aide de ces méthodes est pour le moins laborieux. En effet, les langages formels ne sont souvent pas bien maîtrisés par les ingénieurs industriels et leur syntaxe, souvent lourde, les rend difficiles à appréhender. Ce problème peut être partiellement résolu par l’utilisation de langages dédiés (Domain Specific Languages (DSLs)). Ces langages masquent en partie la complexité syntaxique des approches formelles. La sémantique des DSLs est alors donnée par transformation dans un langage formel appelé domaine sémantique cible.
Celui-ci doit être syntaxiquement et sémantiquement précisément défini ainsi que suffisamment expressif pour pouvoir transformer et interpréter n’importe quel modèle exprimé dans le langage dédié. Leur expressivité, leur excellent support de la notion de concurrence font des réseaux de Petri algébriques (Algebraic Petri Nets (APNs)) un candidat idéal pour assumer le rôle dedomaine sémantique cible.
Il subsiste, cependant, un autre défi de taille. Il n’est pas rare que les sys- tèmes logiciels puissent prendre des milliards d’états différents. Or, pour mener une vérification formelle à bien, il est nécessaire d’observer chaque état afin de déterminer si oui ou non il satisfait la spécification. Ce problème, appelé explosion combinatoire de l’espace d’états(State Space Explosion (SSE)), limite fortement la taille des systèmes pouvant être vérifiés. La vérification symbolique de modèles permet de résoudre partiellement ce problème en proposant un
i
encodage de l’espace d’états dont la taille est au mieux logarithmique par rapport au nombre d’états. Cet encodage utilise des structures de données appelées diagrammes de décisions(Decision Diagrams (DDs)) qui permettent de partager les parties similaires des états et ainsi d’économiser de la mémoire. De récentes avancées dans le domaine, utilisant les diagrammes de décisions d’ensemble, ont démontré des résultats très prometteurs pour les réseaux de Petri Place/Transition (Place/Transition Petri Nets (PTs)). Parmi ces avancées citons l’agglomération (Clustering) et l’anonymisation de variables qui permettent de gagner plusieurs ordres de grandeur en termes de modèles traités. Pour être appliquées à des formalismes plus expressifs tels que les APNs, ces techniques requièrent néan- moins de déplier les modèles APNs en modèles de PTs avant la vérification.
Cette opération, requérant de fixer les bornes des domaines de valeurs utilisés, est souvent complexe et quelques fois impraticable. En effet ces bornes peuvent être difficiles voire impossibles à déterminer. Il convient néanmoins de souligner que le dépliage, bien que coûteux en tant que tel, peut potentiellement amener des gains de performances très élevés au moment de la vérification proprement dite.
Dans cette thèse, nous proposons de faire de la vérification symbolique sur les modèles de réseaux de Petri algébriques directement. A cette fin, nous pro- posons d’adapter les techniques développées pour les réseaux de PetriPTs. Nous proposons également, la notion dedépliage partiel du réseau(Partial Net Unfol- ding (PNU)) qui consiste à limiter le dépliage aux seuls domaines désignés par le concepteur du système. Cela permet à l’utilisateur de ne déplier que les domaines dont il connaît les bornes et uniquement si c’est intéressant d’un point de vue des performances.
De surcroît, nous avons également adapté les techniques d’agglomération et d’anonymisation des variables de manière à prendre en compte les spécificités des réseaux de Petri algébriques. Par ailleurs, contrairement aux PTs, les APNs consomment et produisent des structures de données complexes représentées par des termes. Les états étant constitués de termes, leur nombre explose de la même façon que les états. Il est donc nécessaire d’en fournir un encodage efficace.
Pour ce faire, nous avons développé les diagrammes de décisions de signature (ΣDecision Diagrams (ΣDDs)) s’intégrant par la même parfaitement à l’approche d’encodage par diagrammes de décisions.
La quasi-totalité (à l’exception de l’anonymisation) des techniques présentées dans ce document a été implémentée dans un outil appelé AlPiNAafin d’en prou- ver la faisabilité et l’efficacité. Pour résumer, cette thèse propose différents outils théoriques et pratiques afin de vérifier des réseaux de Petri algébriques de manière symbolique.
Version abrégée
Nous présentons ici un résumé de la thèse. Nous commencerons par exposer le contexte ainsi que la problématique liée à la sûreté des systèmes informatiques.
Puis nous verrons, en quoi et de quelle façon, la vérification systématique de mo- dèle permet d’en améliorer la qualité. Après quoi, nous analyserons également les défis qui y sont attachés. Ensuite, nous positionnerons ce travail par rapport à l’état de l’art et présenterons les différentes contributions apportées. Enfin nous détaillerons la structure du document, conclurons et terminerons par les perspec- tives d’évolution de ce travail.
Contexte et problématique
L’ubiquité des systèmes informatiques rend leur robustesse de plus en plus primor- diale. Les systèmes embarqués, tels que ceux des appareils médicaux, des automo- biles ou des avions, requièrent une sûreté de fonctionnement très élevée parce que des vies humaines sont engagées. D’autres systèmes, moins critiques du point de vue des vies humaines, tels que les téléphones portables ou les consoles de jeux re- présentent néanmoins des enjeux économiques considérables. Dans un cas comme dans l’autre un manquement à la qualité coûte très cher. Citons, par exemple, l’in- cident du Therac-25 [LT93], un appareil de traitement par radiothérapie produit par la firme AECL, qui a coûté la vie à au moins six patients entre 1985 et 1987.
Cet incident est dû, entre autre, à ce que l’on appelle une condition de course, phénomène fréquent dans le cas des systèmes multi-tâches (i.e.,concurrents), qui a conduit l’appareil à administrer une dose très élevée de radiations alors qu’une protection appelée collimateur n’était pas dans la bonne position.
Améliorer la qualité des systèmes informatiques
Il existe différents moyens d’améliorer la qualité des systèmes informatiques et cela à différents stades de leur développement [BK08]. Parmi ces moyens, sans doute l’un des plus connus et des plus employés est le test. Cette technique permet
iii
de vérifier qu’un certain nombre de scénarios respectent les spécifications données par le mandant. Bien que très efficace, cette méthode souffre de trois limitations importantes :
• L’approche par tests requiert que le système existe (au moins en partie) pour être appliquée. De ce fait les erreurs de conception ne sont détectées que tard lors du développement. Or, plus une erreur est détectée tardivement, plus elle coûte cher à corriger. Notamment, parce que problèmes de conception et de construction (i.e.,implémentation) sont mêlés.
• D’autre part, seuls un nombre limité de scénarios sont vérifiés. Si un test prouve que le système satisfait la spécification pour un scénario donné, cela ne signifie pas que ce soit le cas pour tous les scénarios.
• Certaines erreurs de conception tels que les conditions de course et les dé- passements de mémoire sont très difficiles à détecter à l’aide de tests. No- tamment parce qu’il est difficile de reproduire les conditions dans lesquelles de telles erreurs surviennent.
La vérification systématique de modèle
Les trois problèmes attachés aux tests peuvent être résolus par des méthodes de vérification formelle. Ces méthodes, et notamment la vérification de modèle (i.e.,model checking), s’appliquent très tôt dans le processus de développement d’un produit. Cette intervention précoce permet de limiter le coût de correction d’éventuelles erreurs de conception. Ces méthodes inspectent de façon systéma- tique tous les scénarios possibles d’un système. Comme souligné dans [LT93], l’incident du Therac-25 aurait pu être évité si des méthodes formelles avaient été utilisées en plus des tests. Par exemple, la condition de course aurait pu être détec- tée par une vérification systématique de l’inexistence d’un état du système dans lequel le faisceau de haute énergie est activé alors que le collimateur n’est pas en place. Cela revient à vérifier que le modèle du Therac-25 satisfait la propriété suivante
Φ :¬(collimateur en position) =⇒ ¬(faisceau de haute énergie activé) pour tous les états du système. Dans le cas qui nous occupe, une vérification for- melle aurait signalé qu’il existe un état dans lequel le flux à haute énergie est actif alors que le collimateur n’est pas en position. Cet état, appelé contre-exemple de la propriété, est retourné au concepteur afin qu’il améliore le modèle ou qu’il corrige la propriété.
Principales limites des méthodes formelles
Malgré son indiscutable utilité, la vérification formelle et systématique de logi- ciels n’est pas encore d’usage courant et cela pour plusieurs raisons :
• La complexité et la lourdeur syntaxique des langages formels de modélisa- tion. En effet de tels langages sont souvent très proches des mathématiques et éloignés du domaine traité par le concepteur du système.
• Toute vérification formelle est au maximum aussi bonne que le modèle du système et les spécifications utilisés. En d’autres termes, si le modèle (ou la spécification) est faux alors la vérification le sera également. Le concepteur doit avoir confiance dans le fait que son modèle et que ses spécifications sont conformes aux attentes de son mandant. Pour cela le concepteur doit impé- rativement comprendre la signification (i.e.,la sémantique) de son modèle et de ses spécifications. Dans la norme IEEE-STD-610 [IEE90], le processus qui assure que les spécifications reflètent bien les attentes du mandant est appelé validation.Contrairement à la validation, la vérificationse propose de s’assurer que l’implémentation est conforme aux spécifications.
• La complexité des systèmes modélisés. Il n’est pas rare que le nombre d’états atteigne le millier de milliards voire beaucoup plus. Ce problème est appelé explosion combinatoire de l’espace d’états. Manipuler de telles quantités d’états est très difficile et requiert des techniques et des connais- sances qu’un concepteur de systèmes n’a pas nécessairement et qu’il est coûteux d’acquérir. De plus, cela conduit la vérification formelle à ne pou- voir donner de résultat si le modèle est trop grand. Ce processus retourne, pour une propriété et un modèle donné :
– VRAIsi la propriété est vérifiée pour tous les états,
– FAUXet un contre-exemple dans le cas contraire ou encore,
– MANQUE DE MÉMOIREsi le modèle est trop grand et que la vérifi- cation ne peut terminer pour des raisons de mémoire.
Pour illustrer le problème de l’explosion combinatoire, il suffit que prendre le module critique du Therac-25. Utilisant trois variables pour un total de 32 bits, ce module peut donc prendre 232 états différents, chacun des états né- cessitant 4 octets soit un total 16 giga-octets pour un problème de très petite taille (un logiciel complet pouvant compter des centaines de variables).
• Étant appliquée sur des modèles, elle ne permet pas à priori de vérifier la construction (i.e.,implémentation). Cela dit, de nombreux travaux pro- posent d’utiliser les données produites lors de la vérification systématique
pour servir de données et d’oracles de tests. C’est-à-dire pour construire automatiquement les scénarios de tests. Parmi ces travaux citons [BLC09].
De fait, ces obstacles posés, bien des entreprises renoncent à appliquer des mé- thodes formelles pour contrôler et améliorer la qualité de leur système.
Vérification systématique de modèle en langage dédié
Une façon de rendre les méthodes formelles plus accessibles est d’utiliser un langage de modélisation dédié au domaine (i.e.,DSL). Pareils langages offrent l’intérêt de proposer une syntaxe facile d’accès pour un expert du domaine (puisque utilisant ses idiomes) tout en conservant une sémantique clairement dé- finie et donc susceptible d’être analysée de façon automatique. La figure1décrit cette approche. Un ingénieur (appelé ingénieur langage) capture les concepts, le vocabulaire et le fonctionnement d’un domaine. Puis il décrit la syntaxe d’un lan- gage proche du domaine du concepteur ainsi qu’une transformation. La dernière étape est la validation du langage par les experts du domaine.
La transformation permet de partir d’un modèle exprimé dans la syntaxe dé- diée (e.g.,description de réfrigérateur, téléphones portables, . . . ) et d’aller vers un modèle exprimé dans un langage formel (e.g.,automates, π-calculus, réseaux de Petri algébriques, . . . ). Il est à noter que c’est cette transformation donne une sé- mantique formellement définie auDSL. L’intérêt est de libérer le concepteur du
Concrete Syntax
Transform.
Meta Model
Language engineer
Domain expert
Figure1 – Processus de développement d’un “langage dédié”.
système des aspects formels et de leurs lourdeurs. Le langage ainsi développé est utilisé comme indiqué par la figure 2. Le modèle transformé est ensuite analysé par un outil appelé vérificateur de modèle ou “model checker” (e.g.,SPIN [Hol03], NuSMV [CCGR99], GreatSPN [BBC+09], AlPiNA [BHMR10b], . . . ) qui produit un contre-exemple dans le cas où une propriété (i.e.,la spécification) n’est pas satisfaite (e.g.,un état du Therac-25 dans lequel le flux d’énergie est actif alors que le collimateur n’est pas en place). Ce contre-exemple étant exprimé dans la syntaxe formelle, il faut le traduire pour le rendre compréhensible par le concep- teur. Sur la base de ce contre-exemple, le concepteur peut modifier le modèle du système afin qu’il satisfasse les contraintes posées (e.g.,flux d’énergie éteint si le collimateur n’est pas en place).
Model Checker modélise
Transformation Transformation
Langage spécifique au domaine Modèle du système
Modèle du système + optimisations (Algebraic Petri Nets)
Contre-exemple Contre-exemple Langage spécifique
au domaine
Processus automatique Intervention manuelle
(Algebraic Petri Nets) Concepteur
Figure2 – Approche “langage dédié” appliquée à la vérification de modèle.
De plus, le concepteur du système ne manipulant que des concepts qu’il maî- trise, sa confiance dans le modèle et surtout dans la sémantique de celui-ci augmente. Cela permet d’assurer avec un haut degré de confiance que le mo- dèle du système et les spécifications sont conformes aux attentes du mandant (i.e.,validation). Par ailleurs, il est souhaitable que la sémantique de chacun des
éléments duDSLsoit discutée et définie par le concepteur et l’ingénieur langage de façon conjointe.
Un autre intérêt de l’approche de modélisation à l’aide de langages dédiés est qu’elle rend possible l’intégration d’un certain nombre de techniques et d’heuris- tiques permettant de palier à l’explosion combinatoire directement lors de la trans- formation. Cela permet de libérer le concepteur de cette tâche et de lui éviter de devoir acquérir des connaissances poussées dans le domaine de la vérification sys- tématique de système. De plus, certaines de ces techniques peuvent être enrichies par des méta informations indirectement fournies par le concepteur et extraites lors de la transformation. En effet, certaines heuristiques sont liées au domaine ou au type de modèles manipulés (e.g.,concurrents, modulaires, temps réel, . . . ).
De ce fait, utiliser un langage proche du domaine permet d’intégrer dans celui-ci des méta-données de façon naturelle et de les exploiter lors de la transformation.
Enfin, cette approche présente l’intérêt de limiter les interventions manuelles du concepteur à son strict travail de conception, les détails techniques étant laissés aux soins de l’ingénieur langage ou au “model checker”.
L’approche décrite ci-dessus est expliquée en détails dans [JS06]. Pour pou- voir être mise en oeuvre, elle requiert une plate-forme cible ayant les propriétés suivantes :
• Supporter un formalisme de modélisation et de spécification suffisamment expressif pour pouvoir modéliser toutes les instances représentables par le langage dédié et suffisamment flexible pour limiter la complexité de la trans- formation depuis et vers le langage dédié.
• Un ensemble de techniques et de configurations permettant de circonvenir à l’explosion combinatoire. Les configurations relatives à l’optimisation de la vérification doivent par ailleurs pouvoir être générées automatiquement.
• Autant que faire se peut, les techniques d’optimisation et de calcul doivent être cachées (y compris à l’ingénieur langage). C’est-à-dire que le langage d’optimisations doit être intuitif et ne pas demander la maîtrise des tech- niques employées par l’outil.
Positionnement
L’objectif du projetAlPiNA, qui est au centre de cette thèse, est de fournir une plate- forme cible ayant les propriétés susmentionnées. La figure 2 décrit le processus de vérification à l’aide d’un langage dédié. Tout d’abord le concepteur réalise un
modèle dans un langage dédié. Ce modèle est ensuite transformé en un modèle formel et vérifié grâce à un outil adéquat. Puis les résultats de la vérification sont traduits dans le langage dédié afin d’en faciliter l’interprétation par le concep- teur. Dans la suite nous ne considérerons pas la partie de la figure 2concernant le langage dédié et admettrons qu’un utilisateur avancé manipule directement les langages de modélisation et d’optimisation. Puisqu’il doit manipuler les concepts de modélisation et de vérification formelle, cet utilisateur doit maîtriser le forma- lisme et dans les grandes lignes, comprendre le fonctionnement des principales optimisations. Rôle qui serait normalement assumé par l’ingénieur langage qui programme la transformation.
Un langage de modélisation : les réseaux de Petri algébriques
Il existe de nombreux langages formels. Selon l’objectif choisi, certains sont plus adaptés que d’autres. Dans ce travail nous choisissons d’utiliser les réseaux de Petri de haut niveau et plus particulièrement les réseaux de Petri algébriques. Cela pour plusieurs raisons :
• Étant des réseaux de Petri [Rei85], les réseaux de Petri algébriques [Vau85, Vau87,Rei91] (i.e.,APN) décrivent très bien les notions de concurrence. Ils représentent un bon compromis entre un langage, qui bien que formel, reste lisible puisque graphique. Cette propriété est bien utile pour l’ingénieur lan- gage qui doit écrire les transformations à partir de et vers leDSL.
• Par rapport aux réseaux de Petri standard, ils apportent le support de type de données structurées (i.e.,Algebraic Abstract Data Type (AADT)) tels que les listes, les ensembles ou encore les tableaux. Cette propriété les rend Turing complet et s’avère très pratique pour modéliser des systèmes infor- matiques non triviaux. Sans cela, la plupart des systèmes manipulant des objets structurés, il serait nécessaire de déplier le modèle (i.e.,de transfor- mer les structures complexes en objets plus simples) avant de pouvoir le vérifier. A nouveau, la richesse du formalisme cible permet de simplifier la transformation à partir de et vers leDSL.
• Ils représentent un premier pas vers un formalisme plus évolué supportant la modularité et la hiérarchie. Il est prévu à terme qu’AlPiNA supporte les réseaux de Petri algébriques hiérarchiques et modulaires [AD11].
La figure3présente le module du Therac-25 responsable de l’incident. Il s’agit d’une approximation, en effet AECL n’ayant jamais fourni le code source à la Federal Drug Agency (FDA), nous en sommes réduits à inférer le comportement de ce module à partir des bribes à disposition.
Pour simplifier, le Therac-25 fonctionne selon deux modes possibles :
[false] [1]
Tphase
Fmal Class3
SetupTest_SET
$set = true SetupTest
[FIELD_LIGHT]
CollimatorMode
[FIELD_LIGHT]
BeamMode [DatEnt]
Lmtchk
[$col] [$m]
[$f]
[chkcol($c, $f, $col, $m)]
[$c]
[$c]
[inc($c)]
[SetupTest]
[nextPhase($f)]
[SetupTest]
[$f]
[SetupTest]
DataEntry
[SetupTest]
[DatEnt] [$m]
[$treatment]
[false]
PressSet
[$set]
[$set]
[true]
[nextpos($col)]
[$col]
MoveCollimator
$set = true [$set]
Set
[DatEnt]
Figure3 – Réseau de Petri algébrique modélisant le bogue du Therac-25.
• En mode lumière de positionnement. Dans ce cas, l’appareil illumine la zone à irradier pour permettre un positionnement précis du patient avant le traitement.
• Un mode de traitement soit par des rayons X, soit par un flux d’électrons.
Dans chacun des cas, une pièce appelée collimateur vient se positionner devant le flux. Le collimateur est strictement différent selon le mode de fonctionnement sinon il y a risque important de surexposition. C’est ce qui s’est passé pendant l’incident dit de Yakima en 1987. Le mauvais collimateur était en position. Cette erreur, n’ayant pas été détectée par le logiciel, a entraîné l’irradiation du patient sans la protection adéquate.
Description du fonctionnement du Therac-25 Lorsque l’opérateur a fini de saisir le traitement (Rayons-X ou flux d’électrons, puissance, durée) le Therac- 25 passe en phase “SetUp Test”. A ce moment là, la lumière de positionnement est utilisée pour positionner le patient. Une fois fini, l’opérateur appuie sur la touche “SET” ce qui, théoriquement, a pour effet de mettre le bon (par rapport au traitement choisi) collimateur en place. Pour assurer cette fonctionnalité, deux tâches (Lmtchk,SetUpTest) coopèrent en communiquant par l’intermédiaire de deux variables partagées (Class3etFmal). A noter queSetUpTest_SETest la seconde partie de la tâcheSetUpTest. En effet,SetUpTestn’est pas atomique et de fait,Lmtchkpeut prendre la main avant que ne soit exécutée la seconde partie deSetUpTest.Class3est incrémentée à chaque passage dans la tâcheSetUpTest. Le rôle de la variableClass3 est de contrôler si la vérification de la consistance du collimateur par la routine
Lmtchk aura lieu. La routineLmtchk vérifie que l’état du collimateur est consistent par rapport à la prescription si et seulement si Class3 est différente de zéro. En cas d’inconsistance, le bit 9 deFmalest positionné. De façon régulière, la seconde partie de la première tâche (SetUpTest_SET) vérifie queFmalvaut zéro (sinon il y a inconsistance). Si c’est le cas le Therac-25 passe en modeSetUpDoneet dès lors le bombardement peut commencer.
Il y a plusieurs problèmes avec cette façon de procéder :
• Tout d’abord rien n’oblige la tâcheLmtchka être exécutée avantSetUpTest_SET
et doncSetUpTest_SETpeut se lancer sans queFmaln’ait été mise à jour.
• Ensuite,Class3étant de longueur un octet, au 256 ème passage dans la tâche
SetUpTest, la variableClass3vaudra zéro et si il y a inconsistance à ce mo- ment précis, elle ne sera pas détectée même si Lmtchk prend la main avant
SetUpTest_SET.
L’état initial du modèle de la figure3 ne devrait jamais permettre de passer en phaseSetUpDone. En effet le collimateur, n’étant jamais consistent avec le trai- tement cela devrait être empêché. Malheureusement, ce n’est pas le cas pour les raisons citées plus haut.
Le réseau de Petri algébrique décrit dans la figure 3 fonctionne de la façon suivante :
• Les cercles représentent des variables (appelées places), elles contiennent des ressources (i.e.,des données) qui peuvent être consommées par les tran- sitions (les rectangles) pour mener à bien une action. Par exemple, la place
Class3contient la valeur1et la placeFmalcontient la valeurfalse.
• Les rectangles représentent des actions (appelées transitions), elles consomment les ressources des places d’entrée et produisent des ressources dans les places de sortie.
• Les flèches représentent des flux de données (appelés arcs), ils représentent ce que doit consommer et produire une transition. Par exemple, la transi- tion SetupTest consomme et produit une valeur dans la place Class3. Il en va de même pour la placeTPhase. Les valeurs en entrée sont appelées pré- conditions et celles en sortie post-conditions. La pré-conditions deSetupTest demande une valeur deClass3(n’importe laquelle puisque$creprésente une variable) et la valeurSetupTestde la placeTphase. Puis si la pré-condition est satisfaite, la post-condition est exécutée :SetupTestremet la valeurSetupTest dansTphaseet met la valeur$cincrémentée de un dansClass3.
• Les annotations sur les places et sur les arcs sont des multi-ensembles de valeurs. C’est-à-dire des conteneurs qui peuvent contenir plusieurs fois la même valeur. Les valeurs sont représentées par des termes construits à partir d’une signature décrite par lesAADTs. Les termes peuvent être vus comme des fonctions dont la sémantique précise est définie par axiomatisation. Ce niveau d’abstraction permet au concepteur de se libérer des considérations d’implémentation pour se concentrer sur la seule sémantique.
A noter que les réseaux de Petri algébriques permettent de définir le compor- tement des fonctions utilisées sur les arcs et dans les places par l’intermédiaire de types abstraits algébriques. Cela permet au concepteur d’utiliser la logique pour définir la sémantique des fonctions et non de devoir les programmer. Les types abstraits algébriques utilisés pour le modèle du Therac-25 sont donnés dans les figures 12 et 13. Par exemple, la fonction chkcol($c, $f, $col, $m) sur l’arc de
Lmtchk àFmal retourne vrai s’il y a une incohérence entre le traitement (BeamMode) et la position du collimateur (UpperCollimatorPosition). Sinon la fonction retourne faux. A savoirChkcolretourne la valeur actuelle deFmalsiClass3vaut zéro.
Un langage de spécification : la logique du premier ordre
En plus de la modélisation du système proprement dite, il est nécessaire de fournir un langage pour exprimer les spécifications. En d’autres termes, un langage pour exprimer les propriétés que le système doit satisfaire. Ces propriétés peuvent être de différents types :
• les propriétés d’atteignabilité ou d’invariance. Il existe un (ou il n’existe aucun) état qui satisfait une propriété. Par exemple, la propriété
Φ : $phase=SetUpDone =⇒ $coll=$m,
devrait toujours être respectée quelque soit l’état ($p ∈ TPhase, $m ∈ BeamMode et $col ∈ CollimatorMode) du Therac-25. En d’autres termes,
si le Therac-25 est dans la phaseSetUpDonealors il ne doit pas y avoir d’in- cohérence entre$collet$m.
• L’absence de blocage. En d’autres termes quelque soit l’état, il existe toujours un état successeur. Une action peut toujours être effectuée. Par exemple, dans le cas du Therac-25, il est toujours possible d’arrêter le flux d’énergie.
• Une séquence d’états appelée trace d’exécution (e.g.,Linear Temporal Lo- gic (LTL),Computation Tree Logic (CTL)).
AlPiNA vérifie des propriétés d’atteignabilité exprimées en logique du premier ordre ainsi que l’absence de blocage. Ce choix représente un compromis entre la vérification de propriétés, qui bien qu’intéressantes d’un point de vue du modèle restent à la fois faciles à comprendre d’un point de vue du concepteur et d’une complexité limitée d’un point de vue opérationnel. De plus, il s’agit d’une pre- mière étape obligatoire vers la vérification de propriétés temporelles. La syntaxe et la sémantique du langage de propriété d’AlPiNA sont définies dans [MB10].
La vérification de modèle
Une fois le système modélisé et les spécifications établies, voyons à présent com- ment vérifier si une propriété est satisfaite par un ensemble d’états. La méthode naïve consiste à calculer à partir d’un état donné (i.e.,l’état initial) et pour une action donnée, le prochain état du système et se faisant, de vérifier que le nou- vel état calculé satisfait à la spécification (la propriété énoncée). Si ce n’est pas le cas, l’état (ou la trace d’exécution) fautif est retourné au concepteur pour qu’il puisse corriger le modèle en conséquence. A noter, que l’erreur peut également se trouver au niveau de la spécification. Ce processus se poursuit jusqu’à ce que tous les états possibles du système aient été vérifiés. La figure 4 explique cette approche. Imaginons que l’on ne souhaite vérifier qu’aucun état n’a la propriété C, en commençant par l’état initial (s0). Il faut calculer les états successeurs de s0 en appliquant chacune des actions possiblesN = {a0,a1,a2}. AppliquerN(s0) produit les états{s1,s2,s3}. A partir des1, seule l’actiona2est possible et conduit à produire l’état s3. De la même façon,N(s2) ={s3,s4}. Comme s4 a la propriété C nous avons trouvé un contre-exemple à la propriété à savoir l’état s4. Cette technique requiert de mémoriser qu’un état ait déjà été observé afin de pouvoir terminer la procédure. Evidemment cette approche implique qu’il y ait un nombre fini (même très grand) d’états ce qui en réduit le champ d’application auxsystèmes finis.
s0
s1
s2
s3
s5 s4
s6
s7 a0
a1 a2
a2
a2 a0
a0
a1 a0
A
A
B
A A
C A
A
N
= a0...a2 : actions s0...s4 : Etats du système A,B,C : propriétésFigure4 – Vérification qu’aucun état du système n’ait la propriété C.
Nous avons vu qu’étudier systématiquement tous les états d’un système tel que celui du Therac-25 nécessite beaucoup de mémoire. Il existe de nombreux travaux visant à réduire cette consommation mémoire. Citons, par exemple, les techniques d’abstractions [Kur94] permettant de réduire significativement la taille du modèle à explorer en l’abstrayant. Dans le Therac-25, la variableFmalest un double-octet mais comme seul le bit 9 est intéressant, il est donc possible d’abstraire cette va- riable en un Booléen. Il en va de même pour la variable Class3 (limiter à 4 au lieu de 255 dans le modèle de la figure3). Cependant l’abstraction peut produire des faux négatifs. Il convient dès lors de les vérifier dans le modèle original. Les techniques, basées sur les ordres partiels [Pel94,GW94], permettent quant à elles de profiter de l’indépendance de certaines actions pour ne pas traiter tous les cas possibles. Par exemple, dans la figure4, en partant de l’état s0 on peut appliquer soita0(a2(a0(s0))) = s7 soit a2(a0(a2(s0))) = s7. Dans les deux cas, l’état obtenu est le même. Dans ce cas sia0eta2sont indépendantes (i.e.,elles manipulent des variables différentes) on peut ne considérer que l’un des deux chemins. Cepen- dant ces techniques ont en commun de représenter chaque état explicitement et de fait, de requérir une quantité de mémoire linéaire par rapport au nombre d’états.
Comme l’explosion combinatoire est exponentielle, cela reste un problème.
Vérification symbolique de modèle
La vérification symbolique de modèle résout partiellement ce problème en enco- dant l’espace d’états de façon condensée, en utilisant par exemple les diagrammes de décision binaires Binary Decision Diagrams (BDDs)[BCM+92] ou leurs ex- tensions telles que les diagrammes de décisions multiplesMulti-valued Decision Diagrams (MDDs)[CLS00], les diagrammes de décisions de donnéesData Deci-
sion Diagrams (DDDs)[CEPA+02] ou encore les diagrammes de décisions d’en- sembles Hierarchical Set Decision Diagrams (SDDs) [CTM05]. Ces techniques ont été appliquées avec succès aux réseaux de Petri standard pour la vérification de systèmes matériels ou encore de logiciels simples tels que des protocoles qui n’utilisent pas de structures de données complexes.
Imaginons, que nous disposions de l’encodage symbolique d’un espace d’états et d’une fonction successeur appelée N qui à partir d’un espace d’états produit l’ensemble des successeurs. C’est-à-dire l’ensemble d’états atteignables à partir de l’espace d’états initial. Il suffit dès lors d’appliquer N jusqu’à ce que l’on ne découvre plus aucun nouvel état. Il convient naturellement de conserver les états produits à chaque application de N. Ce qui revient à calculer la fermeture transitive de la fonction N. Autrement dit, l’espace d’états d’un système à partir d’un espace d’états initialS0se calcule par :
(N+Id)∗(S0)
(N + Id)∗ représentant le point fixe de la fonction (N + Id) c’est-à-dire lorsque (N+Id)n+1= (N+Id)npour un ensemble d’états donné,idreprésentant la fonction identité qui, à un espace d’états donné, retourne le même espace. La figure5décrit cette approche.
De part la structure partagée desDDs, cette procédure travaille sur plusieurs états à la fois, ce qui améliore significativement les performances par rapport à l’approche explicite. Bien que très efficace, cette technologie oblige le concep- teur à maîtriser les technologies sous-jacentes. De plus, pour être appliquées sur des formalismes de plus haut niveau tels que les réseaux de Petri colorés ou al- gébriques, ces techniques nécessitent la transformation du modèle de haut niveau en réseau de Petri place/transition. Cette opération, appelée dépliage [KLPA06], est souvent complexe et quelques fois impraticable. En effet le nombre de places et de transitions résultantes est polynomiale par rapport à la taille des domaines traités. De plus, ladite transformation appelle une limitation de tous les types de données. Si cette limitation s’avère fausse elle peut soit provoquer un surplus de calcul non négligeable si trop haute, soit invalider le résultat de l’analyse si trop basse. La transformation en réseau de Petri de bas niveau pose aussi problème lors de l’interprétation des résultats, en effet il faut les interpréter dans le contexte du formalisme de haut niveau.
Diagrammes de décisions
Les diagrammes de décisionsDDsétant au centre de cette thèse, nous rappelons ici quelques principes de base sur leur fonctionnement. LesDDssont une famille de structures de données dédiées à la représentation compacte de données. L’idée principale est de stocker des vecteurs d’assignements de façon partagée. Il en
N (S0) N (N ((S0))= N 2(S0) ... N d(S0) = N d+1(S0) = N *(S0) S0
(N + Id)*(S0)
Figure5 – Calcul de l’espace d’états de façon symbolique.
existe de multiples variantes, chacune pour un besoin particulier. Les plus anciens et les mieux connus sont les diagrammes de décisions binaires BDDs [Bry86].
Dans la suite nous noterons le vecteurs d’assignementsvar1 =val1, var2 =val2, . . . , varn = valn de la façon suivante : var1
val1
−−→ var2 val2
−−→ . . .varn valn
−−→ 1 . Les DDs sont des graphes dirigés et acycliques dont chacun des noeuds re- présente une variable ou un domaine et dont chaque arc représente une valeur (e.g.,BDD,DDD) ou un ensemble de valeurs (e.g.,SDDs). LesDDsont plusieurs propriétés intéressantes. Par exemple, leur taille (le nombre d’arcs et de noeuds du graphe) ne dépend par directement de la quantité de données stockée dans le graphe. Leur taille peut être exponentiellement plus petite que la taille des don- nées encodées. De plus, grâce à l’utilisation du patron de conception “poids mou- che” [Wik12a,Wik11] qui est intrinsèquement lié à la construction opérationnelle duDD, l’égalité entre deuxDDs(deux ensembles) est testée en temps constant.
Encodage d’un espace d’états
Un état peut être vu comme une séquence d’assignements de valeurs à des variables. Ainsi l’état initial du Thérac-25 selon le modèle 3 est composé de cinq variables : Class3=0 (noeud C3), Fmal=0 (noeud FM) et TPhase = 3 (noeud TP),
UpperCollimatorPosition=FIELD_LIGHT(noeudUP) etBeamMode=FIELD_LIGHT(noeudMB).
Cela se traduit par le diagramme de décision de la figure6a.
Le diagramme6bprésente l’espace d’états complet du système du Therac-25.
Comme les variablesTPhaseetFmaln’ont pas été modifiées elles sont partagées. La variableC3 prend quatre valeurs différentes. Sur le chemin du bas,FM prend deux valeurs alors qu’il n’y en a qu’une sur celui du haut. Ainsi, la figure 6b encode symboliquement douze (4*2+4) états différents. Par exemple : UP FIELD LIGHT
−−−−−−−−−−−−→
BM FIELD LIGHT
−−−−−−−−−−−−→ TP SetUpDone
−−−−−−−−−→ FM true
−−−−→ C3 2
−
→ 1 et UP FIELD LIGHT
−−−−−−−−−−−−→BM FIELD LIGHT
−−−−−−−−−−−−→
TP SetUpTest
−−−−−−−−−→ FM false
−−−−−→ C3 3
−→ 1 sont deux des séquences possibles. A noter
que la dernière node ( 1 ) est un terminateur qui a une signification similaire au terminateur 1 desBDDs.
UP {FIELD_LIGHT} BM {FIELD_LIGHT} TP {SetUpTest} FM {f alse} C3 {0} 1
(a)État initial du modèle du Therac-25
UP BM TP FM C3 1
FM
{FIELD_LIGHT} {FIELD_LIGHT} {SetUpTest} {true,f alse} {0,1,2,3}
{SetUpDone} {true}
(b)Espace d’états complet Therac-25 soit douze vecteurs
Figure6 – Encodage DD de l’espace d’états initial et complet du Therac-25
Encodage de la fonction de transition
Une fois l’espace d’états encodé, il faut pouvoir le manipuler pour pouvoir calculer les états successeurs. Il faut donc encoder la fonction successeurN citée précédemment. La manipulation diffère selon le type de diagramme de décisions.
Nous ne parlerons ici que du cas desDDDset de leurs successeurs. Sur ce type de DDs, la manipulation se fait à l’aide de fonctions appeléeshomomorphismes in- ductifsqui sont définis par l’utilisateur. Ces fonctions étant des homomorphismes par rapport à l’union il permettent de travailler chemin par chemin puisque siφest un homomorphisme eta,bsont desDDsalorsφ(a∪b)=φ(a)∪φ(b). A noter que l’union et la composition de deux homomorphismes sont des homomorphismes et que φ(0) = 0, 0 représentant le DD vide (i.e.,l’ensemble vide). Ils sont dits inductifs parce que définis inductivement pour chaque cas hvariable,valeuri et pour le cas du terminateur.
La sémantique du tir d’une transition d’un réseau de Petri se fait par compo- sition d’homomorphismes. L’homomorphisme simulant la pré-condition ne sélec- tionne que les chemins la satisfaisant (i.e.,ayant suffisamment de ressources) et dans le même temps change les valeurs duDDpour refléter la consommation de ressources. Puis dans un deuxième temps, les gardes s’il y en a sont vérifiés et enfin les ressources produites sont ajoutées auDD.
La première application de la transition SetUpTest consomme la valeur
SetUpTestdans la placeTP et la valeur zéro de la placeC3($c=0). Puis, elle produit la ressourceSetUpTestdansTPet la valeur1dansC3. Il faut deux homomorphismes inductifs :
• h−Var,Valconsomme le multi-ensembleValdu contenu de la variableVar.
• h+Var,Valajoute le multi-ensembleValau contenu de la variableVar.
La transitionSetUpTestpeut être décomposée en quatre homomorphismes : φSetUpTest =h+C3,1◦h+TP,SetUpTest◦h−TP,SetUpTest◦h−C3,0
L’homomorphisme h−TP,SetUpTest (resp. hC3,0− ) sélectionne les chemins où TP = SetUpTest (resp. C3 = 0) et h+C3,1 (resp. h+TP,SetUpTest) ajoute la valeur 1 (resp.
SetUpTest) au multiset de la variableC3 (resp.T P).
• h−(e−→X dd)=
•e−−−−→X\Val ddife= Var∧Val ⊆X
•0 ife= Var∧Val* X
•e−→X ddife,Var
• h−( 1 )= 1
h−est appliqué récursivement sur chaque couplehvariable,valeurien partant du terminateur et en préservant le couple si la variable est différente deVar. Dans le cas oùh−traite la variableVar: soitVarcontientValet dans ce casValest retirée du multi-ensemble soith−renvoie leDDvide (i.e.,0). Le résultat de l’application deh−TP,SetUpTest◦h−C3,0sur l’état initial de figure6aest visible sur la figure7a.
L’homomorphisme h+Var,Val quant à lui ajoute le multiset Val à la variable Var quoi qu’il en soit. C’est donc important de d’abord sélectionner les chemins (i.e.,qui satisfont la pré-condition) à modifier à l’aide deh−Var,Val.
• h+(e−→X dd)=
•e−−−−−→X∪{Val} ddife=Var
•e−→X ddotherwise.
• h+( 1 )= 1
L’application deh+Var,Val laisse leDDinchangé si la variable n’est pasVar, sinon il ajouteVal au multi-ensemble. Le résultat de l’application de la post-condition (h+C3,1 ◦ h+TP,SetUpTest) à la figure 7a est visible figure 7b. Finalement la figure 7c présente le résultat de l’union entre l’état initial et le nouvel état calculé par l’ap- plication deφSetUpTest.
Il est intéressant de souligner que les opérations s’appliquent sur des ensembles d’états. En effet tous les sous-graphes partagés sont automatiquement impactés par une modification en amont. De plus, la représentation canonique permet d’identi- fier chaqueDDde façon unique à l’aide d’une référence. Cela permet grâce à une technique appeléememoization[Wik12b] d’avoir un cache d’opérations particu- lièrement efficace. De ce fait, si une opération a déjà été effectuée pour une partie d’unDD, elle peut être tirée du cache et cela en temps constant évitant ainsi un parcours de graphe inutile.
UP BM TP FM C3 1
{FIELD_LIGHT} {FIELD_LIGHT} {} {f alse} {}
(a)Application de la pré-condition deSetUpTestsur la figure6a
UP BM TP FM C3 1
{FIELD_LIGHT} {FIELD_LIGHT} {SetUpTest} {f alse} {1}
(b)Application de la post-condition deSetUpTestsur la figure7a
UP BM TP FM C3 1
{FIELD_LIGHT} {FIELD_LIGHT} {SetUpTest} {true,f alse} {0,1}
(c)Application de l’union entre la figure6aet la figure7b
Figure7 – Différentes étapes du calcul de l’espace d’états du Therac-25
Ordonnancement des variables La figure8présente l’un des problèmes prin- cipaux lié au diagramme de décisions, à savoir l’ordre des variables. En effet, la figure8aprésente l’encodage de l’espace d’états du Therac-25 avec un ordre op- timal pour cette fonction c’est-à-dire qu’il prendra le moins de noeuds et d’arcs.
La figure 8bprésente le pire ordre possible et donc celui qui prendra le plus de place possible. Trouver un ordre optimal est un problème NP-Complet. Il existe cependant des heuristiques qui fonctionnent très bien dans certains cas. Trouver un ordre (ou une organisation) efficace des variables est le défi le plus important dans le cadre de la vérification de modèle symbolique en utilisant les diagrammes de décisions et cela quelle que soit leur nature.
UP BM TP FM C3 1
FM
{FIELD_LIGHT} {FIELD_LIGHT} {SetUpTest} {true,f alse} {0,1,2,3}
{SetUpDone} {true}
(a)En utilisant l’ordre optimal
TP UP BM C3 FM 1
UP BM C3 FM
{SetUpTest}
{SetUpDone} {FIELD_LIGHT}
{FIELD_LIGHT}
{FIELD_LIGHT}
{FIELD_LIGHT}
{0,1,2,3}
{0,1,2,3}
{true}
{true,f alse}
(b)En utilisant le pire ordre
Figure8 – Deux ordres de variables pour l’encodage de l’espace d’états
Optimisations de la vérification de modèle symbolique
Cette approche a été utilisée avec succès [CEPA+02] pour vérifier des modèles de réseaux Petri standard. Cependant, pour pouvoir vérifier des modèles de taille conséquente cela ne suffit pas toujours. Le défi majeur reste l’organisation des va- riables et la façon d’appliquer les transitions. Nous proposons d’utiliser et d’adap- ter les techniques suivantes aux réseaux de Petri algébriques.
Agglomération de variables Comme démontré par la figure 8, une mauvaise organisation des variables peut avoir un effet désastreux sur la taille duDDet donc sur les performances. La taille du graphe n’est pas le seul paramètre, en effet si deux variables dépendantes sont éloignées l’une de l’autre dans le graphe, le par- cours en sera plus lourd ce qui influera négativement sur les performances. Divers techniques ont été inventées pour parer à ce problème, comme par exemple, l’uti- lisation de matrices de Kronecker pour déterminer les interdépendances entre les variables par rapport aux transitions du réseau de Petri. Si deux variables sont très dépendantes il convient de les mettre proches l’une de l’autre dans le graphe. Ces agglomérats (i.e.,cluster) de variables (i.e.,les places du réseau) peuvent être cal- culés automatiquement en utilisant certaines heuristiques ou en utilisant des don- nées et des connaissances spécifiques au domaine modélisé. Comme il s’agit de partitionner des éléments du réseau de Petri on parle de groupement topologique.
La création desSDDs a permis d’apporter une dimension supplémentaire à l’or- donnancement des variables. Avec les SDDsil est possible d’embarquer un DD comme valeur ce qui permet d’organiser les variables sur plusieurs niveaux de hiérarchie.
Saturation Un problème très important dans le cas du calcul symbolique d’es- pace d’états à l’aide des diagrammes de décisions est l’effet de pic (i.e.,peak ef- fect). La taille du DD augmente significativement durant le calcul avant de se réduire à nouveau vers la fin du calcul. Ceci est dû à l’apparition d’états qui ne font pas partie de l’espace d’états final (structure intermédiaire entre pré et post condition). Divers algorithmes ont été créés pour palier à ce problème. Les deux plus connus sontChaining Loop[RCP96] et laSaturation[CLS00,CLS01]. Dans ce travail nous utiliserons la saturation qui est un ordre de magnitude plus efficace queChaining Loop. Toutes les transitions qui n’utilisent que les variables d’une partition sont appliquées jusqu’à l’obtention d’un point fixe, puis les transitions qui recouvrent plusieurs partitions sont appliquées jusqu’à l’obtention d’un nou- veau point fixe et ainsi de suite. Cette technique a été adaptée et améliorée pour lesSDDspar Thierry-Mieg et Hamez [HTMK08].
Anonymisation d’états Une autre technique permet de rendre les noeuds et donc les variables partiellement anonymes. Ainsi, si un sous-graphe du DD est fortement similaire modulo le nom des variables, les variables sont “anonymi- sées” afin de pouvoir partager le sous-graphe en question. Une fonction d’anony- misation permet de reconstituer le graphe original ajoutant par la même un autre niveau de symbolisme. Cette approche est basée sur l’observation faite qu’une partie de l’information est dupliquée et qu’il n’est pas nécessaire, pour identifier de façon unique une partie des éléments, de les nommer. Leur position au sein de la super structure qui les contient peut suffire. Cette technique est comparable aux approches d’optimisations par symétries [CEFJ96].
Contributions
Pour résumer, la vérification de réseaux de Petri algébriques appelle, entre autres, les défis suivants :
• L’encodage de la représentation symbolique des états et la sémantique de modèle de réseaux de Petri algébriques. Puisque nous souhaitons travailler au niveau du réseau non déplié, les opérations sur lesDDsont notablement plus complexes. Nous devons notamment gérer la notion de terme et de réécriture afin de donner une sémantique opérationnelle auxAADTs.
• Le dépliage pose des problèmes de performance et de correction de la véri- fication.
• Les optimisations telles que les agglomérats de variables, la saturation ou l’anonymisation ont été mises au point pour les réseaux de Petri standard et doivent de fait être adaptées aux réseaux de Petri algébriques.
Dans cette thèse, afin de partiellement régler les problèmes susmentionnés, nous proposons d’étendre les diagrammes de décisions d’ensemble à des struc- tures de termes afin de supporter les types de données complexes (listes, tableaux, ensemble, multi-ensemble). Cette extension est appeléediagrammes de décision de signature. Nous proposons également la notion de dépliage partieldu réseau qui évite à l’utilisateur de fixer toutes les bornes et de devoir donc tout déplier. En- fin nous proposons une extension de la notion d’agglomération et d’anonymisation aux réseaux de Petri de haut niveau en introduisant l’agglomération algébrique.
De plus, contrairement à d’autres approches, bien que l’utilisateur garde un fort contrôle sur la modélisation et sur l’optimisation de la vérification, ces deux no- tions sont clairement séparées. De plus, l’objectif à moyen terme est de faciliter l’optimisation de la vérification de modèle. Pour cela, nous proposons de dériver
automatiquement une partie des optimisations à partir de méta-données fournies par des formalismes plus riches tels que les réseaux algébriques hiérarchiques et modulaires.
Diagramme de décisions de signature : Σ DD
L’une des différences principales entre les réseaux de Petri standard et algébriques est le fait que ces derniers embarquent des termes comme inscriptions dans les places, les arcs et les gardes des transitions. Manipuler un modèle algébrique re- vient à générer des milliards de termes. Comme ces termes sont parties intégrantes des états, il devient dès lors nécessaire de proposer une représentation symbolique.
C’est ce que se propose de faire les ΣDDs qui sont une évolution des SDDs. A noter que nous proposons ici une formalisation alternative desSDDsappeléeIn- ductive Injective Partitioned Functions (IIPFs). En effet, la formulation usuelle n’est pas suffisamment typée pour pouvoir définir lesΣDDs. La figure 9montre un ΣDD qui encode trois termes. De la même façon qu’un autre type de dia- gramme de décisions, l’idée est de partager les parties communes. Donc si deux termes ne diffèrent que d’un opérande, le symbole de fonction (f dans l’exemple) et les autres opérandes peuvent être partagés (bdans l’exemple). Une description précise desΣDDsest donnée au chapitre5.
s t t 1
{f}
t {a,b,c} 1
t {b} 1
Figure9 – Exemple d’unΣDDqui encode trois termes
Pour conclure cette présentation informelle des ΣDDs, voyons comment ré- écrire l’ensemble de termes de la figure 9 en utilisant la règle de réécriture sui- vante ρ : f(x,b) → x avec x une variable de typet. Il n’est pas difficile de voir que les trois termes sont réécris en un seul, comme démontré dans la figure10.
L’idée de base est, qu’en utilisant ce type de structure de données, il devient pos- sible d’unifier plusieurs termes d’un seul coup. Grâce à cela et à la memoiza- tion [Wik12b, Mic68] qui peut être facilement implémentée pour les ΣDDs, les performances de réécriture de très larges ensembles sont très bonnes (voir les bancs d’essais présentés au chapitre7).
Encodage de la sémantique opérationnelle
Le défi principal est de supporter la notion de variable. En effet, contrairement aux réseaux de Petri standard, les valeurs consommées et produites ne sont pas
s {f} t t 1 t {a,b,c} 1
t 1
{b}
f ( x , b )
→
→
t {a,b,c} 1
x
Figure10 – Exemple of d’une réecriture deΣDD
toujours connues à l’avance. Il faut donc pouvoir construire une substitution et l’utiliser dans la post-condition. De plus, pour des raisons de performance il faut permettre le dépliage quand cela est nécessaire et donc les parties dépliées et non- dépliées doivent pouvoir cohabiter.
Dépliage partiel
Comme nous l’avons vu plus haut, le fait de ne pas connaître les substitutions à l’avance, requiert des homomorphismes plus complexes dans le cas des réseaux de Petri algébriques que dans le cas des réseaux de Petri standard. Ce surplus de complexité a également un coût en terme de temps de calcul. Pour résoudre ce problème il est possible de déplier les transitions et pour chaque substitution possible de créer une transition spécifique. Par exemple, dans le cas de la transition
SetUpTest du modèle de la figure 3, la seule variable en entrée étant $c de type octet on peut créer une transition pour$c=0,$c=1,$c=2et ainsi de suite. Il est donc possible, connaissant la valeur de$c, de calculerinc($c)et donc de supprimer les variables. Cependant, un dépliage complet n’est à l’évidence pas viable pour les domaines infinis (ou très grands). C’est pour cela que les domaines doivent être bornés, soit structurellement, soit par le concepteur :
• Certains domaines sont intrinsèquement finis (e.g.,une énumération), on parle dans ce cas de borne structurelle.
• Si le domaine à déplier n’est pas fini, le concepteur doit définir une borne appelée borne présumée.
Pour définir une borne présumée le concepteur doit deviner une bonne valeur pour la borne. Ce choix peut avoir des effets importants sur la vérification. Si la borne présumée est trop basse, le modèle ne sera exploré complètement, ce qui rend le résultat non conclusif. D’un autre côté si la borne est trop haute, une partie des ressources mémoire et processeur seront gaspillées pendant la phase de dépliage.
De plus, un grand nombre de pré-conditions jamais satisfaites seront testées pen- dant la vérification, augmentant d’autant le gaspillage. Pour toutes ces raisons les
