Designing the model
4.5 Property definition
• the output arc of transitionproducecontains variable$cof sortconsumer. This is a free variable,i.e.,an output variable that is not an input variable. There-fore the term pk($prod, $c)will be matched to the input variable$prodand toanyconsumer;
• the transitionsendhas a guard: isNotFull($b). This enables the firing ofsend
only if the input variable$b— that represents the current state of the buffer
— is not full (thus ifisNotFull($b)is evaluated to true). The functionpush(
$p, $b)on the output arc queues packet$pin buffer$b. On the other output arc,getProd($p)extracts the producer from packet$p;
• the guard of transitionreceiveis a conjunction of two predicates:isNotEmpty ($b)that is true when the buffer is not empty andgetCons(head($b))= $cthat checks whether the current consumer is the actual recipient of the packet extracted from$b(using the functionhead);
• the signature and semantics of functions isNotFull, push, head, tail,
isNotEmpty are defined in the AADT called Buffers.adt. The functions pk,
getProd andgetCons are defined in the AADTcalled Packets.adt. For more details about the data types, please refer to Fig.4.2.
Prod Cons
Figure 4.3: Algebraic Petri net of a producers/consumers model
4.5 Property definition
To perform verification, it is necessary to specify the properties that the design must satisfy. There are two main families of properties:
110 Chapter 4. Designing the model
• invariant/reachability properties: they are evaluated on each state of the sys-tem. They are usually expressed with a language that is equivalent to first-order logic. In this case, the predicates are defined over the individual states of the system, using a tool-specific language;
• temporal properties: they assert how the system evolves over time. There-fore, they are evaluated on sequences (or trees) of states. They require to extend the properties defined over single states by using temporal logic, such asCTL[CE82] orLTL[Pnu77].
The added expressiveness of temporal properties comes at a cost. First, it requires expertise for the user to write and understand properties. Second, it requires more advanced model checking techniques and is more time and memory consuming.
In AlPiNA, we have chosen to implement a property language that is roughly equivalent to first-order logic with deadlock detection. This language was in-spired by that of Helena [PE09], a well-known model checker for HLPNs, but was adapted to benefit from the flexibility ofAADTs.
As stated in the introduction, properties in AlPiNA are only checked in individual states, without considering the firing of the transitions. There is one exception to this rule: the deadlock. A deadlock occurs in a state if no transition can be fired from it, i.e.,the system is blocked. Thus, looking the state itself is not sufficient, it also is necessary to look at the firing of the transitions from this state. This implies that there is a strong conceptual difference between the check of a deadlock expression and the check of any other expression presented here.
This section presents some of the features of the language and is heavily borrowed from [MB10]. A complete description of the syntax and semantics of the property language is out of the scope of this thesis and can be found in [MB10].
A property is composed ofexpressionsthat can be split in three categories:
• basic expressions that are formula expressed in propositional logic and made up of terms over naturals numbers and upon the specifications of the system;
• iterated expressions that allow to express properties on set of terms (e.g.,all the terms in a place);
• named expressions that enable the user to compose and organize iterated and basic expressions to build the actual property.
4.5. Property definition 111
4.5.1 Basic Expressions
Basic Boolean Expressions
Let us first start with the basic building blocks of a property.
A basic expression is a Boolean expression that can be evaluated to true or false. There are five different types of Boolean expressions:
• constants (e.g.,TRUE,FALSE),
• negative expressions, negations of Boolean expressions (e.g.,!e);
• composed expressions, built with three usual Boolean operators: and, or, andimplies(e.g.,e or e’);
• equals expressions, which evaluate if two expressions are equal or not. We can check the equality between two expressions of the same type; two terms are equal iffboth terms have the same normal form;
• deadlock check, syntactically, a deadlock expression is just a Boolean ex-pression, expressed with the keywordDeadlock.
The semantics of all these expressions is trivially described by the correspond-ing expressions in propositional logic.
Basic Integer Expressions
An integer expression is an expression whose evaluation returns an integer. There are three types of integer expressions:
• constants among the natural numbers (e.g.,0,1,2,. . . )
• minus expressions (e.g.,-2, -(2+2))
• composed expressions, built using the usual integer operators (e.g.,+, *,/) Please note that the operations used are integer ones of the Java language. As for the Boolean expressions, precedences must be explicitly declared with paren-thesis. Integer expressions are essentially used for counting in conjunction with iterated expressions.
112 Chapter 4. Designing the model Term expressions
A term expression is a term built upon the signature of the specification used by the model; it can eventually take variables that are declared within the property definition. These expressions can only be used as members of equal expressions (see Section 4.5.1). The evaluation of a term expression is simply its normal form, eventually after the substitution of the variables (see Section4.5.2). Using terms allows the user to declare special operations in the AADTs that are only used at verification time. This makes the property language extensible and more expressive.
4.5.2 Iterated Expressions
Iterated expressions useiteratorsto perform checks on sets of terms. Two types of sets can be iterated: the content of a place, or the terms of a given sort. We use three operators to iterate over sets: the two quantifiers from first order logic (i.e.,∀notedforall and∃notedexists), and an observer to count the terms of a given set, calledcard.
Iterators
An iterator is a couple hVariable,Domaini noted $x in D, where the domain (D) can be either the content of a Place or the elements of a given Sort. Iterators use variablesto perform iterations. The iteration over sorts can only be performed on unfoldedsorts. InAlPiNAeach sort can be unfolded,i.e.,the values of this sort can be generated during a pre-processing phase, prior to the state space computation.
This unfolding can be total for finite sorts, or partial. Thus, a sort iterator will iterate over the set of values generated by the unfolding of the corresponding sort.
Boolean Iterated Expressions An iterated expression uses a composition of iterators to explore the values in a given set, and evaluates a Boolean expression on each one of these values. We first introduce the expressions that use the two well-known operators from first order logic,∀and∃:
• the universal quantifier ∀ requires that each value of the iterator satisfy a given Boolean expression. For instance,forall($x in P : $x = zero)will be evaluated to ’true’ if for every state of the APN state space, the place P
contains only tokens equal to zero;
• the existential quantifier ∃ requires that at least one value of the iterator satisfy the Boolean expression. For instance, exists($x in P : $x = zero)
4.5. Property definition 113 will be evaluated to ’true’ if, for every state of theAPNstate space, there is at least one token inPequal to zero.
Like in first order logic, ifPis empty at some point, the first expression will be trivially evaluated to ’true’ and the second one to ’false’.
Integer Iterated Expressions In order to enable properties that express con-straints over the number of resources in a given place, we add an operator that works over sets of elements. It is used to count the number of elements that ver-ify a given Boolean expression is called card. APNuse multisets as the states of places, i.e.,each element can be present more than once. If this is the case, card
expressions willcount each element multiple times.
• card($x in P : $x = zero)counts the number of tokens inPequal tozero,
• card($x in P)simply count all the tokens inP, it is equal tocard($x in P : TRUE),
• card($x in P1, $y in P2) counts the number of elements in the set P1 × P2, which is different from computing card($x in P1)+ card($y in P2)
There is a small syntax shortcut for cardinalities, if the condition to be checked isTRUEand there is only one iterator, they can be both omitted:card($x in P : TRUE )can be simply writtencard(P). The same also applies for sort iterators.
Composition of iterators
A single iterated expression could work on more than one iterator at the same time. For this, we use a composition of iterators. These iterators will iterate over the Cartesian product of all the domains. For example, the composition of iterators
$x in P1, $y in P2will iterate over the Cartesian product of the contents ofP1and
P2: each pair of elements from these places will be considered.
4.5.3 Named expressions
To help the user with the properties definition, we added the possibility to define Boolean expressions with a name and use those expressions simply by referencing the name. For instance, when the user wants to write a complex property that is a conjunction of two Boolean expressions. The following listings are equivalent:
card($x in P1 : $x = zero) = 3 & (card($x in P1) + card($y in P2)) < 5
He can write the two Boolean expressions separately and then create a Boolean expression that references the two declarations:
114 Chapter 4. Designing the model
Equals : card($x in P1 : $x = zero) = 3 Max5 : (card($x in P1) + card($y in P2)) < 5
@Equals & @Max5
This allows some modularity in Boolean expressions. It is also useful to test each expression separately. This mechanism is purely syntactical: making a refer-ence to@Expris exactly like copying and pasting the expression referenced by the identifierExpr. This heavily affects the variables substitutions. For example, it’s possible to write both: Equals : $x = zero; and AlwaysEquals : forall($x in P :
@Equals);. In this example the expressionEqualscannot be checked alone, because there is no iterator to define values for the variable$x. The second expression is strictly equivalent toAlwaysEquals : forall($x in P : $x = zero);.
4.5.4 Complete property specification
A property to check in AlPiNA is a Boolean expression. Only one property (thus only one Boolean expression) can be checked at a time. We give here an idea of the syntax used to define the properties in the tool.
import "natural.adt"
import "myAPN.apn"
Expressions
Equals : card($x in P1 : $x = zero) = 3 Max5 : (card($x in P1) + card($y in P2)) < 5 Check
@Equals & @Max5 Variables
x : nat;
y : nat;
The file begins with a list of imports. All the files that define the used Sorts, and the file containing theAPN must be imported. The sectionExpressions con-tains a list of named expressions. The section Check contains a single Boolean expression. This expression will be the actual property checked on the model.
Finally, the variables used by the expressions are declared in theVariablessection.