Automated assume-guarantee reasoning for component verification

1. Automated assume-guarantee reasoning for component verification Dimitra Giannakopoulou (RIACS), Corina Păsăreanu (Kestrel) Automated Software Engineering NASA Ames Research Center Moffett Field, CA, USA

2. System-Level Verification for Autonomous Systems Verification is essential for autonomy insertion in missions executive plans commands • Objectives • Detect integration problems early • Support module-based verification (for scalability) • Design for verification • Approach • Software architecture design and verification • Module verification with generated assumptions • Design patterns / architectures for autonomous systems

3. satisfies P? • A M1 P • true M2 A • true M1 || M2 P Compositional Verification • Decompose properties of system (M1 || M2) in properties of its components • Does M1 satisfy P? • typically a component is designed to satisfy its requirements in specific contexts / environments • Assume-guarantee reasoning: introduces assumption A representing M1’s “context” • Simplest assume-guarantee rule M1 A M2 “discharge” the assumption

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

5. 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, …

6. Implementation in LTSA • Components modeled as labelled transition systems (LTS) • an LTS M has a communicating alphabet M • internal actions represented by action “ τ ” • LTSs assembled with parallel composition operator “||” • synchronizes shared actions, interleaves remaining actions • A property P is a safety LTS (an LTS with no error states) • P describes all legal behaviors with respect to P • Perr– determinize & complete P; bad behaviors lead to “error” • component M satisfies P iff error state unreachable in (M || Perr) • Assume-guarantee reasoning • assumptions and guarantees are safety LTSs • A M P holds iff error state unreachable in (A || M || Perr)

7. Example Input Order Ordererr in send in ack || out out in Output send out ack

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

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

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

11. A M1 P • true M2 A • true M1 || M2 P how are assumptions obtained? • developer encodes them explicitly • abstractions of other modules The problem our goal: • automate assume guarantee reasoning by generating appropriate assumptions for the rules

12. 1. Ai M1 P Framework, iteration i counterexample – strengthen assumption Model Checking Learning Learning Ai false 1. Ai M1 P true true P holds in M1||M2 2. true M2 Ai 2. true M2 Ai false real error? real error? N Y P violated in M1||M2 counterexample – weaken assumption

13. Learning with L* • L* algorithm by Angluin, improved by Rivest & Schapire • learning 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)

14. 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| • # queries:(kn2 + n logm) • m is size of largest counterexample, k is size of alphabet 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

15. M1 M2 satisfies P? • A M1 P • true M2 A • true M1 || M2 P Learning Assumptions • L* learns the weakest assumption Aw for M1 • for all environments E:( M1|| E satisfies P IFF Esatisfies Aw ) • a string sis in L (Aw) iff in the context of s, M1 satisfies P •  = Aw = (M1P) M2 • conjectures are intermediate assumptions Ai • framework may terminate before L* computes Aw • Aw is not available – how do we implement the Teacher ? • use model checking

16. 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 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)

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

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

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

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

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

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

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

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

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

26. Ames K9 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 property P: If the Executivethread reads the value of variable savedWakeupStruct, the ExecCondChecker thread should not read this value unless the Executive clears it first.

27. K9 Rover results • We check: true ExecCondChecker || Executive P • M1 = ExecCondChecker, M2 = Executive 8.639secs

28. Related Work • Assume-guarantee frameworks • Jones 83; Pnueli 84; Clarke, Long& McMillan 89; Grumberg & Long 91; Xu, de Roever & He 97; Henzinger, Qadeer & Rajamani 98; … • tool support: MOCHA; Calvin (static checking of Java); … • Assumption generation • Giannakopoulou, Păsăreanu & Barringer, 2002 • Interfaces for Compositional Reachability Analysis • Cheung & Kramer 1996, Krimm & Mounier 1997 • Learning system models • Groce, Peled, and Yannakakis, 2002 • Ammons, Bodik, and Larus, 2002

29. Conclusions & Extensions • framework for incremental assume-guarantee reasoning • general – relies on standard features of model checkers • extend framework to more than two components • carry out more & larger case studies • alternative approaches for generating assumptions • combine with abstraction to deal with source code • extend to liveness / fairness properties • L Algorithm, Maler and Pnueli, 1995 • timed systems

30. part 2: work in progress

31. A1 M1 P • A2 M2 P • true M2 A1 OR true M1 A2 • true M1 || M2 P Symmetric Rules • assumptions for both components at the same time • early termination • smaller assumptions • take simplest symmetric rule • the rule is sound and complete • completeness is essential for automation

32. P holds in M1||M2 Framework weaken weaken learning learning strengthen strengthen A2 A1 A1 M1 P A2 M2 P false false true true true M2 A1 true M1 A2 OR true false P violated in M1||M2 counterexample analysis

33. A1 M1 P • A2 M2 P • coA1|| coA2 =  • true M1 || M2 P Incorporation of other circular rules • a variety of assume guarantee rules exist in the literature • usually, they are sound but not complete • we make them complete by adding premise 3 to the rule • example: • the rule is sound but not complete

34. P holds in M1||M2 P violated in M1||M2 P violated in M1||M2 Framework weaken weaken learning learning strengthen strengthen A2 A1 A1 M1 P A2 M2 P false false true true coA1 || coA2 = false counterexample analysis false true M2 A1 true M1 A2 P holds in M1||M2 OR false counterexample analysis

35. Incorporation of other circular rules • a variety of assume guarantee rules exist in the literature • usually, they are sound but not complete • we make them complete by adding premise 3 to the rule • example – Chandy and Misra 1981: • the rule is sound but not complete • A1 M1 P • A2 M2 P • M1 @ A1, P, M2 @ A2 ,P • P |= A1, P |= A2 • true M1 || M2 P

36. Compositional verification for C • check C1||C2 |= P • use as much information as you can from previous iterations C1 C2 refine refine predicate abstraction predicate abstraction M1 M2 learning framework true C1||C2 |= P false counterexample analysis spurious spurious C1||C2|=P

37. C1||C2|=P C2 C1 Compositional verification for C (details) weaken A1 weaken A2 learning learning strengthen A1 strengthen A2 A2 A1 A1 M1 P A2 M2 P false false true true M1 M2 true M2 A1 true M1 A2 M1 M2 predicate abstraction predicate abstraction OR false strengthen M1 strengthen M2 counterexample analysis C1||C2|=P