Concrete Model Checking with Abstract Matching and Refin...(PPT-33)文档.pptVIP

24 September 2002 ? Willem Visser 2002 Concrete Model Checking with Abstract Matching and Refinement Corina P?s?reanu QSS, NASA Ames Research Center Radek Pelánek Masaryk University, Brno, Czech Republic Willem Visser RIACS/USRA, NASA Ames Research Center Introduction Abstraction in software verification Used to reduce data domains of a program Described as abstract interpretation Classic approach: over-approximation SLAM, Blast, Magic; see also Bandera, Feaver Preserves true results Abstract counter-examples may be infeasible Counter-example based iterative refinement Our approach: Under-approximation based abstraction with refinement Goal: error detection Explores only feasible system behaviors Preserves errors of safety properties Iterative refinement based on checking “exactness” of abstraction Predicate Abstraction Maps a (possibly infinite state) concrete transition system into a finite state system Via a set of predicates: Preds = {p1, p2 … pn} Abstraction function a: ConcreteStates → BitVectors a(s) = b1b2…bn, bi=1 ? s╞ pi Traditional approaches: May abstract transitions: Over-approximate concrete transitions a1 →may a2 : ? s1 s.t. a(s1)= a1 and ? s2 s.t. a(s2)=a2, s.t. s1 → s2 Must abstract transitions: Under-approximate concrete transitions a1 →must a2 : ? s1 s.t. a(s1)= a1, ? s2 s.t. a(s2)=a2 and s1 → s2 Compute may/must transitions automatically: Use a theorem prover/decision procedure: require 2n × n × 2 calls Our Approach Concrete search with abstract matching: Traverse the concrete system For each explored concrete state Store abstract version of the state Use predicate abstraction Abstract state used to determine if the search should continue or backtrack Does not build abstract transitions It executes the concrete transitions directly Decision procedure invoked during refinement: At most 2 calls for each explored transition Example Example Example Example Example Example Example Example (Concrete) Search Algorithm