Reachability analysis

Thanks to Dr. Junzhao Sun

University of Oulu
 Correctness Properties of Communicating
Distributed Systems
• Communication software design errors:
– Semantic error which causes the provision of incorrect service to the
system users that affect the safety of the system.
– Syntactic errors which ultimately causes the system to deadlock, and
therefore affects the liveness propriety of the system

1. Freedom from deadlocks

2. Freedom from unspecified
3. Liveness
4. Boundedness
5. Freedom from dynamical blockage
6. Completeness
7. Self-synchronization
 Some definitions
➢ Safety properties specify that “something bad never happens”
➢ Doing nothing easily fulfills a safety property
– as this will never lead to a “bad” situation
➔Safety properties are complemented by liveness properties
– that require some progress

➢ Liveness properties assert that:

– ”something good” will happen eventually
[Lamport 1977]
 Protocol Design Errors - Deadlock
Deadlock
– Both machines are at receiving states and channels are empty. The network
can not progress further
– Receiving state is a state where all its outgoing transition are all receiving
transition. It can not move without msg in its incoming channel

C1
1 1
S
FIFO…..
Channels -R -A +R
… +A
are empty

C2
Sender Receiver
Discriminates against Livelock
– A system is in the livelock (dynamic deadlock) if the processes are
exchanging messages that are not useful for providing the service and so
not making "effective progress".
 Protocol Design Errors - Unspecified
Reception
Unspecified reception
There exist a message in the queue, there exist a reception transition but
the message in the queue is different from the message expected by the
reception transition. The network can not progress further.
E.g. there is msg B in C2 but sender does not have a receiving transition
with msg B.

“-” means send; “+” means receive

b1
C1
1 1
S b2
… ….. +A -R +R -B
br B
C2
Sender Receiver
{a1, …, at}∩{b1, …, br} = Ø
Non-executable States and Transitions
E.g. State 3 of Receiver will never be executed or become the current state. It
is called non-executable state.

Transitions (2,3,+B) and (3,1 ,-C) will never be executed. They are called non-
executable transitions.

C1
1 1 -C

+A -R -A +R
3
C2 +B
Sender Receiver
 Other Protocol Design Errors
• Other System Design Errors
– Instability or state ambiguity
• If an initial state of one protocol entity may coexist with different
states of other cooperating entities (with empty channels)
• The result of such an error is the potential loss of synchronization
between the cooperating entities
• Unboundedness or overflow
– If a protocol state can be reached such that the channel
linking any pair of communicating protocol entities
contains a number of messages exceeding the predefined
capacity for that channel
Protocol Verification: Global State In CFSMs
• A global state of a system, is a pair of <S,C>, where
– S=(s1,s2,...sn), si- current states of processes Pi,
– C=(cij, for all I#j, and i,fin) - current contents of the channels cij linking the
processes Pi and Pj
– A global state is a snapshot of the overall system state
• The initial (final) global state composition is a pair <S,C> in which
– Each s/of S is the initial (final) states in its respective processes Pi
– All channels are empty, i.e. cij= 0
• The next global state is obtained as: <S,C>=xS',C>, if there exit a transition
that can be executed. Two cases are possible:
1. There exist a transition for a process where the message x can be sent,
2. There exist a reception transition of a message x for a process and a message x
is in the input queue of a process
 System Verification Using Reachability
Analysis
• Reachability Analysis is a global state exploration process that
– Starts from the initial global state, and
– recursively explores all possible transitions that lead to new global
states
– The result is a reachability graph, which captures all possible
states
• A global state <S,C> is said to be reachable from the initial
global state <So,Co>, denoted <So,Co> =>*<S,C>, IFF:
– There exists an execution path consisting of the interleaving of
message receptions and transmissions that takes the system of
communicating processes from the the initial global state <S0,C0> to
<S,C>
 Reachability Graph (Tree)
• Reachability Graph (Tree)
– Nodes represents regular global states
– Directed arc, connecting two nodes or states <S1,C1> and <S2,C2>,
corresponds to a transition in one of the communicating processes
– Roof of the Tree corresponds to the initial state <S0,C0>
– A path in the Tree corresponds to an execution sequence of the interleaved
receptions and transmissions, and it represents the reachability of the last
state in the path from the initial state of the path
• The expansion of the tree from a particular node stops if one of the
following conditions is satisfied:
• 1. the node already exist in the tree
• 2. the node correspond to a deadlock state
• 3. an unspecified reception error is detected at the node
• 4. the node corresponds to a final state
 Reachability Analysis Process
• Starting from initial global state, where channels are empty
and machines at their initial states
• Explore all possible reachable state by firing all the possible
transitions (and generating global states) from any given
reachable state
• All deadlock and unspecified reception errors will be captured
and marked as individual global state
• By examining the number of messages in the channels we can
design the buffer size for the protocol
• Can detect non-executable states and transitions by marking
those states that are touched and transitions that are fired
during the reachability analysis
 Reachability Analysis Example
GS0

1 ɛ

1 -B C1
1 ɛ 1

-B -R

+A -R
-A +R GS1 B R
2 2
C2 GS2
ɛ 1 ɛ 1
Sender Receiver
+R
UR
Unspecified
Reception 2 ɛ GS3
ɛ 2
Global State/ Reachable State
-A
Sender Channel C1 from
State Sender to Receiver
2 ɛ GS4
content
A 1

Channel C2 from +A
Receiver to Receiver
Sender content State

Global state ID
Reachability Analysis Example 2
 <M, N, C1,C2> convention
M N
1 1 -c

-a
+c C1
+a <1,1, ɛ, ɛ> GS0
+d
2 2 4 -a/M -d/M
+a
+b C2 -b
-d -b
3 3
GS1 <2,1,a, ɛ> <3,1,d, ɛ> GS2

+a/N +d/N

GS3 <2,2, ɛ, ɛ> <3,4, ɛ, ɛ> GS4

-b/N
-b/N -c/N

GS5 <2,3, ɛ, b> GS6 <3,1, ɛ, c> GS7 <3,3, ɛ, b >

+b/M +c/M
UR
Unspecified
GS8 <3,3, ɛ, ɛ> Reception
GS0 <1,1, ɛ, ɛ >
Process M
Deadlock Visited state
M and N in
receiving states 3,3
and C1 and C2 are empty

Size of channels = maximum number of accumulated messages in a channel

C1=1
C2=1
 Reachability Analysis Example 3
a) Perform the reachability analysis on the Network
(M, N)
b) What sizes of buffers are needed for the two FIFO
channels?
c) Are there non-executable states or transitions?
 Reachability Analysis Example 3 - Solution

M C1
C2 N
Global state

• One unspecified reception (see gs4)

• Both channels need buffer size of 2 (see gs8 and
gs9)
• No non-executable states and transitions
• Since both machines send same types of msgs. We
use "Machine:" to specify which machine fires the
transition
 Reachability Analysis Example 4
• Perform the reachability analysis on the Network (P1, P2)
• Find deadlock, unspecified reception global states in the protocol
• Are there non-executable transitions and nodes in the CFSMs
• How many buffers are required in each of the two channel?
 <P1, P2, C1,C2> convention
C1

<S0,S0, ɛ, ɛ> GS0

C2 -1/P1

<S1,S0, 1, ɛ> GS1

+1/P2

+2/P1
<S1,S1, ɛ, ɛ> GS2

-3/P2
-2/P2

<S1,S2, ɛ, 3> GS4

GS3 <S1,S0, ɛ, 2>
-6/P2 +3/P1
No deadlock, no unspecified reception
Non reachable, Non-executable
GS5 <S1,S0, ɛ,(3,6) > <S1,S2, ɛ, ɛ> GS6
P1
State: S2 -6/P2
Transitions: (S1, S2, +5), (S2, S1,-4) +3/P1

P2 <S1,S0, ɛ, 6> GS7

State: S3 +6/P1
Transitions: (S2, S3, +4), (S3, S1,-5)
<S0,S0, ɛ, ɛ>
Channel Buffers Visited state
C2: 2 C1: 1 GS0
 Reachability Analysis Example 4 - Solution

• No deadlock or
unspecified reception
• Non-executable
– P1:S2, (S1, S2, +5), (S2,
S1.-4)
– P2: S3, (S2, S3, +4), (S3,
S1.-5)
• Buffer
– C21: 2
– C12: 1
 Reachability Analysis Exercises
• Given the following network of two communicating finite
state machines,
– a) Perform the reachability analysis on the Network (M, N).
– b) What sizes of buffers are needed for the two FIFO channels?
– c) Are there non-executable states or transitions?

• What are the channel buffer sizes needed for the following two machines?
Pros and Cons of Reachability Analysis
• Advantages:
– Easily automated
– Many logical errors can be detected by only examining
individual global states in the reachability graph
• Disadvantages:
– State space explosion problem
– Does not work on unbounded protocols
– Many relationships among the protocol state variables,
expressing the desirable logical correctness properties of
the protocol are not apparent from simply traversing the
reachability graph
 Methods Other Than Full State Space
Search
• Full search is simplest but for small class of protocols
• Controlled partial search tries to optimize the quality of analysis
– Depth-bounds, place a bound on the length of the execution sequences
– Scatter searches, executions are selected that lead closer to potential
deadlock states
– Guided searches, a dynamically evaluated cost function as state selection
criterion
– Probabilistic searches, successor states are explored in decreasing order of
their probability of occurrence
– Partial orders, based on the definition of a heuristic for fair or maximum
progress state exploration
• Random simulation is for systems of even complexity
– Explore the state space with a random simulation or "random walk"
 References (1/2)
• C. E. Chow. Introduction to protocol engineering. 2004. cs.uccs.edu/~cs522/pe/ G O.
Chistokhvalov, Communication software and architecture, lecture notes. 2002.
www.it.lut.fi/kurssit/02-03/010607000/index_eng.html
• G.J. Holzmann. Design and validation of computer protocols. Chapter 8-11. Prentice-Hall.
1991. ISBN 0-13-539925-4, spinroot.com/spin/Doc/Book91.html
• A. Petrenko, Introduction to the theory of experiments on finite state machines, lecture
notes. 2003. www.bretagne.ens-
cachan.fr/DIT/People/Claude.Jard/sem_13_05_2003_petrenko_trans.pdf
• Igor Potapov . Protocol engineering, lecture notes. 2004. www.csc.liv.ac.uk/~igor/COMP201/
• Chris Ling. The Petri Net method, lecture notes. 2001.
www.csse.monash.edu.au/courseware/cse5510/Lectures/lecture2b.ppt
• Gabriel Eirea, Petri nets, lecture notes, UC Berkeley, 2002,
www.cs.unc.edu/~montek/teaching/spring-04/petrinets.ppt
• T.-Y. Cheung. Petri nets for protocol engineering. Elsevier Computer Communications. 19.
1996: 1250-1257
• R.Zurawski and M.C. Zhou, Petri Nets and industrial applications: a tutorial, IEEE Trans.
Industrial Electronics, vol. 41, no. 6, 1994: 567-583
 References (2/2)
• T. Murata. Petri nets: properties, analysis and applications. Proceedings of the IEEE. vol. 77.
no. 4, 1989:541-580
• G.V. Bochmann and R. Gotzhein, Deriving protocol specifications from service specifications,
ACM Trans, on Computer Systems, vol. 8, no. 4, 1990: 255-283
• R.L. Probert and K. Saleh, Synthesis of communication protocols: survey and assessment, IEEE
Trans. Computers, vol. 40, no. 4, 1991: 468-476
• Mark Claypool, Modeling and performance evaluation of network and computer systems,
lecture notes, 2004, www.cs.wpi.edu/~claypool/courses/533-S04/
• R. Dssouli and F. Khendek, Test development for distributed system, 2000,
www.ece.concordia.ca/~dssouli/Testing.pdf
• R. Lai. A survey of communication protocol testing. Elsevier Journal of Systems and Software.
62,2002:21-46
• G.V. Bochmann and A. Petrenko. Protocol testing: review of methods and relevance for
software testing, Proc. ACM ISSTA, Seattle Washington, USA, 1994: 109-124
• A.T. Dahbura, K.K. Sabnani, and M.U. Uyar, Formal methods for generating protocol
conformance test sequences. Proceedings of the IEEE, vol. 78, no. 8, 1990: 1317-1326
• D.P. Sidhu and T.-K. Leung, Formal methods for protocol testing: a detailed study, IEEE Trans.
Software Engineering, vol. 15, no. 4, 1989: 413-426