2. You will learn how
• to choose and manage LoLA configurations
• to ask the right verification questions
• to optimally model a Petri net
• to employ scripts, makefiles, etc.
• to call LoLA from another tool
3. LoLA Configurations
• Get LoLA:
• http://service-technology.org/files/lola
• Standard Workflow:
• edit userconfig.H
• compile LoLA
setup
4. userconfig.H
• What to check?
• Which reduction
techniques to use?
• Other parameters
5. The optimal configuration
1. Know your net!
• Is it bounded? Do you know the bound? Is it safe?
• Do you have a feeling on the outcome?
• Is the net made of several components?
• Does the net have a lot of concurrency?
2. Experiment!
8. Stubborn Sets
• STUBBORN
• when to use: always
• compatibility: all other techniques
• switch RELAXED to chose more efficient
technique if state/predicate is unreachable
9. Invariant-based Compression
• PREDUCTION
• when to use: always
• compatibility: not with sweep-line method
preduction
10. Symmetries
• SYMMETRY
• when to use: net is made of several
symmetric components
• runtime overhead
• compatibility: not with sweep-line method
• switch SYMMINTEGRATION and
MAXATTEMPT to control time/memory
trade-off
11. Coverability Graph
• COVER
• when to use: mostly clear from the context
• compatibility: stubborn sets and symmetry
• use with BREADTH_FIRST to have
shorter paths to check
12. Cycle Coverage
• CYCLE
• when to use: can help sometimes
• runtime overhead
• use with stubborn sets to reduce number
of successors
• Switches NONBRANCHINGONLY and
MAXUNSAVED to control memory/time
tradeoff
13. Sweep-line
• SWEEP
• when to use: behavior has several acyclic
stages - always worth a try
• compatibility: stubborn set method
• in fact: only use with stubborn set method
to avoid a lot of regress transitions
14. Small State Representation
• SMALLSTATE
• when to use: only for simple reachability
questions
• compatibility: all other techniques
15. Reduction techniques
Not all
combinations
make sense!
LoLA takes
care about
this.
16. Other parameters
• BREADTH_FIRST: search strategy
• CAPACITY: fix a maximal number of tokens per place
• CHECKCAPACITY: check capacity and abort
• MAXPATH: maximal length of paths for FINDPATH
• REPORTFREQUENCY: report firing of transitions
• HASHSIZE: number of hash buckets
• MAXIMALSTATES: maximal size of the statespace
maximalstates
17. Manage configurations
• one binary for each configuration
• fight complexity:
• ask LoLA for its configuration
• predefined standard configurations
• offspring generation
configurations
21. Build script
downloads the sources
and generate a configured
binary with random name
22. You will learn how
• to choose and manage LoLA configurations ✔
• to ask the right verification questions
• to optimally model a Petri net
• to employ scripts, makefiles, etc.
• to call LoLA from another tool
23. Ask the right questions
• be as specific as possible
• ask one aspect at a time
• exploit all knowledge
• transform complex questions
24. Be specific!
• most questions can be formulated with CTL
• LoLA has dedicated routines:
• EF φ - use STATEPREDICATE
• AG EF φ - use LIVEPROP
• yields more efficient reduction
specific
25. Ask one aspect at a time!
• Garavel’s challenge: check quasiliveness of a
net with 776 transitions
• naive way: build one statespace and check each
transition
• Problem: 9794739147610899087361 states
• clever way: build 776 statespaces and check each
transition independently
• all but two state spaces have < 20000 states
26. Use all knowledge!
end of a procedure, see Figure 1. The tasks are modeled by transit
ordering of tasks is modeled by places connecting these transitions.
• original question:
soundness of workflow nets
• naive: AG EF φ i
WF-net
o
• Petri-netty: liveness and Fig. 1. A procedure modeled by a W F-net.
boundedness of short-circuited net
The processing of a case starts the moment we put a token in plac
• Knowledge: net is free-choice and built from
the moment a token appears in place o. One of the main properties
should satisfy is the following:
standard patterns For any case, the procedure will terminate eventually, and at t
• boundedness boils down to 1-safeness
procedure terminates there is a token in place o and all the ot
empty.
• clever way: two checks: liveness and 1-safeness
This property is called the soundness property. In this paper we p
to verify this property using standard Petri-net tools. If we restric
choice Petri nets (cf. Best [8], Desel and Esparza [12]), this propert
polynomial time.
W F-nets have some interesting properties. For example, it turns ou
27. Transform your problem!
• original question: relaxed soundness (every
transition fires in at least one terminating run)
• standard algorithm: build statespace, remove
nonterminating behavior and check transitions
• clever way: create special net for each transition t
and check for reachability of marking [o, pt]
29. You will learn how
• to choose and manage LoLA configurations ✔
• to ask the right verification questions ✔
• to optimally model a Petri net
• to employ scripts, makefiles, etc.
• to call LoLA from another tool
30. “optimal” Petri nets
• have verification in mind
• don’t use expensive constructs (reset arcs)
• don’t spoil the reduction techniques
• help LoLA help you
31. High-level guards
• use guards to exclude implausible transition bindings
• results in quicker unfolding
TRANSITION ManInTheMiddle
VAR
bob : bobAgents;
alice : aliceAgents;
bobKey : bobKeys;
aliceKey : aliceKeys;
GUARD
alice <> getMaliceAlice() AND
bob <> getMaliceBob() AND
isSessionKeyForAlice(alice,bob,aliceKey) AND
isSessionKeyForBob(bob,alice,bobKey)
CONSUME
connStateAlice : makeConnectionState(alice,bob,aliceKey,bobKey),
mGoalBobKeys : bobKey;
PRODUCE
goal : 1;
32. Concurrency
• use concurrency where possible
• avoid unnecessary ordering of events
• makes symmetry/stubborn sets applicable
...
initialize initialize initialize
component 1 component 2 component 3
33. erformed only if scope Q is allowed to continue its normal p
Avoid global states
op, the core action of X is bypassed, as captured by the τ -tr
bypassing a normal event can be defined in a similar way.
•
n a fault occurs in scope Q,synchronization changes from to co
avoid excessive the status of Q or “global
state places” rX
X
to_stopQ
X sX
to_continueQ
"bypass" X C
cX
fX
• such nets13. Terminationconcurrency
Figure have no real of a basic activity.
34. Flexible model generation
• model with verification question in mind
• for each question have a dedicated model
with proper abstractions
• implemented in compiler BPEL2oWFN
flexible
35. Scale by structure
• when possible, scale model by structure,
not by the number of tokens
• in LoLA: just increase sort
• rationale: symmetry and stubborn sets
SORT
dimensions = [ 1 , 3 ];
row = [ 1 , 3 ];
36. You will learn how
• to choose and manage LoLA configurations ✔
• to ask the right verification questions ✔
• to optimally model a Petri net ✔
• to employ scripts, makefiles, etc.
• to call LoLA from another tool
37. Script LoLA
• LoLA follows the UNIX philosophy
• every tool does one thing
(and that thing right)
• tools communicate with files/streams
• exit codes tell about outcome of LoLA
• this all allows to quickly build powerful tool chains
38. LoLA’s exit codes
• 0: specified state or deadlock found/net or place
unbounded/home marking exists/net is reversible/
predicate is live/CTL formula true/transition not
dead/liveness property does not hold
• 1: the opposite verification result
• rule of thumb, if the outcome of a verification result
can be supported by a counterexample or witness
path, that case corresponds to return value 0
exit
39. LoLA’s exit codes
• exit code allow for simple workflows in the shell
• (lola1 net.lola && lola2 net.lola && echo
“OK”) || echo “not OK”)
• translation:
• execute lola1
• if the exit code is 0, execute lola2
• if the exit code is again 0, print “OK”
• otherwise, print “not OK”
40. Example: Scripting
• Garavel’s challenge
• quasiliveness of 776 transitions checked in 776 runs
• shell script:
1. extract transitions from net
2. generate analysis task for DEADTRANSITION
("ANALYZE TRANSITION t1")
3. call LoLA
4. evaluate exit code
• DEADTRANSITION succeeds in all but 2 cases
• then use FINDPATH
garavel
41. Example: Makefile
• check for relaxed soundness
• for each transition:
1. create manipulated net
2. generate analysis task
for STATEPREDICATE
("FORMULA (pt = 1 AND o = 1)")
3. call LoLA
4. evaluate exit code
• use Makefile to collect the results
• benefit: parallel execution
relaxed
42. You will learn how
• to choose and manage LoLA configurations ✔
• to ask the right verification questions ✔
• to optimally model a Petri net ✔
• to employ scripts, makefiles, etc. ✔
• to call LoLA from another tool
43. Integrating LoLA into Wendy
• Wendy: a tool to synthesize partners for services
• algorithm needs a lot of small state spaces
• before: calculate them on-the-fly
• now: calculate one big one in advance and
preprocess - helps to avoid “bad” states
• tool of choice for this: LoLA (lola-full)
• benefits:
• modularity
• get Tarjan numbers for free
• interprocess concurrency
wendy
44. Integrating LoLA
• integration is easy when using C:
const char *c = "lola-full tempfile.lola -M";
FILE *pipe = popen(c, "r");
parse_pipe();
pclose(pipe);
• UNIX streams allow parallel generation and parsing of
the state space
45. You will learn how
• to choose and manage LoLA configurations ✔
• to ask the right verification questions ✔
• to optimally model a Petri net ✔
• to employ scripts, makefiles, etc. ✔
• to call LoLA from another tool ✔
