1 / 36

External Memory Algorithms for State Space Exploration in Model Checking

External Memory Algorithms for State Space Exploration in Model Checking. Stefan Edelkamp LS-5, Fachbereich Informatik, Universität Dortmund. modeling language. specification. Abstraction. state rep. transition system. search. A Typical Model Checker. Model Checking. Given

Télécharger la présentation

External Memory Algorithms for State Space Exploration in Model Checking

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. External Memory Algorithms for State Space Exploration inModel Checking Stefan Edelkamp LS-5, Fachbereich Informatik, Universität Dortmund

  2. modeling language specification Abstraction state rep. transition system search A Typical Model Checker Model Checking • Given • A model of a system. • A specification property • Model Checking Problem: Does the systemsatisfy the property ? • An exhausting exploration of the state space. • Problem: How to cope with large state spaces that do not fit into the main memory? • In Practice: successes in finding bugs. Stefan Edelkamp

  3. Why External Memory Algorithms ? • Search algorithms as they appear in model checking and planning performs well as long as they consume RAM only! • Virtual memory slows down the performance of these algorithms drastically! Virtual Address Space 0x000…000 7 I/Os Memory Page 0xFFF…FFF Stefan Edelkamp

  4. External Memory Model (Vitter and Shriver, Algorithmica 1994) If the input size is very large, running time depends on the I/Os rather than on the number of instructions. M B Typically, B = √M Input of size N >> M Stefan Edelkamp

  5. External Sort Open (2) Compact Open (2) Remove Duplicates w.r.t 2 previous layers A A A D A D B A D D E C D D E E E Open (2) Open (1) External Breadth-First Search (Munagala and Ranade, SODA’99) A C E B D A Open (0) Stefan Edelkamp

  6. g g s s Heuristic Search – A* algorithm • A heuristic estimate is used to guide the search. • E.g. Straight line distance from the current node to the goal in case of a graph with a geometric layout. • Admissible Heuristic: Never over-estimates the optimal path. Guarantees the optimal path. • Consistent Heuristic: Never drops fasters than the edge weight. Guarantees the minimum number of expanded nodes. A* Breadth-First Search Stefan Edelkamp

  7. Directed Model Checking (Edelkamp, Leue, Lluch-Lafuente, 2004) • A guided search in the state space. • Usually by some heuristic estimate. • Only promising states are explored. • Under certain conditions proved to be optimal. • Short error trails • Better for human comprehension • Problem: The inevitable demands of the model .. Space, space and space. Stefan Edelkamp

  8. Problems with A* Algorithm • A* needs to store all the states during exploration. • A* generates large amount of duplicates that can be removed using an internal hash table – only if it can fit in the main memory. • A* do not exhibit any locality of expansion. For large state spaces, standard virtual memory management can result in excessive page faults. Q-1: Can we remove the hash table? – Without expanding duplicate nodes? Q-2 Can we bring some order in expansion? - Without compromising the optimality? Stefan Edelkamp

  9. heuristic depth External A* (Edelkamp, Jabbar and Schrödl KI’04)based on Set A* (Jensen, Veloso, Bryant 2000) and BDDA* (Raffel, Edelkamp, FM’00) • h is a total function!! • Consistent heuristic estimates. • ∆h ={-1,0,1,…} I G Stefan Edelkamp

  10. Bucket • A Bucket is a set of states, residing on the disk, having the same (g, h) value, where: • g = number of transitions needed to transform the initial state to the states of the bucket, • and h = Estimated distance of the bucket’s state to the goal • No state is inserted again in a bucket that is expanded. • If Active (being read or written), represented internally by a small buffer. when full, sort and flush Insert states Buffer in internal memory File on disk Stefan Edelkamp

  11. External A* • Buckets represent temporal locality – cache efficient order of expansion. • If we store the states in the same bucket together we can exploit the spatial locality. • Munagala and Ranade’sBFS and Korf’s delayed duplicate detection for implicit graphs. External A* Stefan Edelkamp

  12. Complexity Analysis • Internal A* => Each edge is looked at most once. • Duplicates Removal: • Sorting the green bucket having one state for every edge from the 3 red buckets. • Scanning and compaction. • O(sort(|E|)) • Subtraction: • Removing states of blue buckets (duplicates free) from the green one. • O(scan(|V|) + scan(|E|)) Total I/O complexity: θ(sort(|E|) + scan(|V|)) I/Os Cache-Efficient at all levels!!! Stefan Edelkamp

  13. External A* in Model Checking • Model checking graphs are mostly directed! • Munagala-Ranade’s theorem about looking at only 2 previous layers, does not work! • Subtracting locality many layers and the current layer guarantees no re-expansions. (Zhou and Hansen, AI Journal 2006) • Problem: Locality is not known until the graph is generated! • Idea: Can the individual automata be of any help ? Stefan Edelkamp

  14. Back edge of length 3 loc = 3 Locality in Model Checking • A model checking graph is basically a cross product of automata/processes. • The product can either be synchronous (each automata has to perform one transition) or asynchronous (more than one transitions are fired). loc = 2 loc = 3 Formal proofs and extensions for variables and guards => Under review in STTT Stefan Edelkamp

  15. Liveness Paradoxically, Fdead is a liveness property. It even appears to be true for animals and humans … (Markus Müller-Olm, Liveness Manifesto)

  16. Head of Lasso Initial State Accepting State Liveness Property • Of the form GFp. E.g., G(send  F ackn) • Search for a path that visits an accepting state infinitely often. • Perform Nested Depth-first search that look for a state that is already residing on the stack (Holzmann ). DFS does not show any locality of reference => Not Suitable for External Search! Stefan Edelkamp

  17. Liveness as Safety (Schuppan and Biere, 2005) • Explicitly unroll the lasso. • Search for the head again. Head of Lasso Head of Lasso Initial State Accepting State Stefan Edelkamp

  18. Algorithm: Heuristic Search for Liveness as Safety (Jab.Edel, SPIN’06) • Stage 1: For a state (s,s,0), perform a directed search for an accepting state s’ in the never-claim. When found • Spawn two children: • (s, s, 1): Head of lasso found! • (s, s, 0): Head of lasso not found! • Stage 2: For a state (s, s’, 1), perform a directed search for s’. s might not form a cycle! – So keep searching! Stefan Edelkamp

  19. c a1 a2 a3 Heuristics for the first stage – Head of the lasso • We want to reach an accepting state in the never-claimfaster! Model Never-claim HN = min{(c,a1), (c,a2),(c,a3) }  is the shortest path distance between two states and can be pre-computed. Stefan Edelkamp

  20. Heuristics for the second stage – Close the lasso • We want to reach a particular state (in red) in both the model and the never-claim from mycurrent state (in blue). Model Never-claim c a1 a2 H = max{HN, HM } a3 Stefan Edelkamp

  21. External Directed LTL Model Checking Same states in both parts Arrives at the final state Large jumps due to 2nd heuristic Current state Already seen final state Arrives again at the same final state Stefan Edelkamp

  22. I/O Complexity of External A* for Liveness External memory algorithms are evaluated on the number of I/Os. • Expansion:Linear I/O O(Scan(|V| x |F|)) • Delayed Duplicate Detection: • Removing duplicates from the same buffer: O(sort(|E| x |F|)) • Subtracting previous levels:O(l x Scan(|V| x |F|)); where lis the length of the found counterexample. I/O Complexity =O(sort(|E|x|F|) + l x Scan(|V|x|F|)) Stefan Edelkamp

  23. Parallel and External

  24. Parallel External Model Checking • Probing of our External Model checker showed that successor generation time was most dominating than even the I/O time. • In some of the cases, even up to 80% was spent in successor generation and internal routines. • Since each state in a Bucket is independent of the other – they can be expanded in a parallel fashion. • Duplicates removal can be distributed on different processors. • Bulk (Streamed) transfers between processors are much better than single transfers.  Dual-core ready! Multi-core model checking Stefan Edelkamp

  25. Beware of the Mutual Exclusion Problem!!! Distributed Queue <g, h, start byte, size> P0 <15,34,20,100> TOP P1 <15,34,0,100> <15,34,40,100> P2 <15,34,60,100> Stefan Edelkamp

  26. Delayed Duplicate Detection • Each state can appear several times in a bucket. • A bucket has to be searched completely for the duplicates. Single Files Sorted buffers P0 P1 P2 P3 GOAL Problem: Concurrent Writes !!!! Stefan Edelkamp

  27. External Breadth-First Branch-and-Bound in UPPAAL-CORA • Can we use the same approach by Munagala and Ranade here ? YES and NO • Duplicate Elimination is not trivial! Symbolic State: l: active locations in local automata Z: Zone - set of constraints satisfied by clocks Real-Time state spaces Trivial state spaces A state (l,Z) is a duplicate of (l,Z’) iff Z  Z’ and f(Z)  f(Z’) (l,Z4) (l,Z5) (l,Z6) (l,Z1) (l,Z2) (l,Z3) A A No total order on Zones => O(n^2) comparisons for each location cost  Zone Union – same location but different zones Search frontier Stefan Edelkamp

  28. Iterative Broadening External Breadth-First BnB 100% 80% 60% cost 40% k=20% Search frontier Only pick best k% nodes for expansion. Stefan Edelkamp

  29. Iterative Broadening External BF BnB Stefan Edelkamp

  30. Experiments • Algorithms have been implemented in • Spin Model Checker (ACM Distinguished Software Award Winner) • Uppaal-CORA (based on most widely used real-time model checker, Uppaal) • FF (Winner of the first International Planning Competition IPC4) extended to MIPS-XXL (Winner of the Distinguished Performance Award, IPC5). • External A* for 15-Puzzle (Fastest run time on hard problems when compared with the known results). • Largest state space: Optical Telegraph Protocol with 14 stations. • took about 3 Terabytes, while using only 3.5 Gigabytes of RAM taking 20 days. • Parallel Version on 4 Processors with shared NFS hard disk took 8 days only. • Models. • Spin: Dinning philosophers, optical telegraph, CORBA-GIOP, Elevator, SGC. • Uppaal-CORA: Aircraft landing scheduling, Re-modeling from PDDL (Henning Dierks, 05) • MIPS-XXL: Intr. Planning competition. Stefan Edelkamp

  31. Related Work • Kristensen and T. Mailund (ICFEM 03) – Sweep line algorithm on Petri nets. Saves the closed list on disk in the form of a spanning tree. • Hammer and Weber (FMICS 06) – Hash based partitioning of the whole state space. Utilizes compression and bloom filters. • Bao and Jones (TACAS 05) – Hash-based partitioning with each partition that can fit in the main memory. • Dill – Cache like mechanism to flush states. • Zhou and Hansen (AAAI 05) – Abstract state space construction where each equivalence class and its neighbors can fit into the main memory. • Holte et. al (AAAI 06) – Frontier search for Multiple sequence alignment. Stefan Edelkamp

  32. Summary • First disk-based algorithms for model checking with a formal model for I/O complexity analysis. • First ever External Liveness checking. • Real-Time MC in priced domains. • Can pause-and-resume your execution to add more hard disks. • Can be combined with other state-space reduction techniques – even with BDDs. • Largest exploration so far: 3 Terabytes • Issues: • Error trace: • No predecessor pointers! • Save the predecessor with each state. • Trace back from the goal state to the start state breadth-wise. • Disk space eaten by duplicate states: • Start “Early”Delayed Duplicate Detection • Sparse graphs – unfilled blocks. Stefan Edelkamp

  33. Contributions: Stefan Edelkamp

  34. Evolution of Contributions Stefan Edelkamp

  35. Future extensions • Sequence Alignment Problem • Probabilistic Search • Partial-Order Reduction • Program Model Checking – StEAM-XXL • Parallel External C++ Model Checking • In Implementation: • Pipelined I/Os – keep block in the memory as long as possible Stefan Edelkamp

  36. Thanks for your patience!Questions ?

More Related