The automatic verification of concurrent systems by model-checking is limited due to the inability to generalise results to systems consisting of any number of processes. We use abstraction to prove general results, by model-checking, about feature interaction analysis of a telecommunications service involving any number of processes. The key idea is to model-check a system of constant number (m) of concurrent processes, in parallel with an "abstract" process which represents the product of any number of other processes. The system, for any specified set of selected features, is generated automatically using Perl scripts

Calder, M.

Miller, A.

English

Enlighten: Publications

 
 
 
 
 
 
Calder, M. and Miller, A. (2002) Automatic verification of any number of 
concurrent, communicating processes. In, 17th IEEE International 
Conference on Automated Software Engineering, 23-27 September, pages 
pp. 227-230, Edinburgh.
 
 
 
http://eprints.gla.ac.uk/2885/ 
 
 
 
 
Glasgow ePrints Service 
http://eprints.gla.ac.uk 
Automatic verification of any number of concurrent, communicating processes
Muffy Calder and Alice Miller
Department of Computing Science
University of Glasgow
Glasgow, Scotland.
E-mail: muffy,alice@dcs.gla.ac.uk
Abstract
The automatic verification of concurrent systems by
model-checking is limited due to the inability to generalise
results to systems consisting of any number of processes. We
use abstraction to prove general results, by model-checking,
about feature interaction analysis of a telecommunication-
s service involving any number of processes. The key idea
is to model-check a system of constant number (m) of con-
current processes, in parallel with an “abstract” process
which represents the product of any number of other pro-
cesses. The system, for any specified set of selected features,
is generated automatically using Perl scripts.
1 Introduction
The automatic verification of concurrent systems by
model-checking has traditionally been limited due to the
inability to generalise results to systems consisting of any
number of processes. For example, we may be able to show
that a property holds for 4 processes, i.e. for p
0
jjp
1
jjp
2
jjp
3
,
but how can we deduce that (if at all) the property holds
for p
0
jjp
1
jjp
2
jjp
3
jj : : : jjp
n 1
, for an arbitrary n? It is not
possible to demonstrate this with straight-forward model-
checking [1].
Our application domain is feature interaction analysis
[2]. Analysis involves examining a system of basic service
processes, running concurrently, some with additional fea-
tures, to determine whether or not certain properties hold.
An interaction may be indicated when a property holds in
the presence of one feature alone (i.e. all but one process
offers only the basic service) but is violated in the presence
of more than one feature. It is important to know when anal-
ysis results do (and do not) scale up.
For example, for a system of four concurrent ser-
vice processes, with different combinations of pairs of
features, the goal of the analysis is to prove (or dis-
prove) that M(p
0
jjp
1
jjp
2
jjp
3
) j= [0; 1; : : : ; t] where
M(p
0
jjp
1
jjp
2
jjp
3
) is the finite-state model of the parallel
composition of processes p
0
; p
1
; p
2
; p
3
(instances of a pa-
rameterised process p) and [0; 1; : : : ; t] is a temporal log-
ic formula containing free variables indexed by 0; 1; : : : ; t,
where 0  t  2. The p
i
communicate peer to peer, asyn-
chronously. In general, the p
i
are not isomorphic (because
they have different sets of features enabled).
We have demonstrated a number of such results [3] for
a basic telecommunications service with features modelled
in Promela. The properties are specified in linear tempo-
ral logic (LTL) and verified using the SPIN model checker
[6]. The [0; 1; : : : ; t] express properties about feature be-
haviour (e.g. if process 1 has call forwarding to process 2
and process 0 initiates a call to process 1, then eventually a
call from process 0 to process 2 will be attempted). In some
cases it is necessary to consider more than 4 processes (up
to 6) to fully capture all possible combinations.
The problem is how to generalise such results to any
number of concurrent, communicating processes, i.e. to
demonstrate that the property  holds regardless of the
number of processes involved (providing this number is suf-
ficiently large). In this paper, we offer a solution based on
abstraction.
We give a technique to prove that, for a fixed m and 0 
t  m 1, for any n, if p
m
; p
m+1
; : : : ; p
n 1
are isomorphic
(they have no features enabled), then
M(p
0
jjp
1
jjp
2
jjp
3
: : : jjp
n 1
) j= [0; 1; : : : ; t]:
The technique involves representing the behaviour of
p
m
jj : : : jjp
n 1
by an abstract process, Abs. A model of the
m concrete processes p
0
; p
1
; : : : ; p
m 1
together with the
abstract process is generated automatically from a model of
the concrete processes together with a single basic call pro-
cess p. For example if m = 3, a model of p
0
jj : : : jjp
2
jjAbs
is generated from a model of p
0
jj : : : jjp
2
jjp. In this case,
for any 0  t  2 we show, by model-checking, that
M(p
0
jjp
1
jjp
2
jjAbs) j= [0; : : : ; t] and can hence infer that
8n:M(p
0
jjp
1
jjp
2
jjp
3
: : : jjp
n 1
) j= [0; : : : ; t].
Proceedings of the 17 th IEEE International Conference on Automated Software Engineering (ASE’02) 
1527-1366/02 $17.00 © 2002 IEEE 
concrete
processes
abstract
process
Abs
p0 p1 p2
n−1p. . .p3
Figure 1. Representing n processes
The technique is summarised by Figure 1. The concrete
processes are p
0
; p
1
; p
2
. Communication between concrete
processes is via channels (denoted by rectangles) and is un-
changed. Note that the contents of a communications chan-
nel fundamentally determines process behaviour. The ob-
servable behaviour of processes p
3
: : : p
n 1
is represented
by Abs in the following way. Communication to/from a
concrete process from/to any other process takes place vi-
a a virtual channel. Rather than concrete processes read-
ing/writing to this (virtual) channel and behaving accord-
ingly, each possible read is replaced by a non-deterministic
choice over the possible contents of such a channel. In this
way all possible behaviours are explored. (A write to such
a channel is no longer relevant.)
The number of concrete processes that are required de-
pends on the number of distinct variables that occur in the
feature descriptions and the property to be verified. We have
shown [4] that if two features are enabled in total, then for
our specific set of properties at most 5 concrete processes
are required (that is, m  5).
The generation of the initial model on m + 1 processes
(for any specified set of selected features) is automatically
generated from a template, using Perl scripts. Similarly, the
conversion from an m + 1 process model to an m process
plus abstract model is performed automatically.
2 Basic call service and features
2.1 Basic call
The basic call service permits call set-up and tear-down
between two parties. Call control is asymmetric: one party
has originating behaviour, and controls the call, the other
has terminating behaviour. Our model follows the IN (In-
telligent Networks) model, distributed functional plane.
Figure 2 gives a diagrammatic representation of an ab-
stract automaton for the basic call service behaviour (the
c?<p,1>tconnect
on
off
tclose
tpickup
p!!c,1
c!!p,1
talert
p?<c,0>
idle dial
c!c,0
c?p,0
c?p,0
preidle
c?<x,y>
off on
oconnect
oalert
p!c,0
c!!p,0
calling
dial
c?<p,0>
off
on
c?x,y
p!!c,0
Figure 2. Basic call service behaviour
Figure 3. Interpretation of channel states
channel A interpretation
empty A is free
(A,0) A is engaged, but not connected
(B,0) B is terminating party, attempting connection
(B,1) if A contains (A,1) then A and B are connected
full implementation is somewhat more complicated). States
to the left of the idle state represent terminating behaviour,
states to the right represent originating behaviour. Transi-
tions between states are triggered by user-initiated events at
the terminal device, such as (handset) on and (handset) of-
f, or by communication events on shared channels. Trivial
behaviour is omitted.
Originating and terminating automata influence each
other’s behaviour through communication via (shared)
channels. In Figure 2 the channels are referred to as c,
for the channel associated with that process, and p, for the
channel associated with the partner process. p is chosen
non-deterministically. We use the notation c!x; y to denote
write the value (x; y) to the channel c, c!!x; y to denote over-
write the channel c with (x; y), c? < x; y > to denote poll
or non-destructively read value (x; y) from channel c, and
c?x; y to denote destructively read value (x; y) from chan-
nel c. When the value may be arbitrary, we use variables x
and y; otherwise we use the actual constants required, e.g.
0,1, p, etc. Channels may contain channels.
Each channel has capacity for at most one message: a
pair consisting of a channel name (the other party in the
call) and a status bit (the status of the connection). The
interpretation of messages is given in Table 3.
2.2 Features
Since the purpose of this paper is not to describe the fea-
tures but to to illustrate the abstraction process, we therefore
refer only to the CFU feature – call forward unconditional.
For illustration, we provide the LTL formula for C-
FU but not the detailed description of the (parameterised)
Promela process User, its variables and associated proposi-
Proceedings of the 17 th IEEE International Conference on Automated Software Engineering (ASE’02) 
1527-1366/02 $17.00 © 2002 IEEE 
tions. att(i; k) denotes the proposition “a call is attempted
from User[i] to User[j]” which is itself defined in terms of
the global variables associated with the User process (see
[3]).
Property 1 – CFU Assume that User[j] has CFU User[k].
If User[i] rings User[j] then a connection between i and k
will be attempted before User[i] has handset on.
LTL: [](p! (rUq))
p = ((dialed[i] == j)&&(User[i]@calling)),
r = att(i; k), q = (dev[i] == on).
3 Feature validation and interaction analysis
The basic idea of feature interaction analysis is detecting
when features behave as expected in isolation, but not in the
presence of each other. Analysis involves feature validation
(checking a feature in isolation) and then checking feature
tuples for violation of expected behaviour.
3.1 Analysis of any number of call processes
For a given number of features present, and the property
to be verified, there is a fixed number of processes m for
which proof of the property is sufficient to prove the prop-
erty for any number of processes. For example, suppose
we wish to prove the (CFU) property above with i = 0,
j = 1, k = 2 for the model representing the behaviour of
User[0]jjUser[1]jj : : : jjUser[n   1] when User[1] has C-
FU to User[2] and the other users are basic call processes,
for any n. Proof of the property for n = 4 seems to be suf-
ficient (the three processes involved in the feature and the
property, plus an external process). But why and when is
it is sound to make such a conclusion? Clearly, any exter-
nal process (that is, any process not involved in the feature
or the property) can only affect the behaviour of any of the
processes involved in the feature or property via commu-
nication to or from such a process. Therefore, as long as
all possibilities of such communication is considered, the
(internal) behaviour of the external processes does not af-
fect the truth (or otherwise) of the property. The following
theorem (stated here without proof) clarifies this reasoning.
Generalisation Theorem Suppose that N
n
=
N
n
(p
0
; p
1
; : : : ; p
n 1
) is a network of n processes
such that, for m  i  n   1, p
i
has no features enabled.
If M(N
m
jjAbs) j= [0; 1; : : : ; t] where M(N
m
jjAbs)
is the finite-state model representing N
m
acting concur-
rently with the abstract process Abs (described earlier),
[0; 1; : : : ; t] is a temporal logic formula containing free
variables indexed by 0; 1; : : : ; t, where 0  t  m   1,
then M(N
n
) j= [0; 1; : : : ; t].
The consequences of the theorem are the technique out-
lined in Figure 1 where we represent the behaviour of
Table 1.
3-user Depth States Mem Time State-vector
0.09 0.07 0.3 2.8 96
4-user Depth States Mem Time State-vector
7.0 4.2 16.1 80 116
N-user Depth States Mem Time State-vector
2.0 0.8 3.2 17.5 116
p
m
jj : : : jjp
n 1
by Abs. A model of the m concrete pro-
cesses p
0
; p
1
; : : : ; p
m 1
together with the abstract process
Abs is generated automatically from a model of the con-
crete processes together with a single basic call process
p. For example if m = 3, a model of p
0
jjp
1
jjp
2
jjAbs
is generated from a model of p
0
jjp
1
jjp
2
jjp. In this case,
for any 0  t  2 we show, by model-checking, that
M(p
0
jjp
1
jjp
2
jjAbs) j= [0; : : : ; t] and can hence infer that
8n:M(p
0
jjp
1
jjp
2
jjp
3
: : : jjp
n 1
) j= [0; : : : ; t].
We refer to the m process model plus abstract process
model as the N -users model. Due to lack of space we do
not give details here of how it is generated, but the full Perl
script to convert any (m+ 1)-users model (with m = 3) to
an N -users model is given in [4].
4 Results
4.1 Validation of single features
We have validated each feature for the N -users model.
For the benefit of readers with a knowledge of SPIN, in Ta-
ble 1, we provide results for the CFU property for the 3-user
model, the 4-user model and the N -user model respectively.
For all verification runs we used a Sun Ultra 80 worksta-
tion with four 450MHz UltraSPARC-II CPUs and 2GB of
main memory running the Solaris 7 operating system. No-
tice how the values of Depth (106), (stored) States (105),
Mem (Mbytes, with compression), Time (user + system, in
seconds) and State-vector (bytes) for the N -user model lie
in-between those values corresponding to the 3-user model
and 4- user model respectively. 1
4.2 Pairwise analysis of features
Once, for a given pair of features and a given property,
the number of concrete users required has been established,
it is straightforward to perform pairwise analysis. We give
here a simple example where the number of concrete users
required is 3 and User[1] has CFU to User[2] and User[2]
has CFU to User[0].
1Note that the Depth parameter indicates the number of steps (including
individual steps within atomic statements) involved in the longest path,
which is more than the number of states encountered on such a path.
Proceedings of the 17 th IEEE International Conference on Automated Software Engineering (ASE’02) 
1527-1366/02 $17.00 © 2002 IEEE 
There is an interaction. The scenario offered as a
counter-example (by SPIN) is when an attempted call from
User[0] is forwarded to User[0], not to User[2].The same
scenario is offered during verification of the corresponding
4-user model. Even with two features, the number of con-
crete users required may be greater than 3. For example,
consider the same property when the second feature above
is replaced by User[3] has CFU to User[4]. This would
require 5 concrete user processes.
5 Discussion
The results above clearly demonstrate the feasibility of
the abstraction technique for this application domain – the
model checking requirements are well within the capability
of our machine. The transformation to a N -user model is
relatively straightforward: we need only consider the com-
munication between the external processes and the concrete
processes. On the other hand, an induction approach [5, 8]
requires the construction of an inductive invariant. This is
a non-trivial exercise as it involves incorporating the be-
haviour of the entire system within the invariant.
The abstraction approach is sound because the result-
ing abstraction is conservative. While the approach is po-
tentially unconservative, because the resulting system of-
fers all possible communication between concrete and ab-
stract processes, the communications protocol is strong e-
nough to prevent any incorrect communication from taking
place. Overall soundness is assured because processes on-
ly communicate via specified shared variables and interpro-
cess communication is mediated by a strong protocol. For-
malisation of this argument to a general setting is further
work.
While methods based on a combination of abstraction
and model-checking [7, 9] have been applied in other do-
mains, we are unaware of any previous generalisation re-
sults in the feature interaction domain.
6 Conclusions
The automatic verification of concurrent systems by
model-checking has traditionally been limited due to the
inability to generalise results to systems consisting of any
number of processes. This may be a serious limitation be-
cause it is often important to show that results do, or do not,
scale up.
We show a technique that can be used to prove general
results about an arbitrary number of processes. The tech-
nique does not involve explicit induction, and consequent-
ly is rather simpler to apply. The key idea is to consider
a system of constant number (m) of concurrent processes,
in parallel with one abstract process which represents the
product of any number of other processes.
We have applied the technique to feature interaction
analysis of a telecommunications service. The general sys-
tem, for any specified set of selected features, is generated
automatically using Perl scripts. Empirical results demon-
strate feasibility of the approach and that interaction results
scale up.
Acknowledgments
The authors would like to thank Ken McMillan for valu-
able discussions relating to this work.
References
[1] Krzysztof R. Apt and Dexter C. Kozen. Limits for au-
tomatic verification of finite-state concurrent systems.
Information Processing Letters, 22:307–309, 1986.
[2] M. Calder and E. Magill, eds. Feature Interaction-
s in Telecommunications and Software Systems, vol-
ume VI. IOS Press, Amsterdam, 2000.
[3] M. Calder and A. Miller. Using SPIN for feature inter-
action analysis - a case study. In Proceedings of SPIN
2001, LNCS, vol. 2057, Springer-Verlag. pp. 143–162,
2001.
[4] M. Calder and A. Miller. Feature validation for any
number of processes. TR2002-110, Dept. of Comput-
ing Science,University of Glasgow, 2002.
[5] E.M. Clarke, O. Grumberg, and S. Jha. Verifying
parameterized networks using abstraction and regular
languages. In Proceedings of CONCUR ‘95, LNCS,
vol. 962, Springer-Verlag. pp. 395–407, 1995.
[6] Gerard J. Holzmann. The model checker Spin. IEEE
Transactions on Software Engineering, 23(5):279–
295, May 1997.
[7] C. Norris Ip and David L. Dill. Verifying systems with
replicated components in mur. Formal Methods in
System Design, 14:273–310, 1999.
[8] R. P. Kurshan and K.L. McMillan. A structural in-
duction theorem for processes. In Proceedings of 8th
ACM Symposium on Principles of Distributed Com-
puting, pages 239–247. ACM Press, 1989.
[9] K. L. McMillan. Parameterized verification of the
flash cache coherence protocol by compositional mod-
el checking. In Proceedings of CHARME 2001, LNC-
S, vol. 2144, pp. 179–195, 2001.
Proceedings of the 17 th IEEE International Conference on Automated Software Engineering (ASE’02) 
1527-1366/02 $17.00 © 2002 IEEE 


Automatic verification of any number of concurrent, communicating processes

Enlighten

      Calder, M. and Miller, A. (2002) Automatic verification of any number of concurrent, communicating processes. In, 17th IEEE International Conference on Automated Software Engineering, 23-27 September, pages pp. 227-230, Edinburgh.   http://eprints.gla.ac.uk/2885/     Glasgow ePrints Service http://eprints.gla.ac.uk Automatic verification of any number of concurrent, communicating processesMuffy Calder and Alice MillerDepartment of Computing ScienceUniversity of GlasgowGlasgow, Scotland.E-mail: muffy,alice@dcs.gla.ac.ukAbstractThe automatic verification of concurrent systems bymodel-checking is limited due to the inability to generaliseresults to systems consisting of any number of processes. Weuse abstraction to prove general results, by model-checking,about feature interaction analysis of a telecommunication-s service involving any number of processes. The key ideais to model-check a system of constant number (m) of con-current processes, in parallel with an “abstract” processwhich represents the product of any number of other pro-cesses. The system, for any specified set of selected features,is generated automatically using Perl scripts.1 IntroductionThe automatic verification of concurrent systems bymodel-checking has traditionally been limited due to theinability to generalise results to systems consisting of anynumber of processes. For example, we may be able to showthat a property holds for 4 processes, i.e. for p0jjp1jjp2jjp3,but how can we deduce that (if at all) the property holdsfor p0jjp1jjp2jjp3jj : : : jjpn 1, for an arbitrary n? It is notpossible to demonstrate this with straight-forward model-checking [1].Our application domain is feature interaction analysis[2]. Analysis involves examining a system of basic serviceprocesses, running concurrently, some with additional fea-tures, to determine whether or not certain properties hold.An interaction may be indicated when a property holds inthe presence of one feature alone (i.e. all but one processoffers only the basic service) but is violated in the presenceof more than one feature. It is important to know when anal-ysis results do (and do not) scale up.For example, for a system of four concurrent ser-vice processes, with different combinations of pairs offeatures, the goal of the analysis is to prove (or dis-prove) that M(p0jjp1jjp2jjp3) j= [0; 1; : : : ; t] whereM(p0jjp1jjp2jjp3) is the finite-state model of the parallelcomposition of processes p0; p1; p2; p3(instances of a pa-rameterised process p) and [0; 1; : : : ; t] is a temporal log-ic formula containing free variables indexed by 0; 1; : : : ; t,where 0  t  2. The picommunicate peer to peer, asyn-chronously. In general, the piare not isomorphic (becausethey have different sets of features enabled).We have demonstrated a number of such results [3] fora basic telecommunications service with features modelledin Promela. The properties are specified in linear tempo-ral logic (LTL) and verified using the SPIN model checker[6]. The [0; 1; : : : ; t] express properties about feature be-haviour (e.g. if process 1 has call forwarding to process 2and process 0 initiates a call to process 1, then eventually acall from process 0 to process 2 will be attempted). In somecases it is necessary to consider more than 4 processes (upto 6) to fully capture all possible combinations.The problem is how to generalise such results to anynumber of concurrent, communicating processes, i.e. todemonstrate that the property  holds regardless of thenumber of processes involved (providing this number is suf-ficiently large). In this paper, we offer a solution based onabstraction.We give a technique to prove that, for a fixed m and 0 t  m 1, for any n, if pm; pm+1; : : : ; pn 1are isomorphic(they have no features enabled), thenM(p0jjp1jjp2jjp3: : : jjpn 1) j= [0; 1; : : : ; t]:The technique involves representing the behaviour ofpmjj : : : jjpn 1by an abstract process, Abs. A model of them concrete processes p0; p1; : : : ; pm 1together with theabstract process is generated automatically from a model ofthe concrete processes together with a single basic call pro-cess p. For example if m = 3, a model of p0jj : : : jjp2jjAbsis generated from a model of p0jj : : : jjp2jjp. In this case,for any 0  t  2 we show, by model-checking, thatM(p0jjp1jjp2jjAbs) j= [0; : : : ; t] and can hence infer that8n:M(p0jjp1jjp2jjp3: : : jjpn 1) j= [0; : : : ; t].Proceedings of the 17 th IEEE International Conference on Automated Software Engineering (ASE’02) 1527-1366/02 $17.00 © 2002 IEEE concreteprocessesabstractprocessAbsp0 p1 p2n−1p. . .p3Figure 1. Representing n processesThe technique is summarised by Figure 1. The concreteprocesses are p0; p1; p2. Communication between concreteprocesses is via channels (denoted by rectangles) and is un-changed. Note that the contents of a communications chan-nel fundamentally determines process behaviour. The ob-servable behaviour of processes p3: : : pn 1is representedby Abs in the following way. Communication to/from aconcrete process from/to any other process takes place vi-a a virtual channel. Rather than concrete processes read-ing/writing to this (virtual) channel and behaving accord-ingly, each possible read is replaced by a non-deterministicchoice over the possible contents of such a channel. In thisway all possible behaviours are explored. (A write to sucha channel is no longer relevant.)The number of concrete processes that are required de-pends on the number of distinct variables that occur in thefeature descriptions and the property to be verified. We haveshown [4] that if two features are enabled in total, then forour specific set of properties at most 5 concrete processesare required (that is, m  5).The generation of the initial model on m + 1 processes(for any specified set of selected features) is automaticallygenerated from a template, using Perl scripts. Similarly, theconversion from an m + 1 process model to an m processplus abstract model is performed automatically.2 Basic call service and features2.1 Basic callThe basic call service permits call set-up and tear-downbetween two parties. Call control is asymmetric: one partyhas originating behaviour, and controls the call, the otherhas terminating behaviour. Our model follows the IN (In-telligent Networks) model, distributed functional plane.Figure 2 gives a diagrammatic representation of an ab-stract automaton for the basic call service behaviour (thec?<p,1>tconnectonofftclosetpickupp!!c,1c!!p,1talertp?<c,0>idle dialc!c,0c?p,0c?p,0preidlec?<x,y>off onoconnectoalertp!c,0c!!p,0callingdialc?<p,0>offonc?x,yp!!c,0Figure 2. Basic call service behaviourFigure 3. Interpretation of channel stateschannel A interpretationempty A is free(A,0) A is engaged, but not connected(B,0) B is terminating party, attempting connection(B,1) if A contains (A,1) then A and B are connectedfull implementation is somewhat more complicated). Statesto the left of the idle state represent terminating behaviour,states to the right represent originating behaviour. Transi-tions between states are triggered by user-initiated events atthe terminal device, such as (handset) on and (handset) of-f, or by communication events on shared channels. Trivialbehaviour is omitted.Originating and terminating automata influence eachother’s behaviour through communication via (shared)channels. In Figure 2 the channels are referred to as c,for the channel associated with that process, and p, for thechannel associated with the partner process. p is chosennon-deterministically. We use the notation c!x; y to denotewrite the value (x; y) to the channel c, c!!x; y to denote over-write the channel c with (x; y), c? < x; y > to denote pollor non-destructively read value (x; y) from channel c, andc?x; y to denote destructively read value (x; y) from chan-nel c. When the value may be arbitrary, we use variables xand y; otherwise we use the actual constants required, e.g.0,1, p, etc. Channels may contain channels.Each channel has capacity for at most one message: apair consisting of a channel name (the other party in thecall) and a status bit (the status of the connection). Theinterpretation of messages is given in Table 3.2.2 FeaturesSince the purpose of this paper is not to describe the fea-tures but to to illustrate the abstraction process, we thereforerefer only to the CFU feature – call forward unconditional.For illustration, we provide the LTL formula for C-FU but not the detailed description of the (parameterised)Promela process User, its variables and associated proposi-Proceedings of the 17 th IEEE International Conference on Automated Software Engineering (ASE’02) 1527-1366/02 $17.00 © 2002 IEEE tions. att(i; k) denotes the proposition “a call is attemptedfrom User[i] to User[j]” which is itself defined in terms ofthe global variables associated with the User process (see[3]).Property 1 – CFU Assume that User[j] has CFU User[k].If User[i] rings User[j] then a connection between i and kwill be attempted before User[i] has handset on.LTL: [](p! (rUq))p = ((dialed[i] == j)&&(User[i]@calling)),r = att(i; k), q = (dev[i] == on).3 Feature validation and interaction analysisThe basic idea of feature interaction analysis is detectingwhen features behave as expected in isolation, but not in thepresence of each other. Analysis involves feature validation(checking a feature in isolation) and then checking featuretuples for violation of expected behaviour.3.1 Analysis of any number of call processesFor a given number of features present, and the propertyto be verified, there is a fixed number of processes m forwhich proof of the property is sufficient to prove the prop-erty for any number of processes. For example, supposewe wish to prove the (CFU) property above with i = 0,j = 1, k = 2 for the model representing the behaviour ofUser[0]jjUser[1]jj : : : jjUser[n   1] when User[1] has C-FU to User[2] and the other users are basic call processes,for any n. Proof of the property for n = 4 seems to be suf-ficient (the three processes involved in the feature and theproperty, plus an external process). But why and when isit is sound to make such a conclusion? Clearly, any exter-nal process (that is, any process not involved in the featureor the property) can only affect the behaviour of any of theprocesses involved in the feature or property via commu-nication to or from such a process. Therefore, as long asall possibilities of such communication is considered, the(internal) behaviour of the external processes does not af-fect the truth (or otherwise) of the property. The followingtheorem (stated here without proof) clarifies this reasoning.Generalisation Theorem Suppose that Nn=Nn(p0; p1; : : : ; pn 1) is a network of n processessuch that, for m  i  n   1, pihas no features enabled.If M(NmjjAbs) j= [0; 1; : : : ; t] where M(NmjjAbs)is the finite-state model representing Nmacting concur-rently with the abstract process Abs (described earlier),[0; 1; : : : ; t] is a temporal logic formula containing freevariables indexed by 0; 1; : : : ; t, where 0  t  m   1,then M(Nn) j= [0; 1; : : : ; t].The consequences of the theorem are the technique out-lined in Figure 1 where we represent the behaviour ofTable 1.3-user Depth States Mem Time State-vector0.09 0.07 0.3 2.8 964-user Depth States Mem Time State-vector7.0 4.2 16.1 80 116N-user Depth States Mem Time State-vector2.0 0.8 3.2 17.5 116pmjj : : : jjpn 1by Abs. A model of the m concrete pro-cesses p0; p1; : : : ; pm 1together with the abstract processAbs is generated automatically from a model of the con-crete processes together with a single basic call processp. For example if m = 3, a model of p0jjp1jjp2jjAbsis generated from a model of p0jjp1jjp2jjp. In this case,for any 0  t  2 we show, by model-checking, thatM(p0jjp1jjp2jjAbs) j= [0; : : : ; t] and can hence infer that8n:M(p0jjp1jjp2jjp3: : : jjpn 1) j= [0; : : : ; t].We refer to the m process model plus abstract processmodel as the N -users model. Due to lack of space we donot give details here of how it is generated, but the full Perlscript to convert any (m+ 1)-users model (with m = 3) toan N -users model is given in [4].4 Results4.1 Validation of single featuresWe have validated each feature for the N -users model.For the benefit of readers with a knowledge of SPIN, in Ta-ble 1, we provide results for the CFU property for the 3-usermodel, the 4-user model and the N -user model respectively.For all verification runs we used a Sun Ultra 80 worksta-tion with four 450MHz UltraSPARC-II CPUs and 2GB ofmain memory running the Solaris 7 operating system. No-tice how the values of Depth (106), (stored) States (105),Mem (Mbytes, with compression), Time (user + system, inseconds) and State-vector (bytes) for the N -user model liein-between those values corresponding to the 3-user modeland 4- user model respectively. 14.2 Pairwise analysis of featuresOnce, for a given pair of features and a given property,the number of concrete users required has been established,it is straightforward to perform pairwise analysis. We givehere a simple example where the number of concrete usersrequired is 3 and User[1] has CFU to User[2] and User[2]has CFU to User[0].1Note that the Depth parameter indicates the number of steps (includingindividual steps within atomic statements) involved in the longest path,which is more than the number of states encountered on such a path.Proceedings of the 17 th IEEE International Conference on Automated Software Engineering (ASE’02) 1527-1366/02 $17.00 © 2002 IEEE There is an interaction. The scenario offered as acounter-example (by SPIN) is when an attempted call fromUser[0] is forwarded to User[0], not to User[2].The samescenario is offered during verification of the corresponding4-user model. Even with two features, the number of con-crete users required may be greater than 3. For example,consider the same property when the second feature aboveis replaced by User[3] has CFU to User[4]. This wouldrequire 5 concrete user processes.5 DiscussionThe results above clearly demonstrate the feasibility ofthe abstraction technique for this application domain – themodel checking requirements are well within the capabilityof our machine. The transformation to a N -user model isrelatively straightforward: we need only consider the com-munication between the external processes and the concreteprocesses. On the other hand, an induction approach [5, 8]requires the construction of an inductive invariant. This isa non-trivial exercise as it involves incorporating the be-haviour of the entire system within the invariant.The abstraction approach is sound because the result-ing abstraction is conservative. While the approach is po-tentially unconservative, because the resulting system of-fers all possible communication between concrete and ab-stract processes, the communications protocol is strong e-nough to prevent any incorrect communication from takingplace. Overall soundness is assured because processes on-ly communicate via specified shared variables and interpro-cess communication is mediated by a strong protocol. For-malisation of this argument to a general setting is furtherwork.While methods based on a combination of abstractionand model-checking [7, 9] have been applied in other do-mains, we are unaware of any previous generalisation re-sults in the feature interaction domain.6 ConclusionsThe automatic verification of concurrent systems bymodel-checking has traditionally been limited due to theinability to generalise results to systems consisting of anynumber of processes. This may be a serious limitation be-cause it is often important to show that results do, or do not,scale up.We show a technique that can be used to prove generalresults about an arbitrary number of processes. The tech-nique does not involve explicit induction, and consequent-ly is rather simpler to apply. The key idea is to considera system of constant number (m) of concurrent processes,in parallel with one abstract process which represents theproduct of any number of other processes.We have applied the technique to feature interactionanalysis of a telecommunications service. The general sys-tem, for any specified set of selected features, is generatedautomatically using Perl scripts. Empirical results demon-strate feasibility of the approach and that interaction resultsscale up.AcknowledgmentsThe authors would like to thank Ken McMillan for valu-able discussions relating to this work.References[1] Krzysztof R. Apt and Dexter C. Kozen. Limits for au-tomatic verification of finite-state concurrent systems.Information Processing Letters, 22:307–309, 1986.[2] M. Calder and E. Magill, eds. Feature Interaction-s in Telecommunications and Software Systems, vol-ume VI. IOS Press, Amsterdam, 2000.[3] M. Calder and A. Miller. Using SPIN for feature inter-action analysis - a case study. In Proceedings of SPIN2001, LNCS, vol. 2057, Springer-Verlag. pp. 143–162,2001.[4] M. Calder and A. Miller. Feature validation for anynumber of processes. TR2002-110, Dept. of Comput-ing Science,University of Glasgow, 2002.[5] E.M. Clarke, O. Grumberg, and S. Jha. Verifyingparameterized networks using abstraction and regularlanguages. In Proceedings of CONCUR ‘95, LNCS,vol. 962, Springer-Verlag. pp. 395–407, 1995.[6] Gerard J. Holzmann. The model checker Spin. IEEETransactions on Software Engineering, 23(5):279–295, May 1997.[7] C. Norris Ip and David L. Dill. Verifying systems withreplicated components in mur. Formal Methods inSystem Design, 14:273–310, 1999.[8] R. P. Kurshan and K.L. McMillan. A structural in-duction theorem for processes. In Proceedings of 8thACM Symposium on Principles of Distributed Com-puting, pages 239–247. ACM Press, 1989.[9] K. L. McMillan. Parameterized verification of theflash cache coherence protocol by compositional mod-el checking. In Proceedings of CHARME 2001, LNC-S, vol. 2144, pp. 179–195, 2001.Proceedings of the 17 th IEEE International Conference on Automated Software Engineering (ASE’02) 1527-1366/02 $17.00 © 2002 IEEE 

model-checking is limited due to the inability to generalise results to systems consisting of any number of processes. We use abstraction to prove general results, by model-checking, about feature interaction analysis of a telecommunications service involving any number of processes. The key idea is to model-check a system of constant number (m) of concurrent processes, in parallel with an &quot;abstract&quot; process which represents the product of any number of other processes. The system, for any specified set of selected features, is generated automatically using Perl scripts

Muffy Calder

Alice Miller

CiteSeerX

Automatic Verification of Any Number of Concurrent, Communicating Processes

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.57.6983

Automatic verification of any number of concurrent, communicating processes

Abstract

Similar works

Full text

Available Versions

Enlighten: Publications

Enlighten

CiteSeerX