183
Step-Wise Validation of Communication
Protocols and Services
Hasan U R A L and Robert L. P R O B E R T
Department of Computer Science, University of Ottawa, Ottawa,
Ontario, Canada, KIN 9B4
A highly automated approach is proposed for testing the
consistency of distinct representations of identical system func-
tionality. This approach is based on dynamic comparison and
analysis of observable behaviors presented by system function-
ality representations given at different levels of abstraction.
These representations are encoded in a relatively mechanical
way as procedures in sequential PROLOG and thus provide
the capability of generating and checking the system function-
ality they capture. The approach is extremely flexible,
straightforward to use, and particularly appropriate to systems
whose externally observable behavior can be modeled by finite
state automata. The use of this approach is illustrated in the
context of OSI communication protocol design and validation.
Kevwords: Executable Specifications, Design Tools, Valida-
tion. Testing, Simulation.
Robert L. Probert was born in Belle-
ville, Ont., Canada. He received the
B.Sc., M.Sc., and Ph.D. degrees in
computer science from the University
of Waterloo in 1969, 1970, and 1973,
respectively.
He joined the Department of Com-
putational Science at the University of
Saskatchewan in 1973 as an Assistant
Professor, and is now a Professor in
the Department of Computer Science
at the University of Ottawa. His re-
search interests include software test-
ing tools and techniques, protocol specification and testing,
and rule-based software engineering.
Dr. Probert is the Coordinator of the Protocols Research
Group at the University of Ottawa, involving several faculty
and graduate students and is currently directing a subgroup
working on a protocol validation contract for Bell-Northern
Research. He has served as a consultant in the area of proto-
cols and software testing to both industry and government and
on the board of directors of a software development corpora-
tion.
North-Holland
Computer Networks and ISDN Systems 11 (1986) 183-202
0376-5075/86/$3.50 © 1986, Elsevier Science Publishers B.V. (North-Holland)
1. Introduction
Step-wise refinement in a typical software de-
velopment process starts from a formulation of
intentions of the desired system functionality and
converges to an implementation of the system
providing this functionality. This step-wise refine-
ment process produces a series of system function-
ality representations (SFRs) such as intentions,
natural language assertions, formal specifications,
designs, and implementations in decreasing levels
of abstraction. In general, each such representa-
tion describes the system functionality in terms of
externally observable behavior of the system (e:g.,
possible types and orderings of interactions that
the system exchanges with its environment) and is
derived by successively refining the more abstract
repreSentation immediately preceding it. It is
widely acknowledged that many errors can be
introduced into the representations during these
derivations (i.e., transformations from one repre-
sentation to another) and that such errors can
propagate throughout subsequent representations
unless they are detected and corrected.
A major concern (and thus the purpose of
validation) in a software development process is to
ensure that these distinct but highly related SFRs
are in fact consistent. Here, by consistency we
mean equivalence of externally observable behav-
ior. There are basically two approaches to valida-
tion: namely, verification and testing. Verification
is based on formal and logical means (e.g., induc-
tion arguments) and aims to prove desired behav-
ioral equivalence of SFRs. Testing, on the other
Hasan Ural was born in Ankara,
Turkey. He received the Ph.D. degree
in electrical engineering from the Uni-
versity of Ottawa in 1984. He is now
an Assistant Professor in the Depart-
ment of Computer Science at the Uni-
versity of Ottawa. His research inter-
ests include communication software
specification and validation, applica-
tions of logic programming tech-
niques, and distributed processing.
184 H. Ural, R.L. Probert / Communication Protocols and Services
hand, attempts to reveal inconsistencies between
S F R _ K and its abstraction SFR_K-1 by com-
paring the system behavior observed during the
execution of SFR K with the expected system
behavior as described by SFR_K-1. However,
testing cannot guarantee that S F R _ K is "con-
sistent" With SFR_ K-1 unless all possible system
behavior patterns described by these SFRs are
explored and compared against each other. In
general, this corresponds to "exhaustive" testing
which is practically infeasible. Thus, practical test-
ing aims at detecting particular (if not all), highly
likely instances of inconsistencies between SFR_ K
and SFR_K-1.
In this paper, we present a validation approach
which employs testing as a means of detecting
inconsistencies between SFR K and SFR_K-1.
This approach is motivated by consideration of
the need of a practical, easy to use development
aid which aims to increase our confidence in the
refinement process. Usually, in an incremental
development process a refinement of S F R K-1 is
attempted only after SFR K-1 has been vali-
dated. Thus, we will assume that SFR_K-1 is
acceptable as a reference for consistency checking.
In our approach, detection of inconsistencies (if
any) between two SFRs is based on dynamic
analysis of externally observable behavior of these
SFRs at corresponding observation points. That
is, the analysis involves comparing each actual
behavior of SFR_ K observed during its execution
with a corresponding expected (or intended) be-
havior of S F R _ K described in (or implied by)
SFR_ K-1. Two possible ways of comparing actual
against expected behavior for the purpose of de-
tecting inconsistencies can be identified; namely,
checking whether:
a) a representative set of observed behavior of
SFR_ K is permitted by SFR_ K-1
b) a representative set of intended (or expected)
behaviors of SFR_ K (derived from SFR_ K-l)
is realized by (is actually possible in) SFR_K.
Testing the behavioral equivalence of two SFRs
is a useful approach to, for example, in-house
validation of implementation of protocol entities.
In this case, SFR_K-1 is the accepted protocol
specification and S F R _ K is a protocol imple-
mentation. In addition, design of the protocol
specification can be assisted by testing the con-
sistency of two SFRs. In this case, SFR_K-1 is
the accepted service specification and SFR_ K is a
refined service specification constructed from two
copies of the protocol specification and an un-
derlying service specification. Finally, working
groups of both ISO and CCITT are currently
studying issues related to conformance testing of
protocol implementations. These studies should
benefit from our research into testing the behav-
ioral equivalence of abstract and refined SFRs.
The paper is organized as follows: In section 2,
we detail the consistency checking approach by
elaborating the possible ways of comparing actual
against expected behaviors of SFRs, and by de-
scribing its requirements and basic components.
In section 3, we present the application of our
approach to the development and validation of
layered communication protocols.
2. The Approach
2.1. Overview of the Approach
Assume that SFR_K-1 and S F R _ K are avail-
able in sufficiently precise formalisms that all
actual behaviors of each SFR can be obtained
(e.g., by direct execution). The following valida-
tion scenarios can be used for detecting incon-
sistencies between SFR_ K and SFR_ K-l:
1) Obtain a set of actual execution histories of
S F R _ K (i.e., sequences of interactions in which
S F R _ K participates during its execution). Each
execution history is a sequence of input stimuli
and responses recorded during the execution of
SFR_K. We call each such sequence a trace of
SFR_K. Each trace of S F R _ K corresponds to an
instance of actual behavior of S F R _ K which in
turn corresponds to an instance of externally ob-
servable system behavior described by this SFR.
Since SFR_K-1 has already been validated, the
system behavior described by SFR_K-1 can be
considered to be the expected (desired) behavior of
SFR_K. That is, each trace of S F R _ K can be
checked for consistency with the corresponding
expected behavior(s) described by SFR_K-1.
Therefore, apply each trace of SFR K to
SFR_K-1 to check whether it is permitted by
SFR_K-1. This validation activity is called 'trace
checking '.
2) Obtain a set of actual interaction sequences
from SFR K-1. This set contains intended (or
expected) sequences of interactions between
 H. Ural, R.L. Probert / Communication Protocols and Services
SFR K and its environment. We call each such
interaction sequence a trajectory for S F R _ K, i.e.,
an instance of expected behavior (i.e., potential
trace) of S F R _ K . In general, a trajectory for
S F R _ K is a test sequence which is a string of
stimuli (i.e., input interactions to be applied to
SFR_ K) interleaved with expected responses (i.e.,
output interactions of S F R _ K). Then apply each
selected trajectory to S F R _ K to check whether it
is actually allowed by S F R _ K . We call this vali-
dation activity 'trajectory checking'.
In fact, this is a two-way complementary con-
sistency checking approach. The aim in trajectory
checking is to reveal any expected behaviors that
S F R _ K fails to perform or performs incorrectly.
On the other hand, the aim in trace checking is to
reveal any behavior of S F R _ K that was not in-
tended. As well, the actual limits and constraints
that are realized S F R _ K may be revealed during
trace checking. In each of these cases, discrepan-
cies between actual and expected behaviors of
SFRs are reported for subsequent analysis and
reconciliation.
It is important to note that in some cases
S F R _ K - 1 may involve some nondeterminism
which allows certain implementation choices for
S F R _ K. In these cases, there is a need to adapt to
unpredictable choices of S F R _ K in response to a
given stimulus during testing. That is, the response
(if valid) of S F R _ K must be identified as one of
the acceptable expected responses and the subse-
quent stimulus must be determined.
In our approach, the requirement of adapting
to unpredictable responses of S F R _ K is met as
follows: In trace checking, S F R _ K-1 is employed
as a test oracle which determines whether an
observed trace of S F R _ K is permissible or not.
Thus, an inconsistency is detected if and only if
the actual response of S F R _ K in the trace does
not match any of the (expected) responses per-
mitted by S F R _ K - 1 .
As far as trajectory checking is concerned, a
trajectory which includes a single expected re-
sponse for a given stimulus (i.e., a single-valued
trajectory) cannot provide the capability of adapt-
ing to unpredictable responses of S F R _ K . In-
stead, all allowed responses to a stimulus should
be included in a trajectory. This corresponds to a
tree structure which we call a multiple-valued
trajectory.
At this point, we identify the following two
185
cases for the discussion on trajectory checking:
a) S F R _ K includes all non-deterministic compo-
nents and options specified in S F R _ K - 1 .
b) S F R _ K includes some (possibly one) of the
non-deterministic components or options of
SFR_K-1.
Obviously, case b) cannot be handled using
single-valued trajectories since inconsistency re-
vealed using such a trajectory does not guarantee
inconsistency between S F R _ K and S F R _ K - 1 .
On the other hand, case a) can be handled using
single-valued trajectories provided that S F R _ K
can undo the choices it has taken which do not
lead to a particular expected response. In fact, we
build trajectory checkers to direct S F R _ K to
produce the expected response if it is among
S F R _ K's possible choices. Thus, an inconsistency
between the two SFRs is detected if and only if
there is no sequence of actions taken by S F R _ K
which generates the specific expected response.
This is discussed in more detail in section 2.3
Trajectory checking using multiple-valued
trajectories involves checking whether an actual
response of S F R _ K is among the responses
specified at the corresponding points in the trajec-
tory. Thus, an inconsistency is detected if and
only if a response of S F R _ K does not match any
of the allowed expected responses. The mecha-
nisms for representing and applying such trajecto-
ries require further study.
In the following subsections, we describe basic
components of our approach,~namely, construc-
tion of executable SFRs and analysis of system
functionality captured by these SFRs.
2.2. Construction of Executable Representations
A variety of formal description techniques are
classified as finite state machine (FSM) based
formalisms [2] which have been used to describe a
wide variety of systems such as communication
protocols and services, airline reservation systems,
real-time process control systems, telephone
switching systems, etc. Considering the widespread
use of FSM based formalisms, we focus in this
paper on the application of our approach to those
systems whose externally observable behavior can
be modelled by these formalisms. Without loss of
generality, we assume that original system descrip-
tions are given in the extended finite state ma-
186 H. Ural, R.L. Probert / Communication Protocols and Services
chine (EFSM) formalism of ISO (i.e., Estelle) [6].
Note that original system descriptions given in
this formalism may not be directly executable.
Thus, based on these descriptions, we construct
SFRs in a directly executable form (i.e., in Prolog).
In the following subsections, we describe EFSM
and Prolog based formalisms and the procedure
employed for constructing SFRs in Prolog.
2.2.1. An Extended Finite State Machine For-
malism
Estelle is based on an interaction model char-
acterizing distributed systems [1,7]. In this model,
each system or subsystem is considered as a col-
lection of modules (e.g., processes) where each
module is interacting with its environment (e.g.,
other modules) through its interaction points. An
interaction between two modules takes place at a
pair of corresponding interaction points (one in
each interacting module) which is called a channel.
An interaction is characterized by a name and a
number of parameters. An occurrence of an inter-
action between two modules involves a particular
assignment of valid values to its parameters and a
transfer of this information from one module to
the other over the particular channel. That is, an
interaction transfers information only in one di-
rection. Interactions that transfer information from
a module are considered as "output" interactions
by that module whereas the ones transferring in-
formation to the module are considered as "input"
interactions. It is assumed that each interaction is
atomic and parameter values included in an inter-
action are determined by the module that outputs
the interaction.
Each channel between a pair of interacting
modules is associated with a pair of interaction
queues, one for each direction of information
transfer. Thus, the output interaction of a module
at an interaction point is queued before it is
considered as an input interaction at the corre-
sponding interaction point of the other module.
Furthermore, modules are allowed to have inter-
nal buffers (possibly represented by FIFO queues)
to store some data that they receive through an
input interaction before they send it to another
module via an output interaction.
In Estelle, the externally.observable behavior of
a module (i.e., the possible orderings of interac-
tions exchanged at the interaction points of the
module) is defined by the state space and by the
possible state transitions. The state space of a
module is specified by a set of variables (i.e., the
major state variable(s) and some additional state
variables). A possible state of a module is char-
acterized by the values of all of these variables.
Each state transition is defined by an enabling
condition which is a combination of boolean ex-
pressions involving some state variables and possi-
bly an input interaction and by an action which
may update some state variables and may generate
some output interactions. Transitions may be clas-
sified according to the cause of initiation as fol-
lows:
1) input-initiated transitions which are initiated
by some input interaction and may produce
some output interactions,
2) internal transitions which are spontaneous and
do not produce output interactions,
3) output generating transitions which are sponta-
neous and produce some output interactions.
Note that non-determinism in module descriptions
is introduced by the existence of spontaneous
transitions a n d / o r the presence of more than one
input-initiated transition for a specific input inter-
action at some states. Details of this formal de-
scription technique can be found in [6].
2.2.2. Logic Programming and PROLOG
Logic programming employs a clausal form of
logic [8] where a logic program is considered as a
collection of clauses. The general form of a clause
is conclusion:- condition1 . . . . . conditionN where
conclusion and conditions are of the form: rela-
tion (object1 . . . . . objectM) which denotes a rela-
tionship among the objects. Such a clause states
that the conclusion holds if all the conditions are
met (i.e., a logical implication). A clause with no
conditions is called an assertion.
Each clause in a logic program is interpreted
individually and has two interpretations: namely,
a declarative interpretation where the clause is
considered as a logical implication or an assertion;
and a procedural interpretation which takes the
conclusion of the clause and attempts to satisfy it
either unconditionally (in the case of an assertion)
or conditionally (in the case of a logical impli-
cation). The procedural interpretation of clauses
in a logic program corresponds to a non-determin-
istic computation model [8]. That is, in order to
satisfy a conclusion, the conditions (if any) may
be satisfied in any order and in order to satisfy a
 H. Ural, R.L. Probert / Communication Protocols and Services
chosen condition, any of the clauses whose conclu-
sions match with this condition may be selected.
Prolog [3] is a practical logic programming
language which provides an approximation to this
conputational model by specifying both the order
in which conditions are selected to be satisfied
(i.e., left-to-right) and the order in which specific
clauses are considered to satisfy the chosen condi-
tion (i.e., top-to-down). Prolog supports invertable
execution (i.e., both forward (from input to out-
put) and backward (from output to input) execu-
tion) of procedures defining a complete relation
between input and output. We implement SFRs as
Prolog procedures and then use these procedures
as generators and analyzers of the system func-
tionality. That is, a Prolog procedure P imple-
menting an abstract S F R _ K (e.g., the design of a
system) can be used
1) as a generator to obtain interaction sequences
in which S F R _ K participates. Specifically, P
can be executed as a generator to produce
a) all possible interaction sequences, or
b) a set of all possible output a n d / o r input
interaction sequences observed at the inter-
action points of SFR K for a given input
(or output) interaction sequence.
2) as a validator in recognizer or acceptor mode
to check whether
a) observed interaction sequences obtained
during the execution of a less abstract
S F R _ K + 1 (e.g., an implementation of the
system) are permissible
b) intended interaction sequences obtained by
executing a more abstract S F R _ K - 1 (e.g.,
the specification of the system) are achieva-
ble.
2.2.3. The Form of Executable SFRs
An executable SFR is intended to specify the
system behavior in terms of possible orderings of
externally observable input and output interac-
tions of the system. A Prolog program correspond-
ing to an executable SFR defines all possible
orderings of externally observable system interac-
tions via possible tours of the state space of the
system. It describes system transitions in terms of
transitions of the modules in the system. This
requires definitions of all possible state transitions
of each module as Prolog clauses. These clauses
are constructed from the original EFSM based
module descriptions.
187
C12
IC21
I M21
Fig. 1. Module Descriptions and Channels.
Executable SFRs are constructed as follows:
1) Each system being described consists of a
number of modules. Each module in the system is
denoted by Mij where j = (1, 2 . . . . . m) stands for
the occurrence number of module type i - -
(1, 2 . . . . . n). For example, Figure 1 depicts a sys-
tem which is composed of two occurrences of
module type M1 (i.e., M l l and M12) and one
occurrence of module type M2 (i.e., M21).
2) Modules in the system interact through a
number of channels. Each channel is denoted by
Cpq where q = (1, 2 . . . . . y) stands for the occur-
rence number of channel type p - - ( 1 , 2 . . . . . z).
Continuing with the above example, C l l and C12
are two occurrences of channel type C1, and C21
and C22 are two occurrences of channel type C2.
3) Each channel is associated with at least one
module in the system. If a channel is referred to
by only one module, it is called an external chan-
nel. For example, channels C l l and C12 in Figure
1 are external channels. Each external channel
connects two modules, one of which is not in-
cluded in the system being described. Thus, the
system is thought of interacting with its environ-
ment via external channels. On the other hand, if
a channel is referred to by exactly two modules, it
is called an internal channel. That is, it is a chan-
nel connecting two modules which are included in
the system. For example, channels C21 and C22 in
Figure 1 are internal channels.
4) Each internal channel is represented by a
pair of interaction queues; one for each direction
of information transfer. Thus, modules are inter-
connected by two queues as shown in Figure 2.
The convention is that the input queue at the
interaction point of module Muv is the output
queue at the interaction point of module Mst, and
vice versa.
188 H. Ural, R.L. Probert
INPUT QUEUEFOR Mst
QINst 4 4
Mst
CHANNELCpq
QOUTst ) )
INPUT QUEUEFOR Muv
Fig. 2. Channels Between Modules.
5) For each module Mij in the system, a set of
clauses (SCMij) is constructed using the original
description of the module given in the EFSM
formalism. For each state transition defined in the
original description of the module Mij, the set
SCMij contains a clause which is of the form:
t _ M i j ( P _ S M i j , N _ S M i j , I n p u t , O u t p u t ) :- ena-
bling_condition,action. Here, P _ S M i j and
N SMij stand for the present and the next state
of the module Mij, respectively. Since the state of
the module Mij (SMij) is determined by the values
of all major and additional state variables of the
m o d u l e , P_SMij and N _ S M i j are two lists con-
taining values of state variables before and after
the execution of the transition. Input and Output
are two lists representing interactions of the mod-
ule Mij taking place during the transition. For
each interaction point of the module, there exists
an element in both of these lists. Each element is
either an empty list or a list containing interaction
point identifier, interaction identifier, and interac-
tion parameters depending on the absence or pres-
ence of an interaction at that interaction point,
respectively. The enabling condition is a set of
predicates which must hold for the transition to
take place and actions define some relationships
between mainly the present and the next values of
state variables.
6) A SFR is intended to specify all possible
orderings of externally observable system interac-
tions through all possible system state tours. This
requires the definitions of all possible system tran-
sitions. The system state is defined as the com-
position of the states of all the modules and the
contents of all the interaction queues in the sys-
tem. System transitions can be specified in terms
of transitions of modules in the system. For the
sake of simplicity, we assume that each system
transition corresponds to a transition of one of the
modules. That is, the system state changes as a
/ Communication Protocols and Se/vices
I result of a change in the state of one of the
I QOUTuv modules.
7) This assumption results in a set of clauses
I Muv
(SC) where each clause represents those system
QINuy transitions that are due to a single transition in
one of the modules. Thus, the number of clauses
in the set SC defining all possible system transi-
tions is the same as the number of modules in the
system. A clause in the set SC (e.g., the one
defining all system transitions due to a single
transition of the module Mij) is of the form:
t _ system(P_ System_ State, N _ System_ State,
System Input, System_ Output):-
/ * Queue operations to remove from the head
of input interaction queues of the module
Mij * /
t _ Mij(P _ SMij,N _ SMij ,Input,Output)
/ * Queue operations to insert to the rear of
output interaction queues of the module
Mij * /
8) The SFR is then the union of the set SC and
the sets SCMij (which are the sets of clauses
defining transitions of each module in the system).
In the following sections, we describe the con-
struction of invocation routines which can be used
to automatically invoke executable SFRs for the
purposes of generating or checking observable in-
teraction sequences.
2.3. Trace and Trajectory Checking and Generation
An advantage of constructing executable SFRs
in Prolog is that they can be executed as either
generators or analyzers of the observable behavior
(i.e., i n p u t / o u t p u t interaction sequences) of
specified systems. The invocation of Prolog based
SFRs for either of the above (as well as for
simulation) purposes is achieved by executing the
following relation (denoted by "repeat_until")
which recursively invokes a given SFR:
repeat until(Present_state, Final_state,
[Input,Output Rest of I0 sequence]):-
sfr(Present state, Next state, Input, Output),
repeat until(Next state'Final state,
Rest of I0 sequence).
repeat until(Present state,f:inal state,
[Input,Output]) :-
sfr( Present_state, Final_state, Input, Output).
Here, ":-" and "," read as "if" and " a n d " respec-
tively. The first clause states that an input/output
 H. Ural, R.L. Probert / Communication Protocols and Services
(IO) sequence is obtained on a path from the
present state to the final state if i) the system
changes its state from the present state to a next
state while performing some interactions (denoted
Input and Output) with its environment and ii)
the rest of the i n p u t / o u t p u t sequence is obtained
on a subpath between the next state and the final
state. The second clause applies to the last state
change which leads to the final state.
The relation " r e p e a t _ u n t i l " can be used for:
a) determining whether a given input/output in-
teraction sequence (i.e., a trace or trajectory)
actually results on some execution path be-
tween a pair of states (e.g., initial and final
states) in the SFR and
b) generating possible sequences of input/output
interactions performed by the SFR on its ex-
ecution paths between a pair of states.
The first use corresponds to trace and trajec-
tory checking where checking whether a trace of
SFR K + 1 is permitted by S F R _ K or whether a
trajectory of S F R _ K - 1 is achieved by S F R _ K is
performed in the same manner: The given
i n p u t / o u t p u t interaction sequence is processed
sequentially from left to right and a match for the
sequence is sought by recursively invoking
SFR K.
The second use corresponds to generating the
set of all possible interaction sequences. Often this
set is intractably large due to the existence of large
number of combinations of valid values for inter-
action parameters, or self-loops in certain states,
etc. Such a set can be restricted to a small number
of interesting interaction sequences by guiding the
generation process with some selected input inter-
action sequences. These input interactions se-
quences may be either specified by a tester a n d / o r
constructed automatically by employing some sys-
tematic test generation methods (e.g., transitions
tours, distinguishing sequences, etc. [10,13]). Once
input interaction sequences are selected they may
be used to guide the generation of actual or in-
tended behavior (i.e., traces or trajectories) of
SFRs. That is, each sequence of input interactions
is applied to a SFR and the responses (i.e., output
interactions) of the SFR are recorded in the order
of occurrence as a separate sequence. This may be
achieved by a variant of relation " r e p e a t _ u n t i l "
which is constructed by splitting the IO_sequence
into two sequences, one for the input interactions
and the other for the output interactions:
189
repeat until(Present state, Final state,
[Input Rest of I sequence.],
[Output Rest_of 0 sequence]) :-
sfr(Present state,Next state,input,Output),
repeat_until(Next state, Final state,
Rest of I sequence,
Rest of 0 sequence).
repeat until(Present s-;cate,Final state,
[Input], [Output]):-
sfr(Present_state,Final state,Input,Output).
This relation can also be used for simulation pur-
poses such as determining possible final states that
can be reached from a given initial state or de-
termining possible execution paths between a given
pair of states, etc. Note that it is also possible to
construct a variant of the original relation which
applies a given input interaction sequence to a
SFR and records the output interactions inter-
leaved with applied input interactions in the order
of occurrence. Such a relation is particularly usefull
if one is interested in all possible interleavings of
input and output interactions. The interested
reader can refer to [12] for applications of variants
of " r e p e a t u n t i l " to reachability analysis.
There are basically two disadvantages associ-
ated with the run-time behavior of relation "re-
peat_until" and its variants. One of the disad-
vantages is that " r e p e a t _ u n t i l " may go into an
infinite loop when a cycle is encountered. During
the execution of a SFR, a cycle is encountered
when the next state of the SFR happens to be one
of the states already visited along the execution
path. Such cycles are usually due to spontaneous
transitions whose enabling conditions include only
those state variables which are not modified dur-
ing the execution of these transitions. This disad-
vantage may be eliminated by embedding a loop
detection mechanism into relation " r e p e a t _ until".
An obvious loop detection mechanism is to carry
along the sequence of states visited so far to the
next level of recursion and to check whether the
most recently reached state has already been
visited.
The other disadvantage of " r e p e a t _ u n t i l " is
that when it fails (i.e., terminates unsuccessfully) it
provides no indication about the nature and loca-
tion of failure. Such failures are usually due to
occurrences of unspecified receptions or unex-
pected outputs which may indicate inconsistencies
between SFRs.
Moreover, during trace and trajectory genera-
tion and checking, when " r e p e a t _ u n t i l " fails, it
 H. Ural, R.L. Probert / Communication Protocols and Services
sal of a possible transition path through the com-
plete state space of a possibly non-deterministic
SFR. The set of possible transition paths is de-
termined by the applied sequence of input stimuli
and the set of possible spontaneous transitions at
the states reached during the application of that
sequence of input stimuli.
Thus, an algorithm for a generator is a variant
of the one for a checker obtained by replacing
steps taken for internal transitions with those steps
for spontaneous transitions and by logging the
states visited during traversal in order to construct
the corresponding traces or trajectories.
In Appendix B, we present a Prolog encoding
of an algorithm for trace and trajectory genera-
tors. This algorithm detects and reports unspeci-
fied receptions and infinite loops (if any) and
terminates with irredundant traces or trajectories
of deterministic or non-deterministic SFRs. It is
important to note that once S F R _ K - 1 has been
validated, certified traces obtained during its
validation can be considered as trajectories for (or
potential traces of) S F R _ K . Also, input interac-
tion sequences extracted from validated traces of
S F R _ K - 1 can be used to facilitate generation of
traces of S F R _ K.
In the next section, the use of this approach is
illustrated in the context of communication proto-
cols design and validation.
3. Application of the Approach to Design and
Development of Protocols
Consider the Open Systems Interconnection
(OSI) Reference Model [16]. Protocols and services
referred to in this model are developed in various
phases starting with some natural language de-
scriptions which are called informal specifications.
Formal specifications of protocols and services are
usually based on these informal specifications.
Service specifications describe the service provided
by the layers whereas protocol specifications de-
scribe the behavior of protocol entities in those
layers. Protocol implementations are developed
based on formal or informal protocol specifica-
tions.
Validation activities in a typical protocol devel-
opment process include: informal validation activ-
ities (to relate formal specifications to correspond-
ing informal specifications), protocol design vali-
191
dation (to relate protocol specifications to corre-
sponding service specifications), and protocol test-
ing (to relate protocol implementations to corre-
sponding protocol specifications).
As an illustration of our approach, we consider
the OSI transport protocol (TP) design validation
which aims to demonstrate that the collaboration
of entities executing the TP as described in the TP
specification over an already validated network
service (NS) provides the transport service (TS) as
described in the TS specification. As shown in
Figure 3, this goal is attained via testing the
behavioral equivalence of a refined TS provider
(rts) which is composed of two TP entities (tpl
and tp2) interacting over a NS provider (nsp) with
respect to the abstract TS provider (ts).
3.1. Construction of the Abstract TS Provider
A TS specification given in [4] describes the
externally observable behavior of an abstract TS
provider. Based on this specification, a SFR of the
abstract TS provider is constructed in Prolog as a
single procedure called "ts". Procedure "ts" is a
collection of clauses defining the state transitions
of the abstract TS provider. The following clauses
define the first two transitions in "ts":
ts([idle,idle,B12,B21],[idle,idle,B12,B21],
[[tsapl,tcreq,PARAM1],[]],
[[tsapl,tdind,PARAM2],[]]):-
congestion,input([tsapl,tcreq,PARAM1]),
output([tsapl,tdind,PARAM2]).
ts([idle,idle,B12,B21],[wait_accept,idle,[],[]],
[[tsapl ,tcreq,PARAM1],[]],[[I,[]I) :-
n o _ congestion,input([tsapl,tcreq, PARAM1]).
The first and the second arguments in the conclu-
sion of each clause are two lists representing the
present and next state for the abstract TS pro-
vider. The state of the provider is determined by
the values of major state variables $1 and $2 and
the contents of the internal buffers B12 and B21
which are two additional state variables. (For the
sake of simplicity, we ignore all other additional
state variables in our examples throughout this
paper). The third (forth) argument stands for in-
put (output) interactions at two transport service
access points, namely, tsapl and tsap2. Here, an
empty list (denoted by []) indicates that no input
or output interaction occurs at the related interac-
tion point. For example, in the second clause,
[[I,[]], [[],[]]] indicates that only an input interac-
192 H. Ural, R.L. Probert / Communication Protocols and Services
TEST DRIVER
I1
tpl
a I
I
ts
rts
I
,I.:t2 tp2 |
/¢,'/
I 1101 0101 nsp 1102
Fig. 3. A configurationfor ProtocolDesignValidation.
tion I occurs at tsapl whereas no input and output
interactions occur at tsap2.
Thus, the first clause corresponds to the transi-
tion initiated by the input interaction tcreq (carry-
ing a list of parameters, denoted by PARAM1) at
tsapl and takes place when major state variables
S1 = idle and $2 = idle and when there is conges-
tion in the system. There is no action related to
this transition, only an output interaction (i.e.,
tdind) is generated at tsapl. Note that the values
of major state variables remain unchanged.
The second clause corresponds to a transition
that is initiated by an input interaction at tsapl
changes the value of the major state variable S1
and initializes internal buffers but does not gener-
ate any output. Note that, procedures "input" and
"output" are used to generate as well as recognize
input and output interactions with interaction
parameters, respectively. These two procedures are
based on the definitions of interactions and
parameters. For more details, see [15].
3.2. Construction of the Refined TS Prooider
As shown in Figure 3, a refined TS provider
(rts) is composed of a NS provider (nsp) and two
TP entities (tpl and tp2). A SFR of the refined TS
provider can be constructed by utilizing the SFRs
~,\
0102
of nsp, tpl, and tp2 which are obtained from the
original NS and TP specifications, respectively.
Based on the TP specification given in [5], a
SFR of a TP entity is constructed as a collection
of clauses called procedure " t p " which defines the
state transitions of the TP entity. Conclusions of
the clauses defining state transitions in procedure
" t p " are of the form:
tp([PT, PBFU,PBTU],[NT,NBFU,NBTU],
[I _ tsap,I _ nsap],[O_ tsap,O_ nsap]).
Here, the state of the TP entity is determined by
the value of the major state variable T, and by the
contents of internal buffers BFU (buffer to store
data from user) and BTU (buffer to store data to
user). The third (forth) argument represents the
list of input (output) interactions at the transport
and the network service access points (i.e., tsap
and nsap). In order to construct two copies of this
SFR, each clause in " t p " is replicated while aug-
menting each identifier in the clause with an in-
teger (i.e., 1 or 2). Hence, the conclusion of each
clause defining a transition in " t p l " and "tp2"
(which stand for TP entity-1 and TP entity-2,
respectively) is written in the following form:
tpl([PT1,PBFU1,PBTU1],[NT1,NBFU1,NBTU1],
[I_tsapl,I_nsapl],[O_tsapl,O_nsapl]).
tp2([PT2,PBFU2,PBTU2],[NT2,NBFU2,NBTU2],
[ I _ t s a p 2 , I _ n s a p 2 ] , [ O _ tsap2,O_nsap2]).
 H. Ural, R.L. Probert / Communication Protocols and Sert,ices
Based on a NS specification, a SFR of the NS
provider can be constructed as a collection of
clauses called procedure "nsp". This procedure
defines the state transitions of the NS provider.
Assuming that a NS specification similar to the
TS specification in [4] is given, the state of the NS
provider is determined by the values of the two
major state variables $1 and $2, and by contents
of internal buffers B12 and B21. Moreover, "nsp"
is interconnected to both " t p l " and "tp2" at two
network service access points (nsapl and nsap2
respectively) via interaction queues. The outputs
O_nsapl and O_nsap2 (inputs I_nsapl and
I_nsap2) of " t p l " and "tp2" at nsapl and nsap2
are the inputs (outputs) of "nsp" at those interac-
tion points. Hence, each state transition of the NS
provider is represented in "nsp" by a clause whose
conclusion is as follows:
nsp(PS1,PS2,PB12,PB21],[NS1,NS2,NB12,NB21],
[O_nsapl,O_nsap2][I_nsapl,I_nsap2])
Given the procedures "nsp", " t p l " , and "tp2",
a Prolog procedure, denoted "rts", is constructed
to specify the transitions of the refined TS pro-
vider in terms of transitions of its modules. Recall
that the system state is determined as a composi-
tion of the states of all the modules and the
contents of all the interaction queues in the sys-
tem. Thus, the system state of the refined TS
provider is defined as the composition of the
states of " t p l " , "tp2", and "nsp" and the con-
tents of interaction queues IIQ1, OIQ1, IIQ2, and
OIQ2 (see Figure 3). Conclusion of each clause in
procedure "rts" is in the following form:
rts([PT1,PBFU1,PBTU1,PT2,PBFU2,PBTU2,
PS1,PS2,PB12,PB21,
PIIQI,POIQ1,PIIQ2,POIQ2]/* PRESENT
SYSTEM STATE * /
[NTI,NBFU1,NBTU 1,NT2,NBFU2,NBTU2,
NS1,NS2,NB12,NB21,
NIIQ1,NOIQ1,NIIQ2,NOIQ2]/* NEXT
SYSTEM STATE * /
[I_tsapl,I_tsap2],[O_ tsapl,O_ tsap2])
Assuming that each transition of the refined TS
provider corresponds to a change in the state of
only one of its modules, procedure "rts" will
contain only three clauses: one for each system
transition caused by a transition in one of the
modules. For more details, see [15].
Both "ts" and "rts" may be employed by trace
and trajectory generators and checkers to carry
out validation activities. Examples of trace and
193
trajectory generation and checking are presented
in the following section.
3.3. Examples of Trace and Trajectory Generation
and Checking
The Prolog procedure, denoted "totgen", given
in Appendix B receives an input interaction se-
quence and by applying this sequence to a SFR
(e.g., procedure "ts" or procedure "rts") generates
all corresponding traces or trajectories as se-
quences of input and output interactions. Each
interaction sequence is represented as a list whose
elements are in the form of:
[Interaction-Type,[TSAP-Id,TS-Primitive-Type,
TS-Primitive-Parameters]]
where Interaction-Type is either "i" (stands for
input), or "o" (stands for output). TSAP-Id is the
identifier for the access point at which the interac-
tion occurs. Note that if the interaction sequence
consists of only input interactions then the Inter-
action-Type is dropped for simplicity.
Two examples of generating traces and trajec-
tories are given in Appendix C. In these examples,
"totgen" is invoked via procedure "run-totgen"
which includes a group of sample input interac-
tion sequences. Each invocation of procedure
"run-totgen" contains the sequence number of the
input interaction sequence to be passed to
"totgen". Accordingly, the first example involves
generating traces of the refined TS provider. In
this case, "totgen" applies the given input interac-
tion sequence to procedure "rts" and constructs
all corresponding traces of the refined TS pro-
vider. In the second example, trajectories for the
refined TS provider are obtained from the abstract
TS provider. That is, "totgen" applies the given
input interaction sequence to procedure "ts" and
records its responses interleaved with applied in-
put interactions to construct all corresponding
trajectories.
Note that, in these two examples, the same set
of input interaction sequences is used for gener-
ating traces and trajectories. However, only those
traces of "rts" and trajectories of "ts" correspond-
ing to the last input interaction sequence are iden-
tical. The difference between sets of traces and
trajectories corresponding to the first two input
interaction sequences stems from an inconsistency
194 H. Ural, R.L. Probert / Communication Protocols and Services
between "ts" and "rts": That is, "ts" does not
allow the connection initiator to terminate the
connection establishment prior to receiving a con-
firmation whereas "rts" allows this particular type
of termination. This inconsistency results in an
additional trace (i.e., the fifth trace) of "rts" cor-
responding to the first input interaction sequence
and three traces of "rts" corresponding to the
second input interaction sequence.
It is interesting to note that this inconsistency
can be revealed during trace checking. However,
since no trajectory reflecting this situation could
be generated from "ts", this particular incon-
sistency would not be revealed during trajectory
checking. Thus, this is an interesting illustration
taken from the public domain of the distinction
between trace and trajectory checking.
The Prolog procedure, denoted "totvar', given
in Appendix A receives an interaction sequence
(i.e., either a trace or a trajectory) and by invoking
a SFR (e.g., procedure "ts" or procedure "rts")
checks whether this interaction sequence is per-
missible or achiavable by this SFR.
In the examples included in Appendix D, pro-
cedure "totval" is invoked via procedure "run-
totval" which contains a group of sample interac-
tion sequences. Each invocation of procedure
"run-totval" carries an invocation sequence num-
ber which identifies the sequence to be passed to
"totval". In the first example, traces of the refined
TS provider is checked by the abstract TS pro-
vider. That is, "totval" is used to invoke proce-
dure "ts" to check whether traces of procedure
"rts" are permissible interaction sequences. In the
second example, trajectories obtained from the
abstract TS provider are applied to the refined TS
provider. In this case, "totval" invokes procedure
"rts" to check whether given interaction sequences
are achievable by this procedure. Notice that when
the given interaction sequence is not achievable or
permissible an error message is printed.
4. Conclusions
We have presented an approach for detecting
inconsistencies between different representations
of the same system functionality. This approach is
based on observable behaviors of SFRs at differ-
ent levels of abstraction. These SFRs may be
requirements, functional specifications, detailed
designs, or implementations of a given system.
The approach involves two complementary
consistency checking activities: namely, trace and
trajectory checking which seem to be appropriate
to validation activities anticipated in a protocol
development process, particularly in the case of
layered protocols such as in the OSI Reference
Model. In this context, trace checking can be used
for relating formal specifications of services to
informal specifications expressed in a natural lan-
guage. As well, both trace and trajectory checking
can be employed for protocol design validation
(relating protocol specifications to corresponding
service specifications) and for testing of protocol
implementations (relating implementations to pro-
tocol specifications).
As an illustration of the feasibility and useful-
ness of the approach, we presented an application
to design validation of a transport protocol. In
this case, the abstraction (SFR_K-1) is the trans-
port service specification and the refinement
(SFR_K) is the refined transport service provider
constructed from the transport protocol specifica-
tion and the underlying network service specifica-
tion according to the OSI Reference Model. A
minor inconsistency was found, namely that a
premature disconnection is permitted by the re-
finement, yet is not allowed in the abstraction.
We have shown how to construct SFRs in
Prolog from specifications given in a popular
EFSM formalism. Our focus was on the structure
of these Prolog based SFRs rather than on the
specifics of translating EFSM constructs into
equivalent Prolog constructs. The translation
methodology is straightforward, but does depend
on the particular definitions of EFSM constructs
[141.
A major advantage of constructing SFRs in
Prolog is the capability of reversable execution of
these SFRs. This capability allows not only check-
ing and generating externally observable behaviors
of SFRs via their simulated execution, but also
utilization of SFRs as reference specifications for
trace checking purposes. Another advantage of
Prolog-based SFRs seems to be the ease of con-
structing tools (invocation routines) to direct trace
and trajectory checking and generation.
Finally, as does any other dynamic testing ex-
ercise, this approach requires the selection of rep-
resentative and discriminating test sequences (i.e.,
input/output interaction sequences) to facilitate
 H. Ural, R.L. Probert / Communication Protocols and Services
t r a c e a n d t r a j e c t o r y c h e c k i n g . S e l e c t i o n o f dis-
c r i m i n a t i n g s e q u e n c e s of i n p u t / o u t p u t interac-
t i o n s is a closely r e l a t e d p r o b l e m w h i c h is a d d r e s s -
e d in m o r e d e t a i l in e a r l i e r w o r k s [10,11,13], a n d is
the s u b j e c t of c o n t i n u i n g study.
Acknowledgements
T h e a u t h o r s g r a t e f u l l y a c k n o w l e d g e the s u p p o r t
f r o m the N a t u r a l S c i e n c e s a n d E n g i n e e r i n g R e -
search Council of Canada.
References
[1] G.v. Bochmann, A General Transition Model for Proto-
cols and Communication Services, IEEE Trans. on Com-
munications, Vol. 28, No. 4, 1980, pp. 643-650.
[2] G.v. Bochmann and C.A. Sunshine, Formal Methods in
Communication Protocol Design, IEEE Trans. on Com-
munications, Vol. 28, No. 4, 1980, pp. 624-631.
[3] W.F. Clocksin and C.S. Mellish, Programming in Prolog,
Springer-Verlag, 1981.
[4] G.v. Bochmann et al, A FDT Based on an Extended State
Transition Model, ISO/TC 97/SG16/WG1, Subgroup B
on FDT, Mar 1981.
[5] G.v. Bochmann, Example of a Transport Protocol Specifi-
cation, ISO/TC 97/SG16/WG1, Subgroup B on FDT,
Nov 1982.
[6] "Draft proposal of Estelle", ISO/TC 97/SG21/DP 9074,
June 1985.
195
[7] C. Jard, and G.v. Bochmann, An Approach to Testing
Specifications, Journal of Systems and Software, 3, 1983,
pp. 315-323.
[8] R. Kowalski, Logic For Problem Solving, New York,
North-Holland, 1979.
[9] R.L. Probert, D.R. Skuce, and H. Ural, Specification of
Representative Test Cases", Proc. of 16th Hawaii Int.
Conf. on System Sciences, Jan 1983, pp. 190-196.
[10] B. Sarikaya and G.v. Bochmann, Some Experience with
Test Sequence Generation for Protocols, Proc. of 2nd Int.
Workshop on Protocol Specification, Verification, and
Testing, Cal, May 1982, pp. 555 567.
[11] B. Sarikaya and H. Ural, Test Sequence Generation for
Protocols Using PROLOG, Tech. Report: TR-84-17, Dept.
of CSI, Univ. of Ottawa, 1984.
[12] D.P. Sidhu, Protocol Verification via Executable Logic
Specifications, Proc. of 3rd Int. Workshop on Protocol
Specification, Verification, and Testing, Zurich, May 1983,
pp: 237-248.
[13] H. Ural, and R.L. Probert, User-guided Test Sequence
Generation, Proc. of 3rd lnt. Workshop on Protocol
Specification, Verification, and Testing, Zurich, May 1983,
pp: 421-436.
[14] H. Ural, The Construction of Logic Specifications for
Communication Protocols and Services, Tech. Report:
TR-85-17, Dept. of CSI, University of Ottawa, 1985.
[15] H. Ural, Logic Specifications for Communication Sys-
tems, Proc. of PCCC 86, Phoenix, Arizona, March 1986,
pp: 121-128.
[16] H. Zimmermann, OSI Reference Model-The ISO Model
of Architecture for Open Systems Interconnection, IEEE
Trans. on Communications, Vol. 28, No. 4. 1980, pp.
425-432.
196 H. Ural, R.L. Probert / Communication Protocols and Services

Appendix A

Trace and Trajectory Checker: Procedure “Totval”

totval(IOS) :- echo(IOS), initial(SPS), invoker(IOS,SPS).

invoker([],SPS) :- checker([],SPS).
invoker([[i,tsapl,I,P]],SPS):- checker([[[tsapl,I,P],[]],[[],[]]],SPS,SNS),
invoker([],SNS).
invoker([[o,tsapl,O,P]],SPS):- checker([[[],[]],[[tsapl,O,P],[]]],SPS,SNS),
invoker([],SNS).
invoker([[i,tsap2,I,P]],SPS):- checker([[[],[tsap2,I,P]],[[],[]]],SPS,SNS),
invoker([],SNS).
invoker([[o,tsap2,0,P]],SPS):- checker([[[],[]],[[],[tsap2,0,P]]],SPS,SNS),
invoker([],SNS).
invoker([[Sl,Cl,Il,Pl]~Rl],SPS):- Rl=[YIRZ], Y=[SZ,C2,12,P2],
((Sl=i, SZ=i, ((Cl=tsapl, R=Rl, ~=~~~~~~~~,~~1~~11~~~1,~111~
;(Cl=tsa@, R=Rl, ~=~~~1,~C~,~~,~111,~~1,~111~~~
;(Sl=i, S2=0, ((Cl=tsapl, CP=tsapl,
(R=Rl,~=~~~~~,~~,~~1,~11,~~1,~111
;R=R2,~=~~~~~,~~,~~1,~11,~~~~,~~,~~1,~111~~
;(Cl=tsapP, C2=tsap2,
(R=RI,~=~~~1,~~~,~~,~~11,~~1,~111
;R=@, ~=~~~1,~~~,~~,~~11,~~1,~~~,~~,~~111~~
;(Cl=tsapl, CZ=tsap2,
(R=Rl,~=~~~~~,~~,~~1,~11,~~1,[111
;R=Q, ~=~~~~~,~~,~~1~~11,~~1,~~~~~~,~~111~~
;(Cl=tsapE, C2=tsapl,
(R=RI,~=~~~1~~~~,~~,~~11~~~1,~111
;R=R2,~=~~~1,~~~,~~,~~11,~~~~,~~,~~1,~111~~~~
;(Sl=o, Cl=tsapl, R=Rl, O=[[[],[]],[[Cl,Il,pl],[]]])
;(Sl=o, Cl=tsapE, R=Rl, O=[[[],[]],[[],[Cl,Il,Pl]]])
) ,checker(O,SPS,SNS), invoker(R,SNS).

checker([],SNS) :- final( member(FS,SNS), nl, write('*,** VALID ***I),!.

checker(IO,SPS,SNS) :- for_each(IO,SPS,[],SSNS), ((SSNS=[],!,errorl(IO))
;(not(SSNS=[]), for_all(SSNS,[],SNS))).

/* Apply each invocation IO to each state CS in set SPS and

obtain set SSNS */

for each(_,[],X,X).
forIeach(IO,[CSIRESTSTATUS],LS,SSNS) :- get(IO,CS,LSTATUS),
append(LS,LSTATUS,LN), for_each(IO,RESTSTATUS,LN,SSNS).
get([I,O],PS,LSTATUS) :- INSERT_l...SEE COMMENTS
,setof(NS, T, LSTATUS), !.
W_9_9[l).
/* Find all states that can be reached by internal transitions
from each state in set SSNS and obtain set SNS */

for_all([],X,X).
for_all([CS/RS],LS,SNS) :- get_all(CS,LSl), union(LS,LSl,LN),
for_all(RS,LN,SNS),!.
get_all(CS,LSl) :- store_p(CS), not(each path(CS)), collect(LS1).
each_path(CS) :- get_each(CS,[CS]), fail.
get_each(PS,PSF) :- INSERT_E...SEE COMMENTS
,store_s(NS) ,check(NS,PSF), get_each(NS,[NSjPSF]).
get_each(_,_).

initial(INSERT_3...SEE COMMENTS).
final (INSERT_I...SEE COMMENTS).
 H. Ural, R.L. Probert / Communication Protocols and Ser~,ices 197

/* U t i l i t y Procedures */

append([],X,X).
append([XIR],Y,[XIZ]) :- append(R,Y,Z).

member(X,[Xl_]).
member(X,[ IY]) :- member(X,Y).

union([],X,X).
union([XLR],Y,Z) :- member(X,Y) ,!, union(R,Y,Z).
union([XIR],Y,[XIZ]) :- union(R,Y,Z).
check(S,X) :- not(member(S,X)), store_p(S),!.
check(S,X) :- error2(S,X).
collect([XIR]) :- retract(p(X)), collect(R),
collect([]).
store_s(NS) :- not(s(NS)) , assert(s(NS)) ,!.
store_s(NS) :- fail.
store p(NS) :- not(p(NS)) , asserta(p(NS)) ,!
store_p(NS) :- fail.
echo(IOS) :- nl, w r i t e ( ' I n p u t Output Interaction Sequence'),
nl, outprint(lOS).
outprint([]).
outprint([HIT]) :- write(H) nl, outprint(T).

is_I([[I,[]],[[],[]]]).
is_I([[[],l],[[],[]]]).
is O ( [ [ [ ] , [ ] ] , [ o , [ ] ] ] ) .
is o ( [ [ [ ] , [ ] ] , [ [ ] , o ] ] ) .
get_type([ll,[]],[OZ,[]],1)
get_type([[],12],[[],02],2)
e r r o r l ( l O ) :-
( ( i s l(lO);is_O(lO)) -> nl, write('Execution Aborted')),
( i s _ l ( l O ) -> nl,write('Unspecified Reception Encountered:'),
nl,write(lO);true),
(is 0(I0) -> nl,write('Unexpected Output Encountered:'),
nl,write(lO);true),
( ( i s _ l ( l O ) ; i s 0(I0)) -> nl, w r i t e ( ' * * * NOT VALID * * * ' ) , n l ) , !, f a i l .
error2(Y,PSF) :-
nl, w r i t e ( ' I n f i n i t e idle loop encountered'),
nl, write('The p a t h : ' ) , nl, outprint(PSF),
nl, write('forms a loop w i t h : ' ) , nl, o u t p r i n t ( Y ) , ! , f a i l .

When " t o t v a l " is used to invoke

a) the abstract TS provider b) the refined TS provider
INSERT I T=..[ts,PS,NS,I,O] get type(l,O,X), T=..[rts,X,PS,NS,I,O]
INSERT-2 t s ( P S , N S , [ [ ] , [ ] ] , [ [ ] , [ ] ] ) rts(,PS,NS,[[],[]],[[],[]])
INSERT-3 [ [ i d l e , i d l e , [ ] , I l l ] [[shut,[],[],shut,[],[],
idle,idle,[],[],[],[],[],[]]]
INSERT 4 [idle,idle .... ] [shut . . . . . shut . . . . .
idle,idle ............ ]
*/
198 H. Ural, R. L. Probert / Communicarion Protocols and Services

Appendix B

Trace and Trajectory Generator: Procedure “Totgen ”

totgen(SIS) :- initial(SSi_l), echo(SIS), invoker(SSi_l,SIS), alltrace(SSi_1).

invoker(SSi_l,[]).
invoker(%i_l,[IIRIS]) :- for_each(I,SSi_l,[],SSINi),
((SSINi=[],!,errorl(SSi_l,I,RIS))
;(not(SSINi=[]), for_all(SSINi,[],SSi), invoker(SSi,RIS))).

/* Apply each input stimulus IS to each state CS in set SSi_l and

obtain set SSINi */

for_each(_,Cl,X,X).
for_each(IS,[CSjRESTSTATUS],LS,SSINi) :- get(IS,CS,LSTATUS),
append(LS,LSTATUS,LN), for_each(IS,RESTSTATUS,LN,SSINi).

get(Il,[_,[CNll PSI,_,_],LSTATUS) :- Il=[tsapllR], 12=[], CN is CNl+l,

T=..INSERT_l...SEE COMMENTS,
setof([[CNl~PS],[CN~NS],[I1,12],[01,02]],T,LSTATUS), ! .
get(I2,[_,[CNllPSl ,_,_],LSTATlJS) :- Il=[], 12=[tsapZ(R], CN is CNl+l,
T=..INSERT_E...SEE COMMENTS,
setof([~CNl~PS],~CN~NS],~Il,I2],[01,02]],T,LSTATUS), ! .
get(_,_,Cl).
/* Find all states that can be reached by spontaneous transitions
from each state in set SSINi and obtain set SSi */

for_all( 1,X,X).
for_all( CSIRS],LS,SSi) :- store_s(CS,T), ((T=O, for_all(RS,LS,SSi))
;(T= , get_all(CS,LSl), !, union(LS,LSl,LN), for_all(RS,LN,SSi))), !.

get_all(CS,LSl) :- store_p(CS), not(each_path(CS)), collect(LS1).

each_path([_,[CNlIPS],_,_]) :- get_each([CNljPS],[PS]), fail.
get_each([CNlIPS],PSF) :- INSERT_3...SEE COMMENTS,
Y=~~~~~l~Sl,C~~~lNSl,[[l,[ll,~~~,~~jl,
store-s(Y), check(Y,NS,PSF), get_each([CNljNS],[NSlPSF]).

alltrace([[_,IS,_ ,_]I) :- allpaths( traceout.

allpaths :- final( at(IS,FS,T), not(path(T)), assert(path(T)), fail
allpaths(

at([IlX],[JlX],[]) :- not(I=J).
at(X,Y,Z) :- s([X,Xl,I,O]), at(Xl,Y,Zl), rmv(I,O,V), append(V,Zl,Z).

initial INSERT_4...SEE COMMENTS).

final INSERT_5...SEE COMMENTS).
 H. Ural, R.L. Probert / Communication Protocols and Seruices 199

/* U t i l i t y Procedures */

append([],X,X).
append([XIR],Y,[X]Z]) :- append(R,Y,Z).

member(X,[X1 ]).
member(X,[_IY]) :- member(X,Y).
union([],X,X).
union([XIR],Y,Z ) :- member(X,Y) ,!, union(R,Y,Z).
union([XIR],Y,[XIZ]) :- union(R,Y,Z).
check(Y,S,X):- not(member(S,X)), store=p(Y),!.
check(Y,S,X):- error2(S,X).
collect([XIR] :- retract(p(X)), collect(R),
collect([]).
store s(NS,I) - not(s(NS)), assert(s(NS)), !
store_s(NS,O)
store_s(NS) :- not(s(NS)), assert(s(NS)), !.
store_s(NS) :- f a i l .
store_p(NS) :- not(p(NS)), asserta(p(NS)), !.
store p(NS) :- f a i l .
traceout:- retract(path(T)), traceprint(T), nl, traceout.
traceout.
traceprint([]).
t r a c e p r i n t ( [ X I T ] ) :- write(X), nl, w r i t e ( ' ' ) , traceprint(T).
l i s t s :- s(L), w r i t e ( L ) , nl, f a i l .
outprint([]).
o u t p r i n t ( [ X I T ] ) :- write(X), nl, outprint(T).
echo(SIS) :- nl, w r i t e ( ' I n p u t Interaction Sequence i s : ' ) , nl, outprint(SIS),
nl, write('Trace or trajectory i s ( a r e ) : ' ) , nl.
e r r o r l ( I S , l , R l S ) :-
nl, write('Execution Aborted. Unspecified reception encountered.'),nl,
nl, w r i t e ( ' A l l possible Status that the representation can be'),
nl, w r i t e ( ' a f t e r the application of previous Input I n t e r a c t i o n . ' ) ,
nl, o u t p r i n t ( I S ) ,
nl, write('Current Input Interaction Sequence:'), nl, write(1), nl,
nl, write(tRest of Input Interaction Sequence:'), nl, outprint(RIS),
nl, write('Status seen up to this p o i n t : ' ) , nl, n o t ( l i s t s ) , !, f a i l .
error2(Y,PSF) :-
nl, write('Execution Aborted. I n f i n i t e Idle loop encountered'),
nl, write('The p a t h : ' ) , nl, outprint(PSF),
nl, write('forms a loop w i t h : ' ) , nl, outprint(Y), !, f a i l .
When "totgen" is used to invoke
a) the abstract TS provider b) the refined TS provider
INSERT 1 [ t s , P S , N S , [ I I , 1 2 ] , [ 0 1 , 0 2 ] ] [rts,I,PS,NS,[II,12],[01,02]],
INSERT-2 [ t s , P S , N S , [ I I , 1 2 ] , [ 0 1 , 0 2 ] ] [rts,2,PS,NS,[II,12],[OI,02]],
INSERT-3 ts(PS,NS,[[],[]],[01,02]) rts(_,PS,NS,[[],[]],[01,02]),
INSERT~4 [ [ _ , [ O , i d l e , i d l e , [ ] , [ ] ] . . . . ]] [[_,[O,shut,[],[],shut,[],[],
idle,idle,[],[],[],[],[],[]] . . . . ]]
INSERT_5 [O,idle,idle .... ] [O,shut . . . . . shut . . . . .
idle,idle ............ ]
200 14. Ural, R.L. Probert / Communication Protocols and Services

Appendix C
run_totgen(Z) :- clear [i,[tsapl,tcreq,p]]
,input_interaction_sequence(Z,X) [o,[tsap2,tcind,p]]
,totgen(X). [i,[tsap2,tareq,p]]
clear :- retract(s(_)), f a i l . [i,[tsap2,tdatr,1]]
clear. [o,[tsapl,taind,p]]
input_interaction_sequence(l,[ [i,[tsapl,tdreq,user]]
[tsapl,tcreq,p], [o,[tsap2,tdind,user]]
[tsap2,tareq,p],
[tsap2,tdatr,1], [i,[tsapl,tcreq,p]]
[tsapl,tdreq,user] [o,[tsap2,tcind,p]]
]). [i,[tsap2,tareq,p]]
input_interaction_sequence(2,[ [i,[tsap2,tdatr,1]]
[tsapl,tcreq,p], [i,[tsapl,tdreq,user]]
[tsapl,tdreq,user] [o,[tsap2,tdind,user]]
]),
input interaction_sequence(3,[ yes
[tsapl,tcreq,p], I ?- run totgen(2).
[tsap2,tdreq,user] Input InTeraction Sequence is:
]). [tsapl,tcreq,p]
[tsapl,tdreq,user]
Trace or trajectory is(are):
EXAMPLEC-I [i,[tsapl,tcreq,p]]
[o,[tsap2,tcind,p]]
C-Prolog version 1.4a
[i,[tsapl,tdreq,user]]
[ Restoring f i l e /.plstartup ] [o,[tsap2,tdind,user]]
[ ?- [rts,tpl,tp2,nsp,totgen,run_totgen].
rts consulted 2052 bytes 0.85 sec.
tpl consulted 6496 bytes 3.1 sec.
[i,[tsapl,tcreq,p]]
[i,[tsapl,tdreq,user]]
tp2 consulted 6868 bytes 3.36667 sec. [o,[tsap2,tcind,p]]
nsp consulted 9760 bytes 4.45 sec. [o,[tsap2,tdind,user]]
totgen consulted 8068 bytes 2.76667 sec.
run totgen consulted 996 bytes 0.400007 sec. [i,[tsapl,tcreq,p]]
[i,[tsapl,tdreq,user]]
yes
[ ?- run totgen(1).
Input InTeraction Sequenceis:
yes
I ?- run totgen(3).
[tsapl,tcreq,p] Input InTeraction Sequence is:
[tsap2,tareq,p] [tsapl,tcreq,p]
[tsap2,tdatr,1] [tsap2,tdreq,user]
[tsapl,tdreq,user]
Trace or trajectory is(are):
Trace or trajectory is(are): [i,[tsapl,tcreq,p]]
[i,[tsapl,tcreq,p]] [o,[tsap2,tcind,p]]
[o,[tsap2,tcind,p]] [i,[tsap2,tdreq,user]]
[i,[tsap2,tareq,p]] [o,[tsapl,tdind,user]]
[o,[tsapl,taind,p]]
[i,[tsap2,tdatr,1]] yes
[o,[tsapl,tdati,1]] I ?- halt.
[i,[tsapl,tdreq,user]] [ Prolog execution halted ]
[o,[tsap2,tdind,user]]
[i,[tsapl,tcreq,p]] EXAMPLEC-2
[o,[tsap2,tcind,p]]
[i,[tsap2,tareq,p]] C-Prolog version 1.4a
[o,[tsapl,taind,p]] [ Restoring f i l e /.plstartup ]
[i,[tsap2,tdatr,1]] I ?- [ts, totgen, run totgen].
[i,[tsapl,tdreq,user]] setparam tsp consulted 992 bytes 0.683336 sec
[o,[tsap2,tdind,user]] ts consulted 9208 bytes 5.45 sec.
totgen consulted 7904 bytes 4.6 sec.
[i,[tsapl,tcreq,p]] run_totgen consulted 996 bytes 0.616667 sec.
[o,[tsap2,tcind,p]]
[i,[tsap2,tareq,p]] yes
[i,[tsap2,tdatr,1]] [ 7- run totgen(1).
[o,[tsapl,taind,p]] Input InTeraction Sequence is:
[o,[tsapl,tdati,1]] [tsapl,tcreq,p]
[i,[tsapl,tdreq,user]] [tsap2,tareq,p]
[o,[tsap2,tdind,user]] [tsap2,tdatr,l]
[tsapl,tdreq,user]
 H. UraL R.L. Probert / Communication Protocols and Services 201

Trace or trajectory is(are): Trace or trajectory is(are):

[i,[tsapl,tcreq,p]] [i,[tsapl,tcreq,p]]
[o,[tsap2,tcind,p]] [o,[tsap2,tcind,p]]
[i,[tsap2,tareq,p]] [i,[tsap2,tdreq,user]]
[o,[tsapl,taind,p]] [o,[tsapl,tdind,user]]
[i,[tsap2,tdatr,1]]
[o,[tsapl,tdati,1]] yes
[i,[tsapl,tdreq,user]] i ?- halt.
[o,[tsap2,tdind,user]] [ Prolog execution halted ]
[i,[tsapl,tcreq,p]]
[o,[tsap2,tcind,p]]
[i,[tsap2,tareq,p]]
[o,[tsapl,taind,p]] Appendix D
[i,[tsap2,tdatr,1]]
[i,[tsapl,tdreq,user]]
[o,[tsap2,tdind,user]] run totval(X) :- clear
,interaction sequence(X,S)
[i,[tsapl,tcreq,p]] ,totval(S).
[o,[tsap2,tcind,p]] clear:- retract(s(_)), f a i l .
[i,[tsap2,tareq,p]] clear.
[i,[tsap2,tdatr,l]] interaction sequence(l,[
[o,[tsapl,taind,p]] [i,tsapl,tcreq,p]
[o,[tsapl,tdati,l]] [o,tsap2,tcind,p]
[i,[tsapl,tdreq,user]] [i,tsap2,tareq,p]
[o,[tsap2,tdind,user]] [i,tsap2,tdatr,l]
[i,tsap2,tdatr,2]
[i,[tsapl,tcreq,p]] [o,tsapl,taind,p]
[o,[tsap2,tcind,p]] [i,tsapl,tdatr,1]
[i,[tsap2,tareq,p]] [i,tsapl,tdatr,2]
[i,[tsap2,tdatr,1]] [o,tsapl,tdati,1]
[o,[tsapl,taind,p]] [i,tsapl,tdatr,3]
[i,[tsapl,tdreq,user]] [o,tsapl,tdati,2]
[o,[tsap2,tdind,user]] [o,tsap2,tdati,1]
[o,tsap2,tdati,3]
]).
yes interaction_sequence(2,[
I ?- run totgen(2). [i,tsapl,tcreq,p],
Input Interaction Sequence is: [o,tsap2,tcind,p],
[tsapl,tcreq,p] [i,tsap2,tareq,p],
[tsapl,tdreq,user] [i,tsap2,tdatr,1],
[i,tsap2,tdatr,2],
Trace or trajectory is(are): [o,tsapl,taind,p],
[i,tsapl,tdatr,1],
Execution Aborted. Unspecified reception encountered. [i,tsapl,tdatr,2],
[o,tsapl,tdati,1],
All possible Status that the representation can be [i,tsapl,tdatr,3],
after the application of previous Input Interaction. [o,tsapl,tdati,2],
[[l,wait accept,idle,[],[]],[1,wait accept,wait_accept,[],[]], [o,tsap2,tdati,1],
[[],[]],[[],[tsap2,tcind,p]]] [i,tsapl,tdreq,user],
[[O,idle,idle,E],[]],El,wait accept,idle,I],[]], [o,tsap2,tdind,user]
[[tsapl,tcreq,p],[]],[[],[]]] ])-
interaction sequence(3,[
Current Input Interaction Sequence: [i,tsapl,tcreq,p],
[tsapl,tdreq,user] [o,tsap2,tcind,p],
[i,tsap2,tareq,p],
Rest of Input Interaction Sequence: [i,tsap2,tdatr,1],
[o,tsapl,taind,p],
Status seen up to this point: [i,tsapl,tdatr,2],
[[O,idle,idle,[],[]],[1,wait_accept,idle,[],[]], [o,tsapl,tdati,l],
[[tsapl,tcreq,p],[]],[[],[]]] [o,tsap2,tdati,1]
[[1,wait accept,idle,[],[]],[1,wait_accept,wait_accept,[],[]], ]).
[[],[]],[[],[tsap2,tcind,p]]] interaction sequence(4,[
[i,tsapl,tcreq,p],
no [o,tsap2,tcind,p],
( 7- run totgen(3). [i,tsap2,tareq,p],
Input Interaction Sequence is: [i,tsap2,tdatr,l],
[tsapl,tcreq,p] [o,tsapl,taind,p],
[tsap2,tdreq,user] [i,tsapl,tdatr,2],
[o,tsapl,tdati,1],
[o,tsap2,tdati,2],
[i,tsapl,tdreq,user],
[o,tsap2,tdind,user]
]).
202 14, Ural, R.L. Probert / Communication Protocols and Services

EXAMPLE D-I EXAMPLE D-2

C-Prolog version 1.4a C-Prolog version 1.4a
[ Restoring f i l e /.plstartup ] [ Restoring f i l e /.plstartup ]
I ?- Its, totval, run totval]. I ?- [rts,tpl,tp2,nsp,totval,run_totval]
setparam tsp consulted 992 bytes 0.416669 sec. rts consulted 2052 bytes 0.783333 sec.
ts consulted 9208 bytes 3.28333 sec. tpl consulted 6496 bytes 2.98333 sec.
totval consulted 8528 bytes 2.78333 sec. tp2 consulted 6868 bytes 3.3 sec.
run totval consulted 1948 bytes 0.550004 sec. nsp consulted 9760 bytes 4.3 sec.
totval consulted 8784 bytes 2.76667 sec.
yes run totval consulted 3072 bytes 0.85 sec
I ?- run totval(1).
Input OuTput Interaction Sequence yes
[i,tsapl,tcreq,p] I ?- run totval(3).
[o,tsap2,tcind,p] Input OuTput Interaction Sequence
[i,tsap2,tareq,p] [i,tsapl,tcreq,p]
[i,tsap2,tdatr,1] [o,tsap2,tcind,p]
[i,tsap2,tdatr,2] [i,tsap2,tareq,p]
[o,tsapl,taind,p] [i,tsap2,tdatr,1]
[i,tsapl,tdatr,l] [o,tsapl,taind,p]
[i,tsapl,tdatr,2] [i,tsapl,tdatr,2]
[o,tsapl,tdati,1] [o,tsapl,tdati,1]
[i,tsapl,tdatr,3] [o,tsap2,tdati,1]
[o,tsapl,tdati,2]
[o,tsap2,tdati,1] Execution Aborted
[o,tsap2,tdati,3] Unexpected Output Encountered:
[[[],[]],[[],[tsap2,tdati,1]]]
Execution Aborted *** NOT VALID ***
Unexpected Output Encountered:
[[[],[]],[[],[tsap2,tdati,3]]] no
*** NOT VALID *** I ?- run totval(4).
Input OuTput Interaction Sequence
no [i,tsapl,tcreq,p]
I ?- run totval(2). [o,tsap2,tcind,p]
Input OuTput Interaction Sequence [i,tsap2,tareq,p]
[i,tsapl,tcreq,p] [i,tsap2,tdatr,1]
[o,tsap2,tcind,p] [o,tsapl,taind,p]
[i,tsap2,tareq,p] [i,tsapl,tdatr,2]
[i,tsap2,tdatr,1] [o,tsapl,tdati,1]
[i,tsap2,tdatr,2] [o,tsap2,tdati,2]
[o,tsapl,taind,p] [i,tsapl,tdreq,user]
[i,tsapl,tdatr,1] [o,tsap2,tdind,user]
[i,t~apl,tdatr,2]
[o,tsapl,tdati,1] *** VALID ***
[i,tsapl,tdatr,3] yes
[o,tsapl,tdati,2] I ?- halt.
[o,tsap2,tdati,l] [ Prolog execution halted ]
[i,tsapl,tdreq,user]
[o,tsap2,tdind,user]

*** VALID ***

yes
[ ?- halt.
[ Prolog execution halted ]