refactoring design models for inductive verification

1

Refactoring Design Models for Inductive Verification

Yung-Pin ChengDept. of Info. & Comp. Edu.

National Taiwan Normal Univ.

TAIWAN

Michal YoungDept. of Comp. & Info. Sci.

Univ. of Oregon

USA

2

Outline

An overview of verifying parameterized concurrent systems

An overview of induction framework Using refactoring transformations to enable

induction framework for systems with parameterized behaviors

Related work Conclusion Future work

3

Parameterized concurrent systems

Concurrent systems can be parameterized in many ways, such as The number of identical components

e.g., processes The number of data values

e.g., the length of a bounded buffer The number of control commands

e.g., a protocol that allows retransmission of messages over a lossy channel at most n time

Increasing the size parameters often causes state explosion

4

The general verification problem of parameterized systems

: system of size i

: a family formed by

The verification problem: whether every in F satisfies a given property

Parameterization induces infinite-state space The problem is undecidable in general but

experience shows that many subclasses are decidable.

iS 1}{ iiSF iS

iS

5

Approaches to the problem1. Project the infinite-state space into finite-state space and

then apply the finite-state techniques Often limited to a particular topology of networks (such as

ring, chain, or a central control process with many identical user processes.)

Usually requires manual proof

2. Find a network invariant to pass the induction tests (which we call induction framework)

In principle, not restricted by network topology Induction test is automatic More popular The main problem is network invariant may not exist or

difficult to find (due to the undecidability)

6

Induction framework – An overview

By Wolper & Lovinfosse1989 and Kurshan & McMillan 1995.

A popular approach to extend finite-state verification techniques to verify parameterized systems

7

Induction framework – An overview

Assume ISS ii ||1 , where , where II is some identical is some identical componentcomponent

: a preorder relation (e.g., simulation relation) : a preorder relation (e.g., simulation relation) : a property of interest: a property of interest

such that such that

|)|()( PQQP

Find a network invariant Find a network invariant Inv Inv to pass three tests to pass three tests

InvIInv

InvS

Inv

|| )3(

)2(

| )1(

1

8

Induction framework – An overview

Why with the 3 tests?

1for |

||||||

||||||

||)||(

||

1

iS

InvIIS

InvIIInv

InvIIInv

InvIInv

i

InvIInv

InvS

Inv

|| )3(

)2(

| )1(

1

ISS ii ||1

(use assumption and (1))

(use (2))

(use (3))

9

How models can be affected by parameterization?

1. Models add/remove processes when the system size is increased/decreased(commonly seen in literature) Hardware systems Protocols that communcate by a shared bus

2. The behaviors (transition relation and number of states) of processes grow/shrink when the system size is increased/decreased communication channels of a process varied by size data values varied by size (e.g., buffer size) Some process needs to be aware of new process’s existence

10

How models are affected by parameterization? (Cont.)

Typical examples of the first kind

P1 P2 P3

S

The three process share thesame port of S(adding P4 does not changeS’s behaviors)

P1

P2

P3

P4

Ring structure: processesonly communicate with theirleft/right-hand sides.(only channel relabelling is neededwhile adding a new process)

11

How models are affected by parameterization? (Cont.)

An example of second kind

P1 P2 P3

S(n)

S(n) needs to be aware of every process’s existence and eachP_i must communicate with S(n) by a private channel

12

When the induction framework fails

For a system whose behaviors are parameterized by n

This is where the induction would fail This problem has been ignored or avoided in the past

111

1

||||||||)1(

||||||)(

nnn

nn

PPPnSG

PPnSG

11 || so, ,)()1( that Note nnn PGGnSnS

13

Synchronization structure transformed by refactoring

P1 P2 P3

S(n)

P1 P2 P3P1 P2 P3P1 P2 P3

T1 T2 T3

S S’s behavior is now independent of system size S’s behavior is now independent of system size So, if we increase the system size by one:So, if we increase the system size by one:

P1 P2 P3

T1 T2 T3

S

P4

T4

111 |||| nnnn TPGG It satisfies the assumption It satisfies the assumption

Induction framework is enabled by the new architectureInduction framework is enabled by the new architecture

14

Refactoring

Use a sequence of transformations (selected from a set) and apply them in a right order to transform a model into a final model

Each maintains behavioral equivalence (weak bisimulation)

n

TTT

MMMn

10

10

0MnM

iT

iT

15

Refactoring

PreprocessorModels in Design Languge e,g, Promela, Ada-like design language

LTSLTS

LTSLTS

Parallel CompositionGlobalState spaceanalysis

Property

Verificationresult

refactoring

16

A case study - a remote temperature sensor system (RTSS)[Yeh&Young 1994,Sanden 1989]

The parameterized control parts

The parameterized control parts

Lossy channel

17

Refactoring CP_MODULE (interface behaviors)

-send(0)

call(1) call(0)

-send(1)

-send(1)

-send(0)

call_end

call(1)

call(0)

call_endcall_end

CP_MODULE

INTR UI

• Modeled by CCS (Milner)

18

Refactoring strategy

A general refactoring strategy is to separate behaviors which are linked to different control parts for example

-send(0), call(0) furnace 0

-send(1), call(1) furnace 1

call_end ?

19

-call_end

Transformation I: Edge relabeling

INTR

-send(0)

call(1) call(0)

-send(1)

-send(1)

-send(0)

call_end

call(1)

call(0)

call_endcall_end

CP_MODULE UI

-call(0) -call_end

-call(1) -call_end(1)

Ada’s accept/do block or Promela’s atomic

call_end(1)

call_end(0)

call_end(1) call_end(0)

-call_end(0)

20

Behavioral equivalence

)}1(_),0(_{\)||_(

}_{\)||_(

endcallendcallINTRMODULECP

endcallINTRMODULECP

View CP_MODULE and INTR as a subsystem, we have

where is the weak bisimulation

21

call_end(0)

call(0)-send(0)

Transformation II: Behavior decompositionTransformation II: Behavior decomposition

CP_MODULE

call(1)

-send(1) call(1)

call_end(1)call_end(1)

1. Identify segment

-send(0)

call(0)

call_end(0)

2. Decompose segment and make it into a new process

-send(0)

call(0)

call_end(0)

-send(0)

call(0)

call_end(0)

-send(0)

call(0)

call_end(0)

-send(0)

call(0)

call_end(0)

-send(0)

call(0)

call_end(0)

-send(0)

call(0)

call_end(0)

3. Add new synchronizations to preserve equivalence

-send(1)

-send(0)

call(0)

call_end(0)

-get(0)

-release(0)

-send(0)

call(0)call_end(0)

CP_SUB0

-send(0)

release(0)

UI

release(0)

-send(0)get(0)

22

Transformation II: Behavior decomposition

• behavioral equivalence is again preserved as

)}0(),0(),1(),0({\)0_||_||(

)}1(),0({\)_||(

releasegetsendsendSUBCPMODULECPUI

sendsendMODULECPUI

23

Transformation III: Behavior decomposition

call(0)

-send(0)

call(0)

call_end(0)

-get(0)

-release(0)

-send(0)

call(0)call_end(0)

CP_SUB0

release(0)

release(0)

-get(1)

-release(1)

-send(1)

call(1)

call_end(1)

-send(1)

call(1)call_end(1)

release(1)

release(1)

-send(0)-get(1)

-send(0)-get(0)

-send(1)get(1)

UI

CP_SUB1

24

-send(0)-get(0)

-send(0)-get(1)

Transformation IV: Semaphore simplification

call(0)

-send(0)

call(0)

call_end(0)

-get(0)

-release(0)

-send(0)

call(0)call_end(0)

CP_SUB0

release(0)

release

-get(1)

-release(1)

-send(1)

call(1)

call_end(1)

release

release(1)

CP_SUB1

-send(1)

call(1)call_end(1)

-send(0)-get -release-get

-release

UI

-send(0)get

-send(1)get

• CCS two-way rendezvous

• When increase size by 1, we add another CP_SUB2

• The system may no longer meaningful to user

25

Refactoring of INTR

-call(0) alert0 -call_end(0)

-call(0) alert0

-call_end(0)

-call(1) alert1 -call_end(1)

-call(1) alert1

-call_end(1)

A0

B0

A1

B1

Emulate the loss of alert

A0

A0B0

B0

A1

A1

B1

B1

0 0

1 00 1

1 1

A0A1

26

The result of refactoring INTR

-get-release

-get -release

alert1

-call_end(1)

-call(1) alert1

release

-call(1)

alert1-call_end(1)

-call(1)

alert0

-call_end(0)

-call(0) alert0

release

-call(0)

alert0-call_end(0)

-call(0)

27

A summary of refactored RTSS

Task Name Names of tasks after refactoring

CP_MODULE CP_MODULECP_MODULE,, CP_SUB0, CP_SUB1

INTR INTRINTR,INTR_SUB0,INTR_SUB1

TINTR TINTR,TINTR, TINTR_SUB0, TINTR_SUB1

DP_MODULE

DP_MODULEDP_MODULE,DP_SUB0,DP_SUB1

UI UIUI,UI_SUB0,UI_SUB1

Device[i] Not refactored

Furnace[i] Not refactored

28

The induction of RTSS

00 ||||)1(

][||][

_||_||_||_||_

||_||||||_

RFCRTSS

iFurnaceiDeviceR

SUBiUISUBiDPSUBiTINTRSUBiINTRSUBiCPF

UIMODULEDPTINTRINTRMODULECPC

i

i

• The safety property is translated into a deadlock detection (Cheung & Kramer1999)• Property can be inserted into F0 and R0

send(0)

send_end(0)

send(1),alert1• for example

29

The induction of RTSS (cont)

InvIInv

InvS

Inv

|| )3(

)2(

| )1(

1

We need to find a network invariant to passWe need to find a network invariant to pass

Note that we replace the preorder by weak bisimulationNote that we replace the preorder by weak bisimulation

Let Let Inv=Inv= RTSS(1) \{actions linked to furnace 0} RTSS(1) \{actions linked to furnace 0} Finally, we test (3) by checking Finally, we test (3) by checking

InvRFInv ii i} furnace tolinked actions{\)||||(

Inv Inv is an effective network invariantis an effective network invariant

30

Other systems

A continuously running part of elevator system

Alternating bit protocol …….

31

Related work

Yeh and Young [STVR 1994] Redesign RTSS for compositional analysis

Avrunin et. al. [UMass technical report,1999] Chiron interface – a decomposed dispatcher task

Valmari and Kokkarinen [ ICACSD 1998] A protocol that can retransmit the message at most n times With a brave titile: …10^any states and beyond CSP (multi-way rendezvous)

32

Conclusion

We propose a technique called refactoring to transform (equivalence preserving) system structure

We enable induction framework for systems with parameterized behaviors

Partially automated tool support

33

Future research

More tool support Full automation for subclasses Looking for a unified family of transformations Extend refactoring to Java threads

Question?

34

A prototype Chera

35

A prototype

36

Refactoring of INTR (cont).

A0

A0B0

B0

A1

0 0

1 00 1

1 1

A0

B0

A0

B0

A1

B1A1

B1

A0

B0

A0

B0