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/