Verification with LoLA: 4 Using LoLA

839 views

Published on

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
839
On SlideShare
0
From Embeds
0
Number of Embeds
166
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Verification with LoLA: 4 Using LoLA

    1. 1. 4. Using LoLA
    2. 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. 3. LoLA Configurations • Get LoLA: • http://service-technology.org/files/lola • Standard Workflow: • edit userconfig.H • compile LoLAsetup
    4. 4. userconfig.H • What to check? • Which reduction techniques to use? • Other parameters
    5. 5. The optimal configuration1. 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!
    6. 6. Analysis Tasks• DEADLOCK• REACHABILITY, FINDPATH, STATEPREDICATE• BOUNDEDPLACE, BOUNDEDNET• DEADTRANSITION• REVERSIBILITY, HOME• LIVEPROP, FAIRPROP, STABLEPROP, EVENTUALLYPROP• MODELCHECKING• FULL, NONE
    7. 7. Reduction Techniques• STUBBORN - stubborn sets• PREDUCTION - invariant-based compression• SYMMETRY - symmetry reduction• COVER - coverability graph• CYCLE - cycle coverage• SWEEP - sweep-line method• SMALLSTATE - internal representation
    8. 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. 9. Invariant-based Compression • PREDUCTION • when to use: always • compatibility: not with sweep-line method preduction
    10. 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. 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. 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. 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. 14. Small State Representation • SMALLSTATE • when to use: only for simple reachability questions • compatibility: all other techniques
    15. 15. Reduction techniques Not all combinations make sense! LoLA takes care about this.
    16. 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. 17. Manage configurations • one binary for each configuration • fight complexity: • ask LoLA for its configuration • predefined standard configurations • offspring generationconfigurations
    18. 18. Ask LoLA
    19. 19. Predefined configurations several reasonable standard configurations
    20. 20. Generate offspring generate a userconfig.H for the given binary
    21. 21. Build script downloads the sources and generate a configured binary with random name
    22. 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. 23. Ask the right questions• be as specific as possible• ask one aspect at a time• exploit all knowledge• transform complex questions
    24. 24. Be specific! • most questions can be formulated with CTL • LoLA has dedicated routines: • EF φ - use STATEPREDICATE • AG EF φ - use LIVEPROP • yields more efficient reductionspecific
    25. 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. 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. 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]
    28. 28. Problem hierarchy• MODELCHECKING (CTL algorithms, hardly any reduction possible)• BOUNDEDNET (coverability graph)• STABLEPROP, EVENTUALLYPROP, FAIRPROP (strongly connected sets)• HOMESTATE (mutual reachability of TSCCs)• LIVEPROP, REVERSIBILITY (reachability within TSCC)• REACHABILITY (global property)• BOUNDEDPLACE (overhead for coverability check)• STATEPREDICATE (possibly local property)• DEADTRANSITION (local property)• DEADLOCK (best stubborn sets available)• FINDPATH (memoryless exploration)
    29. 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. 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. 31. High-level guards • use guards to exclude implausible transition bindings • results in quicker unfoldingTRANSITION 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. 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. 33. erformed only if scope Q is allowed to continue its normal p Avoid global statesop, 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. 34. Flexible model generation • model with verification question in mind • for each question have a dedicated model with proper abstractions • implemented in compiler BPEL2oWFNflexible
    35. 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. 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. 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. 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 0exit
    39. 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. 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 FINDPATHgaravel
    41. 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 executionrelaxed
    42. 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. 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. 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. 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 ✔

    ×