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

3. Approach Infer assumptions automatically Two novel solutions developed 1.Algorithmic generation of assumption; knowledge of environment is not required 2.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) IFF E╞ 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 “ τ ” Compositional reachability 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. E.acquire E.release W.acquire W.release Mutex: Example W.acquire W.release W.enterCS W.exitCS Writer: || Mutual Exclusion Property: E.enterCS E.exitCS W.enterCS W.exitCS W.enterCS W.exitCS E.exitCS W.exitCS E.enterCS W.enterCS E.exitCS E.enterCS

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

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

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

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

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

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

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

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. Properties First property: mutual exclusion –426 states 18 states –assumption: 12 states Second property: –544 states 10 states –assumption: 6 states {hiding + minimization} 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. 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). not displaying sink state Q1

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. of the 9th International Conference on Tools and Algorithms for the Construction and Analysis of Systems (TACAS 2003). April 2003, Warsaw, Poland.

20. Automate assume guarantee reasoning Simplest assume-guarantee rule, no circularity, useful for safety properties: The problem M2M2 M1M1 satisfies P? A 1.  A  M 1  P  2.  true  M 2  A  3.  true  M 1 || M 2  P 

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

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 C 1, C 2, … converging to C needs a Teacher to answer two types of questions: membership queries: is string s in U ? conjectures: for a candidate DFA C i, is L (C i ) = U ? –answers are (true) or (false + counterexample)

23. The L* Algorithm 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 C i if Teacher replies true, done! if Teacher replies false, uses counterexample to update the table General method: Characteristics: terminates with minimal automaton C for unknown language U each candidate C i is smallest any DFA consistent with table has at least as many states as C i |C 1 | < | C 2 | < … < |C| produces at most n candidates, where n = |C|

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

25. The Teacher Membership query: trace s Simulate s on M 1 || P err –If it leads to error state, reply false ( s  L (A w ) ) –Otherwise, reply true ( s  L (A w ) ) Conjecture: A i Oracle 1: performs (Step 1)  A i  M 1  P  –If false (with counterexample c): provide c  to L* (assumption is too weak) –If true: forward A i to Oracle 2 Oracle 2: performs (Step 2)  true  M 2  A i  –If true: done! (P holds on M 1 || M 2 ) –If false (with counterexample c): forward c to analysis Counterexample analysis Simulate c  on M 1 || P err –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. Output: send ack out Order err : in out in Example Input: in ack send We check:  true  Input || Output  Order  M 1 = Input, M 2 = Output, Property = Order Assumption’s alphabet: {send, out, ack}

27. Order err : in out in Output: send ack out Membership Queries Input: in ack send E Table T S ? out S  S   ack out send out, ack out, out out, send S = set of prefixes E = set of suffixes  L (A w )? Simulate  on Input || Order err Yes!

28. Order err : in out in Output: send ack out Membership Queries Input: in ack send E Table T S true out S  S   ack out send out, ack out, out out, send S = set of prefixes E = set of suffixes  L (A w )? Simulate  on Input || Order err Yes!

29. Order err : in out in Output: send ack out Membership Queries Input: in ack send E Table T S true out ? S  S   ack out send out, ack out, out out, send S = set of prefixes E = set of suffixes  L (A w )? Simulate  on Input || Order err No!

30. Order err : in out in Output: send ack out Membership Queries Input: in ack send E Table T S true outfalse S  S   ack out send out, ack out, out out, send S = set of prefixes E = set of suffixes  L (A w )? Simulate  on Input || Order err No!

31. Order err : in out in Output: send ack out Membership Queries Input: in ack send E Table T S true outfalse S  S   ack out send out, ack out, out out, send S = set of prefixes E = set of suffixes true false true false

32. Order err : in out in Output: send ack out Candidate Construction Input: in ack send E Table T S true outfalse S  S   ack out send out, ack out, out out, send S = set of prefixes E = set of suffixes true false true false ack send 2 states – error state not added to assumption Assumption A 1 :

33. L* membership queries E Table T S ? out S  S   ack out send out, ack out, out out, send is empty string in U? S = set of prefixes E = set of suffixes

34. L* membership queries in ack send Input Order err in out in E T S ? out S  S   ack out send out, ack out, out out, send true yes!

35. L* membership queries E T S true out ? S  S   ack out send out, ack out, out out, send is in U?

36. L* membership queries in ack send Input Order err in out in E T S true out ? S  S   ack out send out, ack out, out out, send no! false

37. L* membership queries in ack send Input Order err in out in no! is in U?

38. L* membership queries in ack send Input Order err in out in E T S true out ? S  S   ack out send out, ack out, out out, send no! false

39. Candidate Construction E T S true outfalse S  S   sendtrue outfalse acktrue out, ackfalse out, outfalse out, sendfalse ack send 2 states – error state not added to assumption

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

41. Output’: send ack out send Order err : in out in Another Example Input: in ack send ack send A1:A1: ack send out,send A2:A2: Oracle 2:  true  Output’  A 2  Counterexample: c=  send,send,out  send ack,out,send send ack out A3:A3: ack,out,send ack send out ack send A4:A4: property Order holds on Input || Output’ Simulate c  c on M 1 ||Order err Return c to L* Not a real error!

42. Case Study: K9 Rover again iteration|A i |(#states, #trans)result 1 – Oracle 11(5, 24)too weak 2 – Oracle 12(268, 1408)too weak 3 – Oracle 13(235, 1209)too weak 4 – Oracle 15(464, 2500)not too weak Oracle 2(32, 197)false

43. Comparisons Pentium III, 500 MHz, 1 Gb of memory check P on M 1 || M 2 »(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

44. 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

45. 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

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

47. DEMO

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