Proceedings Chapter
Reference
AlPiNA: A Symbolic Model Checker
BUCHS, Didier, et al.
BUCHS, Didier, et al . AlPiNA: A Symbolic Model Checker. In: Lilius, Johan and Penczek, Wojciech. Applications and Theory of Petri Nets . Berlin / Heidelberg : Springer, 2010. p.
287-296
DOI : 10.1007/978-3-642-13675-7_17
Available at:
http://archive-ouverte.unige.ch/unige:10786
Disclaimer: layout of this document may differ from the published version.
1 / 1
AlPiNA: a symbolic model checker
?Didier Buchs, Steve Hostettler, Alexis Marechal, Matteo Risoldi Software Modeling and Verification laboratory
University of Geneva
Route de Drize 7, 1227 Carouge, Switzerland http://smv.unige.ch
Tool Paper
Abstract. AlPiNA is a symbolic model checker for High Level Petri nets. It is comprised of two independent modules: a GUI plugin for Eclipse and an underlying model checking engine. AlPiNA’s objective is to perform efficient and user-friendly, easy to use model checking of large software systems. This is achieved by separating the model and its prop- erties from the model checking-related concerns: the users can describe and perform checks on a high-level model without having to master low- level techniques. This article describes the features that AlPiNA provides to the user for specifying models and properties to validate, followed by the techniques that it implements for tuning validation performance.
Keywords: System design and verification, Higher-level Nets Models, Algebraic Petri Nets, State Space Generation, Computer Tools for Nets, Model Checking
1 Introduction
Model checking consists of verifying whether a model satisfies a given property, usually expressed using temporal or modal logic. Model checking implies fully automated property proving. When a property does not hold on a model, the user should get a counterexample. High-level formalisms [1,2] allow users to specify complex models in an easier way. At the same time model checking can benefit from the richness of information of such models. In our approach, we use High-Level Petri nets (HLPNs) – more precisely, a class of HLPNs called Algebraic Petri nets (APNs) [2]. In APNs, the model is composed of a Petri net – expressing aspects related to causality, non-determinism and concurrency – and of algebraic abstract data types (AADTs, commonly called ADTs with a slight abuse) – describing the data and their manipulation.
This article explains how to perform model checking on APN using our tool called AlPiNA, which stands for Algebraic Petri Net Analyzer. AlPiNA’s ob- jective is twofold. First, to perform reachability analysis on finite models in a
?This work was partially funded by the COMEDIA project of the Hasler foundation, ManCom initiative project number 2107.
Algebraic Clustering Properties to be checked
Model Checking engine
Automatic User Driven Uses
Answer High-Level model
ADTs
+ Algebraic net Unfolding
User input
Performance improvements Model validation
Fig. 1.Overview of the AlPiNA framework
user-friendly and efficient way. Second, to scale up these models without requir- ing the end user to know the underlying model checking techniques used by AlPiNA, like its decision diagrams-based symbolic representation [3].
The article is organized as follows: section2presents a general overview of the framework. Section3describes the definition of models and properties. In section 4 we introduce two notions, algebraic clustering and partial net unfolding, that can be used to improve model checking efficiency. Section5describes AlPiNA’s architecture, and gives some hints about the tool development process. Section6 shows the performance of our tool compared to two other well-known model checkers, for some common examples found in the literature. Finally, section7 draws conclusions and outlines future perspectives.
2 Framework overview
Modeling with AlPiNA requires the user to treat two different concerns, shown in Fig. 1. The first concern is specifying a model along with the properties to be checked (left block). The model specification consists of algebraic data types and a Petri net describing the system behavior. Properties are logical statements concerning the model’s states, that can be either satisfied or not. In our case, a property is said to be satisfied by a model if it evaluates to true for all of the model’s states (and thus is called an invariant). Specifying a model and its properties is already enough to perform checks if the model has a small number of states.
However, for certain problems with high concurrency, the number of states may quickly become too large to be represented as the model size increases if no optimization is performed. Efficiently checking models with larger state spaces requires the user to provide additional information about the model’s structure.
This constitutes the second user concern: specifying algebraic clustering and algebraic net unfolding to improve model checking performance (right block of
Fig. 2.naturals ADT
Fig.1). Both user-provided information are then merged by the engine to perform a more compact computation of the state space.
3 Model creation and validation
AlPiNA is fully integrated in the Eclipse environment. Models are created in a dedicated Eclipse project, and some example projects are provided with the tool. The model and the properties to be checked are defined through a mix of graphical and textual editors. This corresponds to the left block of Fig.1.
3.1 Data types definition
APNs can be compared to the well-known colored Petri nets [1], but they re- place colors with algebras defined using ADTs. Informally, an ADT allows the definition of a set of values using inductive axiomatization. This axiomatization enables some automatic processing on data types, which is very helpful for some features presented here, like algebraic clustering. Every value has a given sort and can be described with a term, i.e., a combination of the ADT’s operations and generators. The behavior of operations is defined using a set of axioms. In AlPiNA, axioms are treated as term-rewriting rules [4] – they are repeatedly applied until a normal form is reached, i.e., no rules can be applied anymore.
AlPiNA offers a helper where one can specify a term and ask for its normal form.
Fig.2 shows one of the most basic ADT defined in AlPiNA: naturals. The naturals ADT defines a sort, callednat. There are twogenerators for this sort, zeroandsuc, that are combined to represent all the values in the algebra. This definition is similar to the Peano axiomatization. We also define one operation, plus, with two axioms that define its behavior. AlPiNA’s data types offer more than this example shows, like sub-sorting, polymorphism or data type modularity similar to what is shown in [5].
3.2 Control flow definition
Once the data types have been defined, one has to model the system’s behavior.
Petri netsare a widely used formalism to model concurrent systems like commu-
Fig. 3.AlPiNA’s GUI for defining an APN
nication protocols. In short, a Petri net is made ofPlaces, that represent system resources, andTransitions, the firing of which represents system state evolution.
Places and Transitions are connected with arcs. AlPiNA offers both a graphical and a textual interface to define algebraic Petri nets, where places, transitions and arcs are annotated with algebraic terms. Fig.3shows the graphical interface.
A tool palette allows the user to create Petri net elements easily, and properties of the net elements can be edited using the standard Eclipseproperties view.
3.3 Property checker
Once a model is complete, one can perform model checking. AlPiNA offers a dedicated textual language for specifying reachability properties, equivalent to first-order logic. This language was inspired by Helena’s [6], a well-known model checker for HLPNs, but was adapted to profit from the flexibility of ADTs.
A property in AlPiNA is a boolean expression that must be evaluated totrue for every state of the model. If there is a reachable state where the property does not hold, a textual representation of this state is returned as a counterexample.
Fig.4shows a property definition in the actual AlPiNA editor.
4 Performance improvements
Due to the state space explosion problem, advanced techniques are needed to perform checks on large models. We proposepartial net unfolding andalgebraic clustering. These techniques correspond to the right block of Fig.1.
4.1 Algebraic clustering
Concurrency and non-determinism are major causes of the well known state space explosion problem. This happens when model components have no causal
Fig. 4.Property definition example
dependencies among them, i.e. when they may evolve independently. Algebraic clustering exploits the inductive definition of data types to define these com- ponents, improving model checking performance. The goal of clustering is to calculate the state space of individual model components, and then to combine them. To specify clustering, we assign each term and place of the net to a cluster.
Existing works already use control flow to perform clustering. We extend that technique to data types.
Fig. 5.Clustering definition
In order to exploit the inductive nature of values, algebraic clustering can be itself defined using induction. Criteria for choosing clusters are generally guided by the structure of the model and the properties to be verified. In general, the best results are obtained when independent elements are put in separate clusters. A heuristic is to put processes in the same cluster as their resources, while resources shared among several processes are put in another cluster. By
doing this, the operations that only affect one process can be performed within a single cluster. This speeds up the computation.
AlPiNA provides a language for defining clustering. Consider a system with ten processes identified by natural numbers. Each process has two states, mod- eled by two places P1 and P2. Using the mentioned heuristic, each process is assigned to its own cluster. Fig.5shows such a clustering function. Each of the ten first natural numbers is added to its own cluster in both places P1andP2.
From a user perspective, choosing the granularity of the clustering is a trade- off between the independence of the components and the size of the cluster. A too fine or too coarse clustering will lead to sub-optimal performance.
4.2 Algebraic net unfolding
Another feature designed to increase the model checking performance in AlPiNA is algebraic net unfolding. Some data types, like naturals or lists, have a sort with an infinite domain; others, like the booleans, are finite. Algebraic unfolding con- sists of explicitly enumerating ADT values before computing the state space.
AlPiNA can use this information to improve the speed of state space generation.
From a user perspective, the novel aspect of this feature resides in the fact that for each data type, users can choose whether or not they want the engine to un- fold it (partial net unfolding) and if so whether the unfolding should be bounded (bounded sort unfolding). This choice is a trade-off between the complexity re- duction of the state space generation and the cost of the unfolding operation itself, which is polynomial with respect to the size of the algebras.
AlPiNA is able, to a certain extent, to guess what a good unfolding com- bination could be, avoiding combinations that may lead to an incomplete state space coverage. Fig.6shows the dialog for specifying unfolding.
Fig. 6.Algebraic unfolding example
As it can be seen, some choices are grayed-out by the system in order to prevent the user from specifying an incorrect unfolding. This system guess uses the following rules:
– An enumerated data type can be totally unfolded (i.e. thebool in our ex- ample).
– If a data type appears in the clustering definition, itmust be unfolded.
– If a data type is infinite, it cannot be totally unfolded. If the system cannot be sure whether an inductive data type is infinite a warning is displayed.
Fig.6 shows this for the naturalsnat.
The user must be careful when choosing a bound for unfolding. If the bound is too big, the unfolding may become more expensive than the model checking itself. On the other hand, if the bound is too small, the validation may become incomplete. In this case, the result is inconclusive.
5 Architecture
One of AlPiNA’s goals is providing a synergy between usability and performance.
The EMF framework provides a good platform to create the user interface; a powerful underlying model checking engine allows checking models with large state spaces. To provide a great user experience we leverage the Eclipse platform.
It provides a well-known user interface model as well as very efficient tools to develop new software. The most natural way to create a model is using a language that is specifically tailored to the domain of the model – a Domain Specific Language (DSL). The Eclipse platform provides several tools to develop DSLs, one of the most relevant being the Eclipse Modeling Project (EMP) [7], which follows a metamodeling approach. The EMP platform includes the following technologies:
– EMFhttp://www.eclipse.org/modeling/emf/: we used the Eclipse Mod- eling Framework to define AlPiNA’s metamodels. The main advantage of EMF is that the large palette of bundled tools makes the creation and ma- nipulation of metamodels easy, while providing strong integration between them.
– GMF http://www.eclipse.org/modeling/gmf/: the Graphical Modeling Framework allows the creation of a graphical editor for EMF metamodels.
The AlPiNA graphical editor is entirely based on GMF.
– XText http://www.eclipse.org/Xtext/: XText allows the creation and manipulation of textual DSLs, and generates a complete textual editor with features like code completion, syntax highlighting and on-the-fly syntax checking. AlPiNA’s textual editors were created using XText.
The real power of these tools is that, being based on the same building blocks, they are well integrated. This allows the graphical editor to reference elements from the textual editors (e.g. the terms can be used in the APN) and vice versa (e.g. the places of the APN can be used in the clustering definition). Moreover, the metamodeling approach allows the integration with other projects that use the same technology. As an example, we are currently working on the integration of the PNML language [8]. PNML’s goal is to become a standard for defining different types of Petri nets. It can be used as a platform for the interchange be- tween different Petri net tools. Like AlPiNA, PNML was developed using EMF.
This allowed us to use metamodel transformations to perform the translation between PNML and AlPiNA’s language.
Graphical User Interface Model Checker Engine AlPiNA GUI
Meta-Model Graphical + Textual Concrete Syntax
EMF/GMF/Xtext Metamodeling Tools
RMI Decision Diagrams (JDD, ∑DD) Data structures Property Checker Algebraic Petri Nets Engine
Fig. 7.AlPiNA’s architecture
As a research project, AlPiNA tries to be as modular as possible in order to support the rapid evolution of technologies as well as new ideas.
Fig.7describes the layered architecture of AlPiNA. The left block represents the structure of the graphical user interface (GUI). The first layer manages the user interface itself. It leverages the code that has been produced by the tools on the second layer, which presents the metamodeling tools used in AlPiNA:
the concrete syntaxes are defined with GMF and XText, based on metamodels created with EMF.
The right block of Fig.7 represents AlPiNA’s model checking engine, which performs the actual computation. The first two layers are the property checker and the APN engine. These two layers act as an interface to the engine: the input is an APN and some properties to be checked; the output is the result of the property checks and some information about the APN’s state space, such as the computation time and the number of states. These two layers are based on the underlying data structures, called Decision Diagrams [9,10,11], used to calculate and represent the state space.
Communication between the blocks of Fig.7 is done through Java Remote Method Invocation (RMI). This ensures a strong independence between GUI and engine, and allows experienced users to easily extend the tool: both the interface and the engine can be substituted by different components or re-used in other projects.
6 Benchmarks
To validate AlPiNA’s approach, we compared its results with Maria’s [12] and Helena’s [6], two well-known model checkers. Table1shows some benchmarks for the state space generation by the three tools. These benchmarks were performed on a 2.5GHz Intel Core 2 Duo Macintosh, with a limit of 1GB RAM assigned.
All source codes are available at http://alpina.unige.ch. Maria and Helena are cleary outperformed when clustering and unfolding are enabled. In the other case (clustering disabled), AlPiNA’s results are of the same order of magnitude.
AlPiNA Maria Helena Partial Unfold. Total Unfold.
Model States Mem Time Mem Time Mem Time Mem Time Size # (MB) (s) (MB) (s) (MB) (s) (MB) (s)
Distributed Database
10 197E3 10 0.8 12.4 1.3 47 44.3 24 9
15 7.2E7 33 2.6 41 5.8 - - 1.4E3 7.5E3
35 5.8E17 544 69.4 789 278 - - - -
Leader Election
10 31302 gray gray 10.3 0.72 20 3.4 10 7
15 399E4 gray gray 27.7 1.4 795 361 107 142
50 1.7E21 gray gray 702 76 - - - -
Table 1.State space generation (empty=N/A; –=out of memory failure)
Both examples in Table1are well-known communication protocols often used in the literature of the model checking field. The Distributed Database model is very interesting because it proves that partial unfolding can be more efficient if applicable. The Leader Election protocol does not have infinite domains, and therefore partial unfolding does not make sense. We can see in these examples that AlPiNA is able to handle a much bigger state space than the other tools.
The performance gain of AlPiNA is more evident on models that have very strong concurrency. This is the case of the Leader Election protocol in Table1, where the different processes are more independent than in the Distributed Database protocol. In such models the state space is close to the cartesian prod- uct of each model component’s state space. In the best case, memory consump- tion is logarithmic with respect to the number of states.
7 Conclusion
This article provided an overview of AlPiNA, a high-level Petri nets based model checker. We showed its user-friendly interface, and gave some details about the tools used to create it. Bechmarks were given to show the state space compu- tation performance. More detailed technical information and benchmarks were published in [13].
The tool is in active development and will be significantly improved within the next months. In the future we plan on adding the following features:
– Automatic test case generation [14] using the generated state space.
– CTL support. Currently, only reachability properties are allowed. Supporting CTL would also allow us to build traces to a given counterexample.
– Object orientation and encapsulation as was done in [5]. A hierarchical view of the model would simplify the modeling activity.
– A DSL for process properties for automatic cluster inference.
AlPiNA, its source code and metamodels are available under the GPL license as an Eclipse plugin or a complete Eclipse package athttp://alpina.unige.ch.
References
1. K. Jensen. Coloured Petri Nets. Springer, Berlin, 1996.
2. Wolfgang Reisig. Petri nets and algebraic specifications. InTheoretical Computer Science, volume 80, pages 1–34. Elsevier, 1991.
3. Jean-Michel Couvreur and Yann Thierry-Mieg. Hierarchical decision diagrams to exploit model structure. In FORTE, volume 3731 ofLecture Notes in Computer Science, pages 443–457. Springer, 2005.
4. A. J. J. Dick and P. Watson. Order-sorted term rewriting.Comput. J., 34(1):16–19, 1991.
5. Didier Buchs and Nicolas Guelfi. A formal specification framework for object- oriented distributed systems. IEEE Transactions on Software Engineering, 26(7):635–652, july 2000.
6. Christophe Pajault and Sami Evangelista. High level net analyzer.http://helena.
cnam.fr/.
7. Eclipse. Eclipse modeling project. http://www.eclipse.org/modeling/.
8. Michael Weber and Ekkart Kindler. The Petri Net Markup Language. In Hartmut Ehrig, Wolfgang Reisig, Grzegorz Rozenberg, and Herbert Weber, editors, Petri Net Technology for Communication-Based Systems, volume 2472 ofLecture Notes in Computer Science, pages 124–144. Springer, 2003.
9. Jean-Michel Couvreur, Emmanuelle Encrenaz, Emmanuel Paviot-Adet, Denis Poitrenaud, and Pierre-André Wacrenier. Data decision diagrams for Petri net analysis. In Proceedings of the 23th International Conference on Application and Theory of Petri Nets (ICATPN’02), volume 2360 of Lecture Notes in Computer Science, pages 101–120, Adelaide, Australia, June 2002. Springer Verlag.
10. Didier Buchs and Steve Hostettler. Sigma Decision Diagrams: Toward efficient rewriting of sets of terms. In Andrea Corradini, editor,TERMGRAPH 2009: Pre- liminary proceedings of the 5th International Workshop on Computing with Terms and Graphs, number TR-09-05 in TERMGRAPH workshops, pages 18–32. Uni- versità di Pisa, 2009. Available at http://smv.unige.ch/publications/pdfs/
termgraph09.pdf.
11. Steve Hostettler. Java decisions diagrams library. Technical Report 201, CUI, Université de Genève, June 2008. Available as http://smv.unige.ch/
technical-reports/pdfs/TR201-JDD.pdf.
12. Marko Mäkelä. Modular reachability analyzer. http://www.tcs.hut.fi/
Software/maria/.
13. Didier Buchs and Steve Hostettler. Toward Efficient State Space Generation of Algebraic Petri Nets. Technical Report 206, CUI, Université de Genève, January 2009. Available as http://smv.unige.ch/technical-reports/pdfs/
TR206-APNClustering.pdf.
14. Didier Buchs, Levi Lucio, and Ang Chen. Model checking techniques for test gen- eration from business process models. InAda-Europe ’09: Proceedings of the 14th Ada-Europe International Conference on Reliable Software Technologies, pages 59–
74, Berlin, Heidelberg, 2009. Springer-Verlag.
