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 required

2. Incremental assumption computation based on counterexamples, learning and knowledge of environment

Applications

Verification produces more precise answerstrue – property satisfied in all environments

false – property falsified in all environments

assumption 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 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

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

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 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,

minimizationProperty true!

(all environments)

Step 2: backward propagation

of 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.enterCS

E.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.enterCS

E.exitCS

E.exitCS

Error Propagation (with )

E.acquire

E.release

E.enterCS

E.exitCS

E.enterCS

E.release

E.enterCS

E.enterCS

E.exitCS

E.exitCS

Error Propagation (with )

E.acquire

E.release

E.enterCS

E.exitCS

E.enterCS

E.enterCS

E.exitCS

E.exitCS

E.release

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

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 Executive

Executes flexible plans for autonomy branching on state / temporal conditions

Multi-threaded systemcommunication 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

Properties

First 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 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

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.

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

false

2. 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* Algorithm

maintains a table that records whether strings in belong to Umakes 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 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|

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

out

Ordererr: 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

E

Table 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

E

Table T

S true

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

E

Table T

S true

out ?

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

E

Table T

S true

out 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

E

Table T

S true

out false

S ack

out

send

out, ack

out, out

out, sendS = set of prefixesE = set of suffixes

truefalse

true

falsefalse

false

Ordererr: in

out

out in

Output:

send

ack

out

Candidate Construction Input:

in

ack

send

E

Table T

S true

out false

S ack

out

send

out, ack

out, out

out, sendS = set of prefixesE = set of suffixes

truefalse

true

falsefalse

false

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 weak

2 – Oracle 1 2 (268, 1408) too weak

3 – Oracle 1 3 (235, 1209) too weak

4 – Oracle 1 5 (464, 2500) not too weak

Oracle 2

(32, 197) false

Comparisons

Pentium III, 500 MHz, 1 Gb of memory

check P on M1 || M2 » (3630 sts, 34653 trans), 0.535 secs.

using weakest assumption6 states

generation: (544 sts, 6314 trans), 24.623 secs

discharging assumption: (32 sts, 197 trans), 0.504 secs

using incremental assume-guarantee reasoning5 states

(max: 464 sts, 2500 trans), 8.639 secs

Related Work

Interface 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 synthesis

Interface equation / sub-module constructionMerlin-Bochmann, Shields, Parrow, Larsen-Xinxin

Synthesis of deadlock-free connectorsInverardi-Scriboni-Wolf-Yankelevich

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 generalrelies on standard features of model checkers

experimenting 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/