Kanban Petri Net

Dans le document Symbolic model-checking with Set Rewriting (Page 88-0)

A.2 Kanban Petri net as an optimized Set Rewrite System

6.4 Kanban Petri Net

contexts) take their new context from the state. Thus, the state becomes a container for the different contexts. For example, in Fig. 6.3 we have a subexpression that treats a data type operation. To treat this operation, we first transform the state to a temporary state (temporary expression). The temporary expression is then treated using thecontext awarestrategy. Finally, once the computation in the temporary state is finished we combine the result of the context with the original context.

6.3.4 Translating Entire Formalisms

To translate entire formalism we proceed transition by transition,i.e.,we compile each transition to a strategy. To simplify the process of translation we do it in two steps.

First, we define a set of simple operations on the state of the system. We give the semantics of these operations using simple SOS rules. These SOS rules are easily translated to strategies. Second, we give the semantics of high level formalisms by compilation to the basic operations we defined in step one.

6.4 Case Study: Petri nets

Petri nets(PNs) [Rei85] is a well known formalism to describe concurrent processes using a graphical notation. A PNis composed of places and transitions. Each place can contain a positive number of tokens. Over the execution of aPNthe number of tokens in each place evolves, thus, the number of tokens in each place represent the state of the system. The transitions describe how the number of tokens in each state varies from one state to the other. When the current state is changed using a transition, we say that the transition isfired.

Graphically, aPNis represeted by abigraph. A bigraph is a graph whose vertices can be divided into two disjoint sets Pand T, with P∩T, s.t. every edge connects an element ofPwith a vertex ofT. We present an example of aPNin Fig. 6.4. The circles represent the places and the rectangles represent the transitions. The tokens are represented inside the places by the black circles.

70 Chapter 6. Semantics Using Set Rewriting

nat zero: nat s: nat 7→ nat pname P1: pname

P2: pname

...

mapping empty: mapping

map: pname, nat, mapping 7→ mapping

Table6.2 – Term signature forPetri net markings

6.4.1 Abstract Syntax

PNshave a simple syntax. Formally, aPNis ann-tuplehP,T,in,out,m0iwherePis a finite set of places, T is a finite set of transitions, andin andoutare respectively the preand postconditions (in curried form)in:T →(P→ N) andout:T →(P→N).

The marking (state) is a mapping from places to integers: m : P → N. We use the notation Mto denote the set of functions fromPtoN(P→ N).

6.4.2 Abstract Dynamic Semantics

EachPNtransition describe (as the name says) a transition. The semantics of a tran-sition can be given by the following general rule:

t: m≥in(t)

m→t m−in(t)+out(t) (6.2)

where m,m1,m2 ∈ M, m is a state of the system, m1 ≥ m2 is true if and only if

∀p∈P : m1(p)≥m2(p), and (m1+m2) : p7→m1(p)+m2(p). We present an example of a concrete rule in Example6.4.1.

Example 6.4.1 Let us consider transitiontok4in Fig.6.4. We have that its semantics is represented by the following simpleSOSrule:

tok4: m(Pm4)≥ 1

m→m[Pout4 =m(Pout4)+1][Pm4=m(Pm4)−1]

The notation m[a=b]presented in Def.3.1.6.

6.4.3 Describing the State

As the previous section states, the state of a PNis described by a mappingm. In our framework we describe the state as a term, thus we need to provide a signature to describe the set of all possible states.

We propose to use the signature in Table6.2. The first thing to notice is that we have to define all types and their respective semantics. For the case ofPNswe use the classical Peano Axiomatization [Pea89,Wik14].

6.4. Case Study: Petri nets 71 There is a sort for natural numbers, a sort for places and a sort representing a map.

Natural numbers are encoded as terms being eitherzero, orsuc(t)wheretis an integer term. For clarity, integer terms are often replaced by plain integers. For instance, the initial state of aPNwith three places ismap(P1, 0, map(P2, 5, map(P3, 0, empty))).

mapingis an inductive structure, which allows to define generic strategies to read and modify it.

6.4.4 Basic Operations on the state

To compute the semantics of a transition we need to be able to do three operations in the state: testp,n,decp,n, andincp,n.

The functions are formally defined as follows:

testp,n : M → {true,false} :m7→m(p)≥ n decp,n : M → M

:m7→m[p= m(p)−n]

incp,n : M → M

:m7→m[p= m(p)+n]

Thus, we can rewrite theSOSrule of Equation (6.2) as:

t=

V

p∈Ptestp,in(t)(p)(m) P={p1, . . . ,pn0}

m→ decp1,in(t)(p1)◦ · · · ◦decpn0,in(t)(pn0)◦incp1,in(t)(p1)◦ · · · ◦incpn0,in(t)(pn0)(m) (6.3) This rule can be translated to our strategies framework in a straightforward manner as shown in Section 6.3.2. The user only needs to define the translation of the three operations. We present an example of the translation in Example6.4.2.

Example 6.4.2 We write the the rule presented in Example6.4.1using the operations defined in this section.

tok4 : testPm4,1(m)

decPm4,1◦incPout4,1(m)

6.4.5 Compile Function

Given a PN, we give a compile function for a transition. Indeed, since we have a generic simpleSOSto describe the semantics of transitions, we only need to provide

72 Chapter 6. Semantics Using Set Rewriting thepCompandaCompfunctions. We present them here:

pComp:testp,in(t)(p)(m)7→ {

checkLocp ={map(p, $x, $m) {

map(p, $x, $m)};

testStratp,n ={map(p,compInt(n), $m) {

map(p,compInt(n), $m)}; applyTo(S1,S2)=IfThenElse(S1,

S2,

One(applyTo(S1,S2),3));

applyTo(checkLocp,testStratp,in(t)(p))} where thecompIntfunction is defined as follows:

compInt:N→ TΣ : 17→s($x)

:n7→s(compInt(n−1))

The function returns a declaration and a strategy. The strategyapplyTois a recur-sive strategy. It first checks if it can apply its first parameter and if it can then applies the second one. If it cannot, then it calls itself recursively on the third subterm. One defines also two auxiliary strategies. ThecheckLocstrategy, which verifies that one is at the correct location and thetestStratstrategy that actually does the test. Of course, the genericapplyTostrategy is completely reusable in our framework.

Using almost the same approach, we can define theaCompfunction to transform actions to rewrite strategies. Indeed theaCompis very similar to thepCompfunction.

We just need to replacetestStratbyactStrat, we illustrate it as follows1: aComp:decp,n(m)7→ {

decStratp,n ={map(p,compInt(n), $m) {

map(p, $x, $m)};

applyTo(checkLocp,decStratp,in(t)(p))}

The compilation ofincp,nis left as exercise to the reader as it is almost the same as fordec. An example of the full compilation of a transition is given in Example6.4.3.

We also present the complete translation of thePNfrom Fig. 6.4in AppendixA.

In that translation, we directly merge the mapping and the names of the places. Thus, instead of having a termmap(P1, 0, empty), we have directlyP1(0, empty).

Example 6.4.3 We present the complete translation of the transition tok4. The first step is to translate the three primitives testPm4,1, decPm4,1, and incPout4,1. We have the

1We omit previously declared functions to improve readability

6.5. Case Study DiViNE 73 following strategies:

checkLocPm4 ={map(Pm4, $x, $m) {map(Pm4, $x, $m)} checkLocPout4 ={map(Pout4, $x, $m) {map(Pout4, $x, $m)}

testStratPm4,1 ={map(Pm4, suc($n), $m) {map(Pm4, suc($n), $m)} decStratPm4,1 ={map(Pm4, suc($x), $m) {map(Pm4, $x, $m)} incStratPout4,1 ={map(Pout4, $x, $m) {map(Pout4, suc($x), $m)}

The full compilation of the strategy is described in the following strategy:

comp( testPm4,1(m)

m→ decPm4,1◦incPout4,1(m))=Sequence(applyTo(checkLocPm4,testStratPm4,1), Sequence(applyTo(checkLocPm4,decStratPm4,1),

applyTo(checkLocPout4,incStratPout4,1)))

6.5 Case Study DiViNE

We have seen that PN are simple to translate to strategies and that the compilation function can easily be given. In this section we present a more complex formalism involving integer expressions and a more imperative structure.

We focus on a restricted set of DiViNE operations. In fact, DiViNE supports several integers operations such as addition, subtraction, division, multiplication and modulo. For our illustration we only implement addition and subtraction. The other operations do not present any particular problem to be encoded in rewriting. However, some of them require non-linear rules to be implemented. Non-linear rules are possi-ble in our framework, however, they are not directly supported,i.e.,one cannot define a non-linear rule. For a detailed discussion of this constraint and the workaround we provide please see Section6.5.5.

6.5.1 Abstract Syntax

We first give an abstract syntax of the language we are translating. ADiViNEsystem is a list of global variables declarations followed by a list of process declarations.

Each process has its own set of local variables and a set of transitions that describe the changes in the local and global variables. The full abstract syntax is given in Table6.3.

For our purposes, we focus on the transitions. Transitions are composed by a guard and a set of actions. The guards are standard Boolean expressions that support integer comparison e.g., less than, equals, etc. Actions are mostly variable assignations to variables in the process and global variables.

We present an example of aDiViNEmodel in Fig.6.5. The model represents the well known Peterson mutual exclusion algorithm for three processes. In the model there is an extra feature that we are not considering in our syntax: arrays. Indeed, to

74 Chapter 6. Semantics Using Set Rewriting Basic syntactic sets:

Boolean generators: {true,false}= B

Integers: i∈Z

Identifiers: id ∈Id

Derived syntactic sets:

Integer Expression: e∈IntExpr

e::= id|e+e0|e−e0| −e|i Guard Expression:

b,b0 ∈BoolExpr

b::=bandb0|true|false e≤ e0|e, e0|e=e0

Assignment: a∈Assign

a::= id:=e|a;a0 Variable declaration: d ∈Dec

d ::=intid|intid= i|intid[i]|d;d

Transitions: t ∈Trans

t ::=transid{b;a}

Process Body: pb∈ProcBody pb::=t|t;t0

Processes: p∈Proc

p::=procid {d;t} |p;p0 Divine Program: d ∈DivineProg

d ::=d;p

Table6.3 – SimplifiedAbstractSyntax of theDiViNElanguage

make the explanation shorter we have omitted the translation of arrays. However, they are implemented in our toolStrataGEM. We present a short explanation of how they work in Section6.6. The full translation of the algorithm can be found in AppendixB.

6.5.2 Abstract Semantics

At a semantics level we are interested in two things, the state and the transitions. We focus first on the state. The state is the combination of two mappings, a mapping for global variables, and a mapping from processes to the mapping of local variables.

To simplify the representation of the state we represent everything in one map. We just use different names for local variables. Thus, given a setGV of global variable names and for each process Pi a setVPi of local variable names (we assume that sets VPi andGV are pairwise disjoint), the mapping is given as follows:

ρ:GV∪[

i

VPi →N

6.5. Case Study DiViNE 75 We present here the outline of the main rule describing the syntax of the system:

hb, ρi → htrue, ρi ha, ρi → hρ0i hb;a, ρi → hρ0i

The rule describes how to obtain the next mapping in a transition. First, we need to evaluate the conditionbto some Boolean value. If the evaluation ofbis equal totrue, then we need to compute the action a. It is clearly a complex rule since we need to keep an intermediate result, before executing the action. Thus, we need to translate it to Simple SOSrules. In Section6.5.4 we present a set of simplified operations that can represent such rule.

6.5.3 Describing the States

The dynamic semantics ofDiViNEmakes a heavy usage of complex rules. For exam-ple, the evaluation of guards requires evaluating integer expression, comparing their result and then possibly combining the result with other guards. We use the state to keep these intermediate results. Thus we redefine the state as a tuple that con-tains the mapping and the intermediate results. We keep the integer intermediate re-sults in a stack. The stack supports the usual operationspush : Z×Stack → Stack, top : Stack → Z, andpop : Stack → Stack. We note the empty stack and we give the semantics of the operations by the following axioms:

push(pop(st))= st top(push(n,st))=n

Thus, the set of statesΓis defined as:

Γ =





hst, ρi |ρ:GV ∪[

i

VPi → Nandst ∈Stack









hb, ρi |ρ:GV ∪[

i

VPi → Nandb∈BoolExpr





We define thus a signature to describe such a state in Table6.4. We do not define a stack sort and we use the map operation to simulate the stack. This saves us the definition of some operations. Thetest functor helps creating a tuple containing the temporary state after the evaluation of a guard.

76 Chapter 6. Semantics Using Set Rewriting Sorts: mapping,vname,int,guarded,bool

Generators: v1: vname

...

vn: vname empty: mapping

map: vname, int, mapping 7→ mapping test: bool, mapping 7→ guarded

Table6.4 – SOSrules forDivine

6.5.4 Describe Basic Operations

We define a set of functions to operate on our state. To simplify, we note the set of mapsGV∪S

iVPi →Nas M. The operations are formally defined as follows:

test :BoolExpr×M → {true,false}

:hb, ρi 7→

( true, ifb=true false, otherwise pushn :Stack× M→Stack× M

:hst, ρi 7→ hpush(n,st), ρi add :Stack× M→Stack× M

:hst, ρi 7→ hpush(top(st)+top(pop(st)),pop(pop(st))), ρi subt :Stack× M→Stack× M

:hst, ρi 7→ hpush(top(st)−top(pop(st)),pop(pop(st))), ρi readv :Stack× M→Stack× M

:hst, ρi 7→ hpush(ρ(v)), ρi writev :Stack× M→Stack× M

:hst, ρi 7→ hpop(st), ρ[v= top(st)]i lt :Stack× M→BoolExpr×M

:hst, ρi 7→ htop(st)≤top(pop(st)), ρi eq:Stack× M→BoolExpr×M

:hst, ρi 7→ htop(st)=top(pop(st)), ρi neq:Stack× M→BoolExpr×M

:hst, ρi 7→ htop(st),top(pop(st)), ρi

We consider that we can describe the semantics of DiViNE transitions using these operations and thus we provide a compilation fromDiViNEto this set of operations.

Given these basic operations, we give the semantics of the language constructs by compilation to SOSrules containing only these operations. This is required because high levelSOSrules are not supported by our framework. We present here thelComp function that translates a DiViNE transition to a simple SOS rule expressed in our

6.5. Case Study DiViNE 77 operations. To simplify the notation we noteExprthe set of all expression that appean in a transition,i.e., Expr = Trans∪IntExpr∪BoolExpr∪Assign∪Z∪Id

lComp:Expr →SimpleSOS∪Cond∪Act :transid {b,a} 7→ lComp(b)

lComp(t) :candc0 7→lComp(c)∧lComp(c) :true7→ true

:false7→ false

:e< e0 7→lComp(e)◦lComp(e0)◦lt◦test :e= e0 7→lComp(e)◦lComp(e0)◦eq◦test :e, e0 7→lComp(e)◦lComp(e0)◦neq◦test :e+e0 7→lComp(e)◦lComp(e0)◦add :e−e0 7→lComp(e)◦lComp(e0)◦subt :id :=e7→lComp(e)◦writeid

:a;a7→ lComp(a)◦lComp(a) :i7→ pushi

:id 7→readid

We can see that the rules are translated in a straightforward manner to our operations.

6.5.5 Compile Function

In the previous section we defined a compile function to translate aDiViNEtransition to a simple SOSrule. We now provide the aCompand pCompfunction to translate our simpleSOSrules to strategies using the framework presented earlier.

The only function in our basic operations set that behaves like a predicate istest.

Thus,pCompis defined as follows:

pComp:test7→ {test(true, $s) {$s}

TheaCompis slightly more complicated. It deals with complex modification of the state and some operations require to use standard rewriting techniques,e.g.,computing integer arithmetic. We divide the aCompfunction in three parts: simple operations, arithmetic computations, and read/write operations.

Simple operations

The simplest operation that we need to do is pushing a value to the stack. This opera-tion is done by a simple rewrite rule. It is presented below:

aComp:pushn 7→ {$m {map(t, n, $m)}

In this rule we use the map directly as a stack instead of creating an extra term for the purpose.

78 Chapter 6. Semantics Using Set Rewriting Arithmetic Computations

Arithmetic computations are done on the stack. We need to perform two steps, first we get the elements out of the stack and then we compute the result using standard rewriting rules. We give the rules to encode the semantics addition and subtraction as follows:

integerSem={+($i1, 0) {$i1

+(0, $i1) {$i1,

-(-($i1)) {$i1,

-(0) {0,

+(s($nz1), s($nz2)) {+(s(s($nz1)), $nz2),

+(-($nz1), -($nz2)) {-(+($nz1, $nz2)),

+(-($nz1), s($nz2)) {-(s($nz2), $nz1),

+(s($nz1), -($nz2)) {-(s($nz1), $nz1),

-($i1, 0) {$i1,

-(0, s($nz1)) {-(s($nz1)),

-(s($nz1), s($nz2)) {-($nz1, $nz2),

-(-($nz1), -($nz2)) {-(+($nz1, $nz2)),

-(-($nz1), s($nz2)) {-(s($nz2), $nz1),

-($i1, -($nz2)) {+($i1 , $nz2) }

However, to apply this rules we need to first do a pop operation, and create the sum term. This can be done by a simple rewrite rule:

popAdd= {map(t, $i1, map(t, $i2, $m)) {map(t, +($i1, $i2), m)}

The same is valid for thepopSubtstrategy, we leave it as exercise to the reader. Thus, we can give theaCompfunction foradd, andsubtas follows:

aComp:add 7→Sequence(popAdd,One(Fixpoint(RewriteSetWith(integerSem,2)))) aComp:subt7→ Sequence(popSubt,One(Fixpoint(RewriteSetWith(integerSem,2))))

The Fixpoint strategy ensures that the RewriteSetWith strategy is applied until all terms are rewritten. TheRewriteSetWithensures that all terms are rewritten.

The same pattern as before is repeated for thelt,eq, andneqfunctions. We present

6.5. Case Study DiViNE 79 here their semantics expressed as rewrite rules:

notEqual={neq(0, 0) {false,

neq(suc($n1), suc($n2)) {neq($n1, $n2),

neq(neg($nz1), neg($nz2)) {neq($nz1, $nz2),

neq(0, suc($n1)) {true,

neq(0, neg($nz1)) {true,

neq(suc($n1), 0) {true,

neq(neg($nz1), 0) {true } lessThan={lt(0, 0) {false,

lt(0, neg($nz1)) {false,

lt(suc($n1), 0) {false,

lt(neg($nz1), 0) {true,

lt(0, suc($n1)) {true,

lt(neg($nz1), suc($n2)) {true,

lt(suc($n1), suc($n2)) {lt($n1, $n2),

lt(neg($nz1), neg($nz2)) {lt($nz2, $nz1),

lt(suc($n1), neg($nz1)) {false)} equals={eq(0, 0) {true,

eq(suc($n1), suc($n2)) {eq($n1, $n2),

eq(neg($n1), neg($n2)) {eq($n1, $n2),

eq(0, suc($n1)) {false,

eq(0, neg($n1)) {false,

eq(suc($n1), 0) {false,

eq(neg($n1), 0) {false)}

The same pattern as foraddandsubtapplies to the functionslt,eq, andneq. However, thepopis different, in fact, the stack (or the map) can only handle integers. Thus, we use the typetestdesigned to hold a state and a Boolean expression. Hence, we have that thepopLtstrategy is given as follows:

popLt={map(t, $i1, map(t, $i2, $m)) {test(lt($i1, $i2), $m)}

The strategies forpopEqandpopNeqfollow exactly the same pattern. We present the missing definition for our functions:

aComp:lt7→Sequence(popLt,One(Fixpoint(RewriteSetWith(lessThan)),1)) aComp:eq7→Sequence(popEq,One(Fixpoint(RewriteSetWith(equals)),1)) aComp:neq7→Sequence(popNeq,One(Fixpoint(RewriteSetWith(notEqual)),1)) Read/Write Operations

Read/write operations are require several auxiliary strategies. However, the auxiliary strategies are completely reusable.

80 Chapter 6. Semantics Using Set Rewriting First we define a strategy to check if we are in a given variable, we call this strategy checkv. It is given as follows:

checkv ={map(v, $n, $m) {map(v, $n, $m)}

This strategy fails if we are not treating a map that hasvas its first variable.

We also need a strategy to find a variable that is in a subterm of the map. We define a parametric strategy findApplyv(S) that takes a strategyS and applies it at the position in the map wherevis. This strategy is defined as follows:

findApplyv(S)= IfThenElse(checkv),S,One(findApplyv(S),3)

We also need a strategy to copy the value in the term. We give a non-linear version of the strategy here:

copy={map($v, $i, $s) {map(sE, $n, map($v, $i, $m))}

We use an extra variable namesEto identify the element of the map as a stack element.

The final strategy that we need is theupstrategy. The job of theupstrategy is to getsEelement of the map to the top of the stack. The upstrategy is defined with the help of three other auxiliary strategies: upAux,endUp, andupSwap. We present them below:

upSwap= {map($v, $i1, map(sE, $i2, $m)) { map(sE, $i2, map($v, $i1, $m))} upAux= Choice(upSwap,Sequence(One(upSwap,3),upSwap))

endUp= {map(sE, $i, map($v, $i, $m)) {map(t, $i, $m)} up= Sequence(upAux,endUp)

The upSwap strategy performs the swap locally. The upAux performs the swap globally. If it finds an element to swap locally it uses upSwap, otherwise it tries to perform the swap in the next level of the map. Finally, we have the endUpstrategy that transforms the element to a normal stack element,i.e.,an element with variablet. Theupstrategy appliesupAuxand then puts the result on top of the stack as the other elements.

Given the auxiliary strategies we can give translation of the read operation, we present it below:

aComp:readv 7→Sequence(findApplyv(copy),up)

The read operation write operation is very similar. It just needs auxiliary opera-tions to take down the variable. We leave it as exercise to the reader.

Constraints

Our framework does not currently support non-linear rules,i.e.,where a variable ap-pears more than once in the same side of the rule. Indeed, linear rules are directly translatable toDDoperations, whereas the translation of non-linear rules can be done

6.6. Arrays 81 in several ways. Depending on the applications, some ways are better than others.

Thus, we decided to let the user choose how to implement non-linear rules. For ex-ample, the following pattern simulates the copy rule, presented earlier, for natural numbers:map(i, $n, $p){map(stackElt, $n, map(i, $n, $p)):

doubleVar={suc($n1){doubleVar(0, 0, suc($n1)),

0{doubleVar(0, 0, 0)}

duplicateVar={ doubleVar($n1, $n2, suc($n3)){

doubleVar(suc($n1), suc($n2), $n3)} extractValue={ map($v, doubleVar($n1, $n2, 0), $s){

map(stackH, $n1, map($v, $n2, $s))} copy= Sequence(

One2(Sequence(doubleVar,

Fixpoint(RewriteSet(duplicateVar))), extractValue)

This principle can be generalized for any sort, if one can define an inductive copy (rulesduplicateVar) of the values based on the generators (0,succ induplicateVar).

The strategyRewriteSet remembers the number rewritten by duplicateVar. It forces the strategy to also keep the terms that were not rewritten. This is one of the few cases where the strategies do not shield the user from the effects of dealing with sets. The

The strategyRewriteSet remembers the number rewritten by duplicateVar. It forces the strategy to also keep the terms that were not rewritten. This is one of the few cases where the strategies do not shield the user from the effects of dealing with sets. The

Dans le document Symbolic model-checking with Set Rewriting (Page 88-0)