Automatic Assumption Generation for Compositional Verification
Dimitra Giannakopoulou (RIACS), Corina Păsăreanu (Kestrel)
Automated Software EngineeringNASA Ames Research CenterMoffett Field, CA, USA
Component VerificationChecking 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?
Approach
Infer assumptions automatically
Two novel solutions developed1. Algorithmic generation of assumption;
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, …
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
ImplementationLabeled 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 LTSsDescribe 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
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
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
Composite System E.enterCS
E.acquire
E.release
E.enterCS
E.exitCS
E.exitCS
E.release
E.acquire
E.enterCS
E.enterCS
E.enterCSE.exitCS
E.exitCS
Error Propagation (with )
E.acquire
E.release
E.enterCS
E.exitCS
E.enterCS
E.release
E.exitCS
E.acquire
E.enterCS
E.enterCS
E.enterCSE.exitCS
E.exitCS
Error Propagation (with )
E.acquire
E.release
E.enterCS
E.exitCS
E.enterCS
E.release
E.enterCS
E.enterCSE.exitCS
E.exitCS
Error Propagation (with )
E.acquire
E.release
E.enterCS
E.exitCS
E.enterCS
E.enterCSE.exitCS
E.exitCS E.release
Property Extraction
E.acquire
E.release
E.enterCS
E.exitCS
E.enterCS E.release
E.exitCSE.enterCS E.exitCS
E.acquire E.release E.acquire
E.acquire, E.release E.enterCS, E.exitCS
Generated Assumption
E.acquire
E.release
E.enterCS
E.exitCS
E.acquire E.release E.acquire
E.acquire, E.release E.enterCS, E.exitCS
Ames 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 mutual exclusiondata racesproperties specified by developer
PropertiesFirst property: mutual exclusion
– 426 states 18 states – assumption: 12 states
Second property:
– 544 states 10 states – assumption: 6 states
{hiding + minimization}
{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.
Resulting AssumptionAssumption_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
Solution 2in 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.
Automate assume guarantee reasoning
Simplest assume-guarantee rule, no circularity, useful for safety properties:
The problem
M2M1
satisfies P?
A
1. A M1 P2. true M2 A
3. true M1 || M2 P
Our Framework
Model Checking
Ai
counterexample – weaken assumption
counterexample – strengthen assumption
P holds in M1||M2
P violated in M1||M2
true
false
true
false2. true M2 Ai
real error?
1. Ai M1 PLearning
yesno
Incremental Compositional Verification
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 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|
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
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 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 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
outOrdererr: in
out out in
Example Input:
in
ack
send
We check: true Input || Output OrderM1 = Input, M2 = Output, Property = 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 ackoutsendout, ackout, outout, sendS = set of prefixes
E = 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 ackoutsendout, ackout, outout, sendS = set of prefixes
E = 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 ackoutsendout, ackout, outout, sendS = set of prefixes
E = 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 ackoutsendout, ackout, outout, sendS = set of prefixes
E = 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 ackoutsendout, ackout, outout, sendS = set of prefixes
E = 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 ackoutsendout, ackout, outout, sendS = set of prefixes
E = set of suffixes
truefalsetruefalsefalsefalse
acksend
2 states – error state not added to assumption
Assumption A1:
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
outsend
A2:Queries
Output’: send
ack
out sendOrdererr: in
out out in
Another Example Input:
in
ack
send
acksend
A1: ack
send
out,send
A2:Oracle 2:
true Output’ A2Counterexample:c=send,send,out
send
ack,out,send
send
ack out
A3:
ack,out,send
ack
send out
ack
send send
A4:
property Order holds on Input || Output’
Simulate cc on M1||Ordererr
Return c to L*Not a real error!
Case Study: K9 Rover again
iteration |Ai| (#states, #trans) result
1 – 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
ComparisonsPentium III, 500 MHz, 1 Gb of memory
check P on M1 || M2 » (3630 sts, 34653 trans), 0.535 secs.
using weakest assumption6 statesgeneration: (544 sts, 6314 trans), 24.623 secsdischarging assumption: (32 sts, 197 trans), 0.504 secs
using incremental assume-guarantee reasoning5 states(max: 464 sts, 2500 trans), 8.639 secs
Related WorkInterface automata (de Alfaro, Henzinger)
component compatibility
Assume-guarantee frameworksMOCHA, Calvin (extended static checking of Java), …
Interfaces for Compositional Reachability AnalysisGraf-Steffen-Lüttgen, Cheung-Kramer, Krimm-Mounier
Controller synthesisInterface equation / sub-module construction
Merlin-Bochmann, Shields, Parrow, Larsen-Xinxin
Synthesis of deadlock-free connectorsInverardi-Scriboni-Wolf-Yankelevich
Conclusions & ExtensionsModel 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 generalrelies on standard features of model checkersexperimenting with JPF
More case studies
Learning box – improve / change algorithm?
Extended properties (deadlock, liveness, fairness)
Timed systems
Contact
{dimitra, pcorina} @ email.arc.nasa.govhttp://ase.arc.nasa.gov/
DEMO
Contact
{dimitra, pcorina} @ email.arc.nasa.govhttp://ase.arc.nasa.gov/