View
30
Download
3
Category
Tags:
Preview:
DESCRIPTION
Refactoring Design Models for Inductive Verification. Yung-Pin Cheng Dept. of Info. & Comp. Edu. National Taiwan Normal Univ. TAIWAN Michal Young Dept. of Comp. & Info. Sci. Univ. of Oregon USA. Outline. An overview of verifying parameterized concurrent systems - PowerPoint PPT Presentation
Citation preview
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
Recommended