Automatic Assumption Generation for Compositional Verification

1. Automatic Assumption Generation for Compositional Verification Dimitra Giannakopoulou (RIACS), Corina Păsăreanu (Kestrel) Automated Software Engineering NASA Ames Research Center Moffett Field, CA, USA

2. satisfies P? how are assumptions obtained? • Developer encodes them explicitly • Abstractions of environment, if known Component Verification • Checking component C against property P : YES: in allenvironments E : (C╞ P ) NO: in someenvironment E :¬(C╞ P ) • Typically a component is designed to satisfy its requirements in specific environments Component • Introduce environment assumption A and check: • assuming A, C╞P – assume / guarantee • E ╞ A – discharge the assumption Assumption Environment

3. Approach • Infer assumptions automatically • Two novel solutions developed • Algorithmic generation of assumption; knowledge of environment is notrequired • Incremental assumption computation based on counterexamples, learning and knowledge of environment

4. Applications • Verification produces more precise answers • true – property satisfied in all environments • false – property falsified in all environments • assumption A – property true in environments where A is true • Support for compositional verification • Property decomposition • Assumptions for assume-guarantee reasoning • Runtime monitoring of environment • assumption monitors actual environment during deployment • may trigger recovery actions • Component retrieval, sub-module construction, …

5. Solution 1 • in collaboration with Prof. Howard Barringer, Univ. of Manchester, UK • Giannakopoulou, D., Păsăreanu, C., and Barringer, H., “Assumption Generation for Software Component Verification”, in Proc. of the 17th IEEE International Conference on Automated Software Engineering (ASE 2002). Awards: Best paper, ACM Distinguished Paper Award

6. The Problem • Given component C, property P, and the interface of C with its environment, generate the weakest environment assumption A such that: assuming A, C╞ P • Weakest means that for all environments E: (E || C╞P) IFFE╞A

7. Implementation • Labeled Transition Systems Analyzer (LTSA) • Components modeled as labelled transition systems (LTSs) • communicate by rendezvous through shared actions • internal actions represented by action “ τ ” • Compositionalreachability analysis • hiding of internal actions • minimization w.r.t. observational equivalence • Properties also expressed as LTSs • Describe all legal behaviors • Deterministic • Completed for verification – bad behaviors lead to “error state” • Composed with components – verification is postponed until the system is “closed” • An LTS can be used as a property or an assumption

8. Mutual Exclusion Property: W.acquire W.enterCS E.enterCS W.enterCS W.exitCS W.release E.exitCS W.exitCS || W.exitCS E.exitCS W.enterCS W.enterCS W.exitCS E.enterCS E.enterCS E.exitCS Example Writer: || Mutex: E.acquire W.acquire W.release E.release

9. Property true! (all environments) Step 2: backward propagation of error with  Property false! (all environments) Step 3: property extraction (subset construction and completion) Assumption Assumption Generation Step 1: composition, hiding, minimization

10. Composite System E.enterCS E.release E.acquire E.enterCS E.exitCS E.release E.acquire E.exitCS E.exitCS E.enterCS t E.enterCS E.exitCS E.enterCS

11. E.enterCS E.release E.acquire E.exitCS t E.enterCS Error Propagation (with t) E.acquire E.enterCS E.exitCS E.release E.exitCS E.enterCS E.enterCS E.exitCS

12. E.enterCS E.release Error Propagation (with t) E.acquire E.enterCS E.exitCS E.release E.exitCS E.enterCS E.enterCS E.exitCS

13. Error Propagation (with t) E.acquire E.enterCS E.exitCS E.release E.release E.exitCS E.enterCS E.enterCS E.exitCS

14. E.acquire, E.release E.enterCS, E.exitCS E.release E.acquire E.acquire Property Extraction E.enterCS E.acquire E.exitCS E.release E.enterCS E.exitCS E.enterCS E.release E.exitCS

15. E.acquire, E.release E.enterCS, E.exitCS E.release E.acquire E.acquire Generated Assumption E.enterCS E.acquire E.exitCS E.release

16. Ames Rover Executive • Executes flexible plans for autonomy • branching on state / temporal conditions • Multi-threaded system • communication through shared variables • synchronization through mutexes and condition variables • Systematic translation of design documents into input language of LTSA • Several synchronization issues • mutual exclusion • data races • properties specified by developer

17. {hiding + minimization} {hiding + minimization} Properties • First property: mutual exclusion • 426 states 18 states • assumption: 12 states • Second property: • 544 states 10 states • assumption: 6 states If the Executive thread reads the value of variable savedWakeupStruct, the ExecCondChecker thread should not read this value unless the Executive clears it first.

18. not displaying sink state Q1 Resulting Assumption Assumption_Property2 = Q0, Q0 = ( external.exec.lock -> Q2), Q2 = ( external.exec.unlock -> Q0 | external.savedWakeupStruct.read[1] -> Q3 | external.savedWakeupStruct.assign[0] -> Q4 | external.savedWakeupStruct.read[0] -> Q5), Q3 = ( external.savedWakeupStruct.read[1] -> Q3 | external.savedWakeupStruct.assign[0] -> Q4), Q4= ( external.exec.unlock -> Q0 | external.savedWakeupStruct.assign[0] -> Q4 | external.savedWakeupStruct.read[0] -> Q5), Q5 = ( external.savedWakeupStruct.assign[0] -> Q4 | external.savedWakeupStruct.read[0] -> Q5).

19. Solution 2 • in collaboration with RIACS SSRP student Jamieson Cobleigh, Univ. of Massachusetts, Amherst • Cobleigh, J.M., Giannakopoulou, D., and Pasareanu, C.S. “Learning Assumptions for Compositional Verification”, in Proc. ofthe 9th International Conference on Tools and Algorithms for the Construction and Analysis of Systems (TACAS 2003). April 2003, Warsaw, Poland.

20. A satisfies P? • A M1 P • true M2 A • true M1 || M2 P The problem M1 M2 • Automate assume guarantee reasoning • Simplest assume-guarantee rule, no circularity, useful for safety properties:

21. Learning Our Framework Incremental Compositional Verification counterexample – strengthen assumption Model Checking false Ai 1. Ai M1 P true true P holds in M1||M2 2. true M2 Ai false real error? no yes P violated in M1||M2 counterexample – weaken assumption

22. Learning with L* • L* – learning algorithm by Angluin, improved by Rivest & Schapire • based on queries and counterexamples • learns an unknown regular language (U over alphabet) and produces a DFA C such that L (C) = U • constructs a sequence of DFAs C1, C2, … converging to C • needs a Teacher to answer two types of questions: • membership queries: is string sin U ? • conjectures: for a candidate DFA Ci, is L(Ci) = U ? • answers are (true) or (false + counterexample)

23. Characteristics: • terminates with minimal automaton C for unknown language U • each candidate Ci is smallest • any DFA consistent with table has at least as many states as Ci • |C1| < | C2| < … < |C| • produces at most n candidates, where n = |C| The L* Algorithm General method: • maintains a table that records whether strings in  belong to U • makes membership queries to update it • decides to make a conjecture – uses table to build a candidate Ci • if Teacher replies true, done! • if Teacher replies false, uses counterexample to update the table

24. M1 M2 satisfies P? • A M1 P • true M2 A • true M1 || M2 P Learning for Assume-Guarantee Reasoning • L* learns the language of weakest assumption Aw for M1 • Alphabet = (M1P) M2 • Conjectures are intermediate assumptions Ai • Algorithm may terminate before computing Aw • Aw is not available – how do we implement the Teacher ? • Use model checking

25. The Teacher • Membership query: trace s • Simulate s on M1 || Perr • If it leads to error state, reply false ( s  L(Aw) ) • Otherwise, reply true ( s L(Aw) ) • Conjecture:Ai • Oracle 1: performs (Step 1) Ai M1 P • If false (with counterexample c): provide c to L* (assumption is too weak) • If true: forward Ai to Oracle 2 • Oracle 2: performs (Step 2) true M2 Ai • If true: done! (P holds on M1 || M2) • If false (with counterexample c): forward c to analysis • Counterexample analysis • Simulate c on M1 || Perr • If it leads to the error state: done! (P does not hold on M1 || M2) • Otherwise, provide c to L* (assumption is too strong)

26. Input: Output: out send send in ack ack Example Ordererr: in out in out • We check: true Input || Output Order • M1 = Input, M2 = Output, Property = Order • Assumption’s alphabet: {send, out, ack}

27. Output: out send ack Yes! lL(Aw)? Membership Queries Input: Ordererr: in send in out in out ack Simulate l on Input || Ordererr S = set of prefixes E = set of suffixes

28. Output: out send ack Yes! lL(Aw)? Membership Queries Input: Ordererr: in send in out in out ack Simulate l on Input || Ordererr S = set of prefixes E = set of suffixes

29. Output: out send ack No! <out>L(Aw)? Membership Queries Input: Ordererr: in send in out in out ack Simulate<out> on Input || Ordererr S = set of prefixes E = set of suffixes

30. Output: out send ack No! <out>L(Aw)? Membership Queries Input: Ordererr: in send in out in out ack Simulate<out> on Input || Ordererr S = set of prefixes E = set of suffixes

31. Output: out send ack Membership Queries Input: Ordererr: in send in out in out ack true false true false false false S = set of prefixes E = set of suffixes

32. Output: out send ack ack send Candidate Construction Input: Ordererr: in send in out in out ack 2 states – error state not added to assumption true false Assumption A1: true false false false S = set of prefixes E = set of suffixes

33. Input: Output: out send send in Ordererr: in ack ack out in out Return to L*: cS=send,ack Counterexample: c=in,send,ack,in • Oracle 1: • A1 Input Order A1: Queries ack ack send A2: send • Oracle 2: • true Output A2 True • Oracle 1: • A2 Input Order True out • property Order holds • on Input || Output send Conjectures

34. Output’: out send send Ordererr: in ack out in out A2: send A1: Counterexample: c=send,send,out Oracle 2: true Output’ A2 out,send ack A4: A3: send Not a real error! Simulate cS=c on M1||Ordererr out send Return c to L* ack ack out send ack send send send ack ack,out,send ack,out,send • property Order holds • on Input || Output’ Another Example Input: send in ack

35. Case Study: K9 Rover again

36. Comparisons • Pentium III, 500 MHz, 1 Gb of memory • check P on M1 || M2 • (3630 sts, 34653 trans), 0.535 secs. • using weakest assumption • 6 states • generation: (544 sts, 6314 trans), 24.623 secs • discharging assumption: (32 sts, 197 trans), 0.504 secs • using incremental assume-guarantee reasoning • 5 states • (max: 464 sts, 2500 trans), 8.639 secs

37. Related Work • Interface automata (de Alfaro, Henzinger) • component compatibility • Assume-guarantee frameworks • MOCHA, Calvin (extended static checking of Java), … • Interfaces for Compositional Reachability Analysis • Graf-Steffen-Lüttgen, Cheung-Kramer, Krimm-Mounier • Controller synthesis • Interface equation / sub-module construction • Merlin-Bochmann, Shields, Parrow, Larsen-Xinxin • Synthesis of deadlock-free connectors • Inverardi-Scriboni-Wolf-Yankelevich

38. Conclusions & Extensions • Model checking components as open systems • Assumptions can be further analyzed • do components that implement them, or the resulting system, have any useful behavior? • Incremental framework is general • relies on standard features of model checkers • experimenting with JPF • More case studies • Learning box – improve / change algorithm? • Extended properties (deadlock, liveness, fairness) • Timed systems

39. Contact {dimitra, pcorina} @ email.arc.nasa.gov http://ase.arc.nasa.gov/

40. DEMO

41. Contact {dimitra, pcorina} @ email.arc.nasa.gov http://ase.arc.nasa.gov/