automated assume-guarantee reasoning for component verification
DESCRIPTION
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. System-Level Verification for Autonomous Systems. - PowerPoint PPT PresentationTRANSCRIPT
Automated assume-guarantee reasoning for component verification
Dimitra Giannakopoulou (RIACS), Corina Păsăreanu (Kestrel)
Automated Software EngineeringNASA Ames Research CenterMoffett Field, CA, USA
System-Level Verification for Autonomous Systems
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
Verification is essential for autonomy insertion
in missions
commands
plansexecutive
Compositional Verification
M2
M1
A
satisfies P?
Decompose properties of system (M1 || M2) in properties of its componentsDoes 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
“discharge” the assumption
1. A M1 P2. true M2 A
3. true M1 || M2 P
Approach
Infer assumptions automatically
Two novel solutions developed1. Algorithmic generation of assumption (controller);
knowledge of environment is not required2. Incremental assumption computation based on
counterexamples, learning and knowledge of environment
ApplicationsVerification produces more precise answers
true – property satisfied in all environmentsfalse – property falsified in all environmentsassumption A – property true in environments where A is true
Support for compositional verificationProperty decomposition Assumptions for assume-guarantee reasoning
Runtime monitoring of environmentassumption monitors actual environment during deployment may trigger recovery actions
Component retrieval, sub-module construction, …
Implementation in LTSAComponents 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 reasoningassumptions and guarantees are safety LTSsA M P holds iff error state unreachable in (A || M || Perr)
Example Input
in send
ack
Output outsend
ack
Ordererr in
out
Order
in out||
Solution 1in 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
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
Assumption Generation
Step 1: composition, hiding, minimization
Property true!(all environments)
Step 2: backward propagationof error with
Property false!(all environments)
Step 3: property extraction (subset construction and completion)
Assumption
The problem1. A M1 P2. true M2 A
3. true M1 || M2 P
our goal:automate assume guarantee reasoning by generating appropriate assumptions for the rules
developer encodes them explicitly
abstractions of other modules
how are assumptions obtained?
Framework, iteration i
Model Checking
1. Ai M1 P
Learning
realerror?
2. true M2 Ai
Ai
counterexample – strengthen assumption
counterexample – weaken assumption
false
truetrue
false
YN
P holds in M1||M2
P violated in M1||M2
Learning 1. Ai M1 P
realerror?
2. true M2 Ai
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 s in U ?
conjectures: for a candidate DFA Ci, is L(Ci) = U ?– answers are (true) or (false + counterexample)
The L* Algorithmmaintains 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
General method:
Characteristics:terminates with minimal automaton C for unknown language U
each candidate Ci is smallestany 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
Learning Assumptions
L* learns the weakest assumption Aw for M1
for all environments E: ( M1|| E satisfies P IFF E satisfies 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
M2M1
satisfies P? 1. A M1 P2. true M2 A
3. true M1 || M2 P
The TeacherMembership 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 analysisSimulate 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)
Output send
ack
out
Ordererr in
out out in
Example Input
in
ack
send
We check: true Input || Output OrderM1 = Input, M2 = Output, P = Order
Assumption’s alphabet: {send, out, ack}
Ordererr in
out out in
Output send
ack
out
Membership Queries Input
in
ack
send
ETable T
S ?out
S ack
out
send
out, ack
out, out
out, sendS = set of prefixesE = set of suffixes
L(Aw)?
Simulate on Input || Ordererr
Yes!
Ordererr in
out out in
Output send
ack
out
Membership Queries Input
in
ack
send
ETable T
S trueout
S ack
out
send
out, ack
out, out
out, sendS = set of prefixesE = set of suffixes
L(Aw)?
Simulate on Input || Ordererr
Yes!
Ordererr in
out out in
Output send
ack
out
Membership Queries Input
in
ack
send
ETable T
S trueout ?
S ack
out
send
out, ack
out, out
out, sendS = set of prefixesE = set of suffixes
<out> L(Aw)?
Simulate<out> on Input || Ordererr
No!
Ordererr in
out out in
Output send
ack
out
Membership Queries Input
in
ack
send
ETable T
S trueout false
S ack
out
send
out, ack
out, out
out, sendS = set of prefixesE = set of suffixes
<out> L(Aw)?
Simulate<out> on Input || Ordererr
No!
Ordererr in
out out in
Output send
ack
out
Membership Queries Input
in
ack
send
ETable T
S trueout false
S ack
out
send
out, ack
out, out
out, sendS = set of prefixesE = set of suffixes
truefalsetruefalsefalsefalse
Ordererr in
out out in
Output send
ack
out
Candidate Construction Input
in
ack
send
ETable T
S trueout false
S ack
out
send
out, ack
out, out
out, sendS = set of prefixesE = set of suffixes
acksend
2 states – error state not added to assumption
Assumption A1truefalsetruefalsefalsefalse
Ordererr in
out out in
Output send
ack
out
Conjectures Input
in
ack
send
acksend
A1: Oracle 1: A1 Input Order
Counterexample:c = in,send,ack,in
Return to L*:c = send,ack
Oracle 1: A2 Input Order
True
Oracle 2: true Output A2
True
property Order holds on Input || Output
ack
send
out, send
A2:Queries
Output send
ack
out sendOrdererr in
out out in
Another Example Input
in
ack
send
Oracle 2: true Output’ A2
Counterexample:c=send,send,out
ack,out,send
ack
send out
ack
send
send
A4: property Order holds
on Input || Output’
Simulate c= send,send,out on M1||Ordererr
Return c to L*not a real error!
real error?
Ames K9 Rover ExecutiveExecutes flexible plans for autonomy
branching on state / temporal conditions
Multi-threaded systemcommunication through shared variablessynchronization through mutexes and condition variables
Systematic translation of design documents into input language of LTSA
Several synchronization issues
If the Executive thread reads the value of variable savedWakeupStruct, the ExecCondChecker thread should not read this value unless the Executive clears it first.
property P:
K9 Rover results
iteration |Ai| (#states, #trans) result1 – Oracle 1 1 (5, 24) too weak2 – Oracle 1 2 (268, 1408) too weak3 – Oracle 1 3 (235, 1209) too weak4 – Oracle 1 5 (464, 2500) not too weak Oracle 2 (32, 197) false
We check: true ExecCondChecker || Executive P
M1 = ExecCondChecker, M2 = Executive
8.639secs
Check M1 || M2 || P: (3630 sts, 34653 trans), 0.535 secs
Related WorkAssume-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 generationGiannakopoulou, Păsăreanu & Barringer, 2002
Interfaces for Compositional Reachability AnalysisCheung & Kramer 1996, Krimm & Mounier 1997
Learning system modelsGroce, Peled, and Yannakakis, 2002Ammons, Bodik, and Larus, 2002
Conclusions & Extensionsframework 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 propertiesL Algorithm, Maler and Pnueli, 1995
timed systems
part 2:work in progress
Symmetric Rulesassumptions for both components at the same time
early terminationsmaller assumptions
take simplest symmetric rule
the rule is sound and completecompleteness is essential for automation
1. A1 M1 P
2. A2 M2 P
3. true M2 A1 OR true M1 A2
true M1 || M2 P
Frameworklearning
A1 M1 P
learning
A2 M2 P
A1 A2
false false
true M2 A1 true M1 A2
OR
counterexampleanalysis
true true
false
P holds in M1||M2
P violated in M1||M2
weakenweaken
strengthen strengthen
true
Incorporation of other circular rules
a variety of assume guarantee rules exist in the literatureusually, they are sound but not completewe make them complete by adding premise 3 to the ruleexample:
the rule is sound but not complete
A1 M1 P
A2 M2 P
coA1 || coA2 =
true M1 || M2 P
Frameworklearning
A1 M1 P
learning
A2 M2 P
A1 A2
false false
true M2 A1 true M1 A2
OR
true true
false
P holds in M1||M2
P violated in M1||M2
weakenweaken
strengthen strengthen
coA1 || coA2 =
false
P holds in M1||M2
counterexampleanalysis
counterexampleanalysis
falseP violated in M1||M2
Incorporation of other circular rules
a variety of assume guarantee rules exist in the literatureusually, they are sound but not completewe make them complete by adding premise 3 to the ruleexample – 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
Compositional verification for C
C1||C2|=Pspurious
C1||C2 |= Ptrue
false
counterexampleanalysis
learning framework
predicate abstraction
M1
C1
predicate abstraction
M2
refine
check C1||C2 |= P
use as much information as you can from previous iterations
C2
refine
spurious
Compositional verification for C (details)
learning
A1 M1 P
learning
A2 M2 P
A1 A2
false
true M2 A1 true M1 A2OR
counterexampleanalysis
true true
false
C1||C2|=P
C1||C2|=P
weaken A1
strengthen A1 strengthen A2
M1
predicateabstraction
C1
predicateabstraction
C2
weaken A2
strengthen M1 strengthen M2
M2
false
M1 M2