1 s2.0 S1569190X0500016X Main

Simulation Modelling Practice and Theory 13 (2005) 505–524
www.elsevier.com/locate/simpat
A modelling tool for hierarchical

stochastic activity networks
Mohammad Abdollahi Azgomi *, Ali Movaghar
Department of Computer Engineering, Sharif University of Technology, Tehran 11365, Iran
Received 10 July 2004; received in revised form 13 November 2004; accepted 28 January 2005
Available online 9 March 2005
Abstract
Hierarchical stochastic activity networks (HSANs) are a newly introduced extension of sto-
chastic activity networks (SANs). HSAN models encapsulate hierarchies and a key benefit of
these models is the possibility of automatic employment of composition techniques by their
modelling tools. For modelling and evaluation with HSANs, we have developed a software
tool called SANBuilder. This tool has an integrated development environment (IDE) for con-
struction, animation, simulation and analytic solution of SAN-based models. We have imple-
mented in this tool some state-of-the-art methods for the simulation and analytic solution of
SAN and HSAN models. In addition to an introduction to HSANs, this paper will describe
the features, capabilities, organization, solution methods, implementation and a performance
evaluation of the SANBuilder modelling tool.
2005 Elsevier B.V. All rights reserved.
Keywords: Stochastic Petri nets; Stochastic activity networks; Hierarchical stochastic activity networks;
Modelling tool; SANBuilder
*
Corresponding author. Tel.: +98 216164628.
E-mail addresses: azgomi@mehr.sharif.edu (M.A. Azgomi), movaghar@sharif.edu (A. Movaghar).
1569-190X/$ - see front matter 2005 Elsevier B.V. All rights reserved.
doi:10.1016/j.simpat.2005.01.004
506 M.A. Azgomi, A. Movaghar / Simulation Modelling Practice and Theory 13 (2005) 505–524
1. Introduction
Hierarchical stochastic activity networks (HSANs) [1] are a newly introduced hier-
archical extension of stochastic activity networks (SANs). SAN models are a gener-
alization of stochastic Petri nets (SPNs) [13] and closely resemble the class of
generalized stochastic Petri nets (GSPNs) [7]. The development of SANs was moti-
vated by the need for a class of network (graphical) models suited to modelling
the performability of distributed real-time systems.
A few techniques have been introduced for constructing hierarchical and com-
posed SAN models. The main motivations of these techniques were to avoid state-
space explosion problem. An important state space reduction technique, which is
implemented in UltraSAN [19] and Möbius [12] modelling tools, is the Replicate/Join
construct [18]. This construct provides a hierarchical, tree like method of combining
submodels to form a larger, composed model. As the name may imply, there are two
main methods that can be used to combine models: Replicates and Joins. Replicates
are used to replicate a model any number of times, often having one or more state
variables shared among all of the replicas as a means of connection. Joins are used
to bring together two or more dissimilar models, connecting them by sharing certain
state variables between them [22]. However, there is a set of issues with this con-
struct. It is limited to a tree-like structure and an arbitrary symmetric model struc-
ture, such as ring or mesh cannot be expressed by this construct.
Replicate/Join construct has been extended and generalized in the work of [22] on
the graph composition formalism in the Möbius modelling framework [12]. This for-
malism does not limit the model hierarchy to a tree-like structure and any arbitrary
structure (such as ring or mesh) is possible.
Using the above techniques, a composed model is constructed in a bottom-up
manner using the two operations. While top–down model construction, especially,
for large models, is more appropriate. On the other hand, the use of these composi-
tion formalisms is specific to the modelling tools (UltraSAN or Möbius) and not
SANs in general. They have not been defined formally along with the definition of
SANs.
On the other hand, programming languages, especially object-oriented languages,
have simple and intuitive ways of encapsulating hierarchies. Keeping in mind these
ways and to overcome the above difficulties and restrictions of SANs, we have intro-
duced HSAN models.
HSANs provide a construct for composing a hierarchy of SAN submodels that is
called macro activity. HSAN models encapsulate hierarchies and a key benefit of
these models is the possibility of automatic employment of composition techniques,
such as Replicate/Join [18] or Graph Composition [22] formalisms by their modelling
tools.
Modelling and analysis with Petri nets and their extensions need a software tool to
help model construction and analysis. The original definition of SANs [14,20] has
been used as a formalism in UltraSAN and Möbius modelling tools, developed by
PERFORM group at UIUC. UltraSAN is a software environment for performance,
dependability and performability evaluation with SAN models. Möbius is a tool for
M.A. Azgomi, A. Movaghar / Simulation Modelling Practice and Theory 13 (2005) 505–524 507
system-level performance and dependability modelling. Möbius supports model

specification in multiple modelling formalisms as well as many different model solu-
tion methods. The original definition of SAN models is supported as an atomic
model by Möbius tool [10].
It is ideal to integrate HSANs into Möbius framework. Because of the existence of
various kinds of solvers and simulators and implementation of SANs as an atomic
model, Möbius is the best modelling framework for supporting HSANs. However,
in the lack of such integration, we have developed a modelling tool for HSAN mod-
els called SANBuilder [2]. This tool has an integrated development environment (IDE),
which allows modellers to construct, compile, animate, simulate and solve SAN-
based models, including a new definition of SANs and HSANs.
The rest of this paper is organized into five sections. In Section 2, an introduction
to HSANs is presented. Section 3 gives a general overview of SANBuilder and its
algorithms and techniques. An evaluation of the performance of tool is presented
in Section 4. Finally, some concluding remarks are mentioned in Section 5.
2. Hierarchical stochastic activity networks
In this section we will briefly introduce a new definition of SANs. Then, we will
present the informal definitions of HSANs and an example of these models. For
more information about the theoretical aspects of HSANs, please see [1,6].
2.1. A new definition of SANs
There are two definitions for SAN models: The original definition of SANs [14,20]
and a new definition of SANs [15]. We will use the latter definition as the base model
throughout this paper. Therefore, we will introduce this definition of SANs in the
following paragraphs.
A new definition of SANs [15] is based on a unified view of the system in three
settings: nondeterministic, probabilistic, and stochastic. In a nondeterministic setting,
nondeterminacy and parallelism are represented in a nondeterministic manner. In a
probabilistic setting, nondeterminacy is specified probabilistically but parallelism is
treated nondeterministically. In a stochastic setting, both nondeterminacy and par-
allelism are modelled probabilistically.
The nondeterministic setting of SANs is referred to as activity networks, which are
nondeterministic models for representing concurrent and reactive systems. Applica-
tion of this setting is on the analysis of logical aspects or verification of concurrent
and reactive systems. Disregarding the timing related information of the model
and viewing it in a nondeterministic setting accomplish this. The activity network
model is then translated into a transition system and verification is done.
For evaluating the operational aspects of systems such as performance, depend-
ability and performability, the stochastic setting of SANs is used. In this setting, both
nondeterminacy and parallelism are represented probabilistically [15]. Based on the
probability distribution of timed activities, Markovian or non-Markovian SAN
models will be resulted. Application of the another setting of SANs, namely, prob-
abilistic setting, is on probabilistic verification.
As we mentioned before, the nondeterministic setting of SANs is called activity
networks. Activity networks have been developed for representing concurrent sys-
tems. SAN models are closely related to Petri nets with the following extensions.
The transition of Petri nets is replaced by a primitive called activity in activity net-
works. There are two types of activities: instantaneous activities and timed activities.
The former describe events, which occur instantaneously, the latter represent pro-
cesses, which usually take some time to complete. Instantaneous activities represent
system activities, which, relative to the performance variable in question, are com-
pleted in a negligible amount of time. Instantaneous activities model nondeterminacy
while timed activities represent parallelism. Other primitives, which distinguish activ-
ity networks from Petri nets, are gates. Gates model complex interactions among
activities and, thus, increase modelling flexibility.
The original definition of SANs, as appeared in 1984, includes extra primitives,
called ‘‘cases,’’ for modelling nondeterminacy, which, with the new definition, can
equivalently be replaced by some instantaneous activities. A model based on the ori-
ginal definition of SANs, must be checked for well-behavedness. The well-behaved-
ness check is in general undecidable and is computationally complex for most
models. Some solutions have been proposed in the literature to alleviate this prob-
lem. However, in a new definition of SANs, no such check will ever be necessary.
Because the syntax of the model has been defined free from well-behavedness check-
ing. For more information about the differences between these two definitions of
SANs, please see [14,20,15].
Graphically, activity networks consist of the following elements:
1. Activities, which are of two kinds: timed and instantaneous. In a graphical repre-
sentation, a timed activity is depicted as and an instantaneous activity is shown
as .
2. Places, depicted as .
3. Input gates, which have a finite set of inputs and one output. An input gate with n
inputs is depicted as in Fig. 1(a). To each such input gate is associated a n-ary
computable predicate, called the enabling predicate, such that e: Nn ! {true, false}
1 1
2 2
. .
. .
n n
(a) (b)
Fig. 1. Graphical representation of gates: (a) input gate and (b) output gate.
and a computable partial function f, called the input function, such that f:
Nn ! Nn, where f is defined for all values for which the enabling predicate is true
and N is the set of natural numbers.
4. Output gates, which have a finite set of outputs and one input. Gates are intro-
duced to permit greater flexibility in defining enabling and completion rules. An
output gate with n output is depicted as in Fig. 1(b). To each such output gate
is associated a computable function g, called output function, such that g:
Nn ! Nn, where N is the set of natural numbers.
Structurally, an activity network is an interconnection of a finite number of prim-

itives, subject to the following connection rules [14]:
1. Each input of an input gate is connected to a unique place and the output of an
input gate is connected to a single activity.
2. Different input gates of an activity are connected to different places.
3. Each output of an output gate is connected to a unique place and the input of an
output gate in connected to a single activity.
4. Different output gates of an activity for a case are connected to different places.
5. Each place and activity is connected to some input or output gates.
In order to facilitate the use and to increase the understandability of activity net-
works, the following conventions are used in their graphical representation:
(a) Input gates with similar enabling predicates and input functions are named
similarly.
(b) Output gates with similar output functions are also named similarly.
(c) An input gate with one input, enabling predicate e(x): x P 1, and input func-
tion f such that f(x) = x 1, is shown as a directed line from its input to its
output.
(d) An output gate with one output and output function f such that g(x) = x + 1, is
shown as a directed line from its input to its output.
(e) An input gate with one input, enabling predicate e(x): x = 0, and identity input
function is shown as a directed line from its input to its output crossed by two
short parallel lines.
The stochastic setting of SANs is called stochastic activity networks. A SAN is

formed by adjoining functions C, F, and G, where C specifies the case probability
assigned to instantaneous activities, F represents the probability distribution func-
tions of activity times and G describes the sets of reactivation markings of timed
activities.
2.2. HSAN models
Hierarchical stochastic activity network (HSAN) models provide hierarchies for

SANs. These models have a new element called macro activity (MA) in addition
to the five primitives of SANs. A macro activity is an HSAN submodel, which is

composed of SAN elements or other macro activities.
The syntax of the usage of macro activity is similar to the usage of timed or
instantaneous activities. Place fusion is used as a mechanism for interfacing macro
activities to other parts of an HSAN model. A macro activity may have zero or more
input and output fusion places. Fusion places are a subset of normal places. A macro
activity has a well-defined interface that is similar to parameter passing of procedure
and functions in high-level programming languages. The places surrounding a macro
activity are formal fusion places. When a macro activity is used in an HSAN model,
these formal places will be bound by actual places, which are normal places of SANs.
In a graphical representation, a fusion place is depicted as . A graphical represen-
tation of a macro activity is shown in Fig. 2(a) and its usage in Fig. 2(b).
2.3. An example of HSAN models
As an example of HSAN models, please see the model depicted in Fig. 3. Fig. 3(a)
displays a macro activity, called MM1NQ, for the M/M/1/N queue. The macro activ-
ity has the following elements: input (an input fusion place), Arrival (a timed activity
that models the arrival process), ChkFull (an output gate that checks for the capacity
of the queue, N), Queue (a place that models the queue line), Service (a timed activity
that models the service time) and output (an output fusion place). The gate table for
the macro activity MM1NQ is shown in Table 1. In this table, the function of Chk-
Full is defined. This function checks whether the queue is full or not. Arrivals, Re-
jected and N are three global variables, which denote the number of arrivals to
MAName
IFP1 MA
OFP1 MAName OP1
Body
IP1
IFPn MAInstance
OFPm
input fusion places output fusion places
(a) IPn OPm

(b)
Fig. 2. Graphical notation of a macro activity: (a) definition and (b) usage.
Fig. 3. HSAN representation of a queueing network: (a) MM1NQ macro activity, (b) HSAN model.
Table 1
Gate table for the macro activity MM1NQ of Fig. 3
Gate name Function
Arrivals++;
if (MARK(Queue) < N)
ChkFull MARK(Queue)++;
else
Rejected++;
the system, the number of rejected customers and the capacity of the queue,
respectively.
Fig. 3(b) displays the HSAN model for a queueing network, composed of six tan-
dem/parallel queues. Q1 through Q6, are some instantiations of the MM1NQ. Arri-
val and Departure timed activities models the input and output process of the
network. Input, Output1 through Output4 are some places, which are bound to the
input/output fusion places of Q1 through Q6.
3. SANBuilder modelling tool
In this section, we introduce the software structure and implementation of SAN-

Builder modelling tool. SANBuilder runs under Windows 2000/XP and has an inte-
grated development environment (IDE). The IDE of SANBuilder provides features
and capabilities for construction, compilation, animation, simulation and analyti-
cally solution of SAN-based models.
3.1. Software structure of SANBuilder
The overall software structure of SANBuilder, including its main modules and
their relations, has been depicted in Fig. 4. Elements of this structure are as follows:
Animator
Analytic
Solver
Model
GUI Transformer State Space Sparse Matrix
SAN Model
Generator Handler
Editor Compiler Model
Flattener
D.-E. State Space

C++Builder
Simulator Handler
Fig. 4. Software structure of SANBuilder.

1. The Graphical User Interface (GUI): The GUI of SANBuilder is an IDE for
editing SANs and HSAN models, checking their syntax and semantics, compi-
lation, animation and evaluation using state space analysis or simulation meth-
ods. This integration makes SANBuilder a user-friendly modelling tool. A view
of the user interface of SANBuilder is displayed in Fig. 5.
2. SAN Editor: This graphical editor allows the construction of SAN-based mod-
els. An important feature of SAN Editor is its feature for saving and loading
models and macro activities in an interchange format, called SAN markup lan-
guage (SANML) [3]. SANML is based on the Petri nets markup language
(PNML) [8].
3. Model Compiler: The model compiler translates the model and generates the
executable model. It partially uses the compiler of C++ language to compile
the model.
4. Model Flattener: A simple approach for the evaluation of HSAN models is
transforming them into a flat SAN model and using the existing methods.
Model Flattener does such transformation.
5. Model Transformer: An advanced approach for the evaluation of HSAN mod-
els is using the existing techniques for the construction of composed models
with reduced state spaces. Model Transformer converts an HSAN model using
one of these techniques.
Fig. 5. A view of the user interface of SANBuilder.

6. Model Animator: SANBuilder can animate models. A feature that is also

known as token-game animation. For animating, the tool shows a step-by-step
execution of the network by firing enabled activities and changing the marking.
Animation is done in a stochastic manner (i.e. the result of discrete-event sim-
ulation of the model is animated on the graphical user interface). Debugging is
a useful feature of this animator, which enables the modeller to define queries
about the model behaviour and trace their results while the animation is in
progress.
7. State Space Generator: It executes a SAN model for generating its state space.
The reachability graph (RG) of the model is built using the following State
Space Handler module.
8. State Space Handler: This module stores and manages the RG in a hash table
data structure.
9. Analytic Solver: If all timed activities of the model are exponentially distrib-
uted, this module can be used for model solution. If so, the corresponding con-
tinuous-time Markov chain (CTMC) will be generated and if it is finite, its
ergodicity will also be checked. If it is ergodic, its global balance equations will
be solved to compute its steady-state probabilities. Finally, the predefined
results of the solution and user-defined queries will be computed from the
steady-state probabilities and displayed on GUI.
10. Discrete-Event Simulator: If the steady-state solver cannot be used, simulation
may be utilized for performance evaluation. This module simulates SANs using
a discrete-event simulation algorithm. It also collects the predefined and user-
defined statistics and displays them whenever the simulation is in progress or
completed.
11. Automatic Code Generation: This feature allows the modeller to generate C++
source codes from the SAN-based models. This is a useful feature for model-
ling software systems by SAN-based models and SANBuilder tool. We are
working to add the capabilities for source code generation of more languages,
including Java and Delphi, to SANBuilder.
3.2. Implementation of SANBuilder
In the following subsections, we briefly describe some important algorithms and

techniques used for the implementation of SANBuilder. We have used C/C++ pro-
gramming language and Borland C++Builder compiler for the implementation of
SANBuilder.
3.2.1. Well-defined checker

An HSAN model is well-defined if its dependency graph (DG) is finite and acyclic
[6]. In a DG, nodes are macro activities and the composition relation between macro
activities and the main HSAN model determines arcs. The root of DG is the HSAN
model. If a cycle is detected in DG, the model is not well-defined and therefore can-
not be analysed. Otherwise, it is possible to employ an algorithm to transform and
analyse the corresponding HSAN model. Well-defined checker constructs a DG for

the model and checks it to be finite and acyclic.
The model of an airport is used in [22] to describe the Replicate/Join construct.
We have built an HSAN model for the airport using SANBuilder. The HSAN model
is shown in Fig. 6. The dependency graph of the model, which is generated by SAN-
Builder, is shown in Fig. 7.
Fig. 6. HSAN model of an airport: (a) gate macro activity, (b) airline macro activity, (c) gates macro
activity, (d) airline-gates macro activity, and (e) airport HSAN model.
Fig. 7. An acyclic dependency graph of the HSAN model of an airport, generated by SANBuilder.
3.2.2. Model compiler

The input/output function of the input/output gates of SANs are general comput-
able functions, written in a high-level programming language (such as C/C++). The
definition of input predicates of input gates, enabling rate functions and reactivation
predicates of timed activities and case probability functions of instantaneous activi-
ties can also be defined in the same way. As an example, please see the input gate
definition form of SANBuilder in Fig. 8.
For building an executable model, the definition of these predicates and functions
should be compiled. To do this, Model Compiler of SANBuilder generates a C/C++
source file corresponding to all predicates and functions of the model. Then it in-
vokes the command-line compiler of Borland C++ Builder to generate a dynamic link
library (DLL). SANBuilder will load the generated DLL, before animation, simula-
tion or analytic solution of the model.
3.2.3. State space generator

The state space generation algorithm of SANBuilder for SAN models is based on
the work in the Möbius modelling framework [21]. The state space generation algo-
rithm is divided into two parts. The first part is the main state generation algorithm
that determines all states of a model in a breadth-first manner. The second part spec-
ifies precisely how to determine next states when timed and/or instantaneous activ-
ities are enabled in a specific state.
The state-space generation algorithm (Algorithm 1) is shown in Fig. 9(a). The set
of generated states (S) contains all unique states that have been produced at any
point in time by the state-space generator. Generated states are those tangible states
that have been found using the GenerateNS algorithm. A tangible state is a state that
has no instantaneous activity enabled in it. The unexplored set contains all tangible
states that have not been used by GenerateNS. The set of next tangible states found
by GenerateNS is stored in the NS set. Algorithm 2 (GenerateNS) that is shown in
Fig. 9(b) is used to determine all tangible next states of an unstable state.
Fig. 8. Input gate definition form.

Fig. 9. State space generation algorithm: (a) main algorithm and (b) next tangible states generation
algorithm.
GenerateNS is a recursive algorithm that takes as input a state and a probability. Ini-
tially, the probability value is set to 1.0.
3.2.4. State Space Handler

The most important problem with state space handling is the amount of time and
memory needed for large models. Due to fast lookup and insertion time, a hash table
is an appropriate data structure for storing the set of generated states (S). Such a
hash table is used in the Möbius tool [21]. We have implemented a hash table, which
is based on the method proposed in [23]. In this method, the hash key is computed by
the function of Fig. 10. The hash function computes a polynomial function of degree
32 by use of Horners rule [23].
The above hashing function is not collision-free. Therefore, a method for rehash-
ing is required. Rehashing schemes use a second hashing operation when there is a
collision. If there is a further collision, we rehash until an empty position in the hash
table is found. The rehashing function can either be a new function or a reuse of the
original one. The following are two useful rehashing strategies:
• Linear probing: One of the simplest rehashing functions is +1 (or 1). There-
fore, if a collision occurs, the neighbouring position in the hash table will be
used. It calculates the new address extremely quickly and may be extremely
efficient.
Function HashFunction (State)

HashKey = 0
for i = 0 to StateSize-1
HashKey = 37 * HashKey + State[i]
HashKey = HashKey mod HashSize
Return HashKey
Fig. 10. The hash function of state space handler.
• Quadratic probing: If the secondary hash function depends on the rehash index,
the strategy is called quadratic probing.
We have used a quadratic probing strategy, where in the case of a collision, the
new index is computed by function,
f ðjÞ ¼ f ðj 1Þ þ 2j 1; ð1Þ
where j is the number of collisions.
The above function is dependent to the rehash index. A more complex function
can also be used. However, if a hash table size that is a prime number is used, the
above formula for quadratic probing procedure is guaranteed to terminate if the
table is at least half empty. If a prime number hash-table size is not used, the proce-
dure may loop and never terminate. For this reason, rehashing is done when the ta-
ble becomes half full [23].
For insertion in the hash table, new indices are computed until an empty position
is found. For a lookup, all states that are reached must be compared to the next state
until either a match occurs (the state is not new), or an empty position is reached (the
state is new and should be added to the table).
3.2.5. Model Flattener

Each HSAN model has an equivalent flat SAN model. For the analysis of an
HSAN model, it is possible to transform it to an equivalent flat SAN model. Since,
the dependency graph of Fig. 6 is acyclic, the HSAN model can be flattened. A sub-
stitution algorithm can be employed to flatten the HSAN model. In each step of the
algorithm, all MAs on the leaves of the graph will be substitute by their definitions.
This will be repeated until the only node on the graph is the root node. The resulting
model is a flat SAN model. The algorithm of Fig. 11 does such a transformation. In
this algorithm, we use the notations of the formal definitions of HSANs [1,6].
Naming in HSAN models is local. Therefore, the name of two elements in two
different levels of the hierarchy of an HSAN model may be identical. To resolve
the problem of duplicate names in the substitution of MA with its definition, the
name of each element of an MA will be preceded by the name of its parent MA.
For example, if we have an MA named ma1 in an HSAN model and there is a place
Fig. 11. HSAN flattening algorithm.
named p1 in the definition of ma1, a place named ma1Æp1 will be added to the flat-
tened model.
3.2.6. Model transformer

The main disadvantage of the above flattening method is the explosion of nodes in
the resulting model that may lead to the explosion of the state space of the model.
There are a few techniques for constructing SAN models in a way, which avoid
state-space explosion problem. A key benefit of HSAN models is the possibility of
automatic employment of such techniques by their modelling tools. SANBuilder
can transform an HSAN model into the following composition formalisms:
Replicate/Join construct: A composition technique for SANs is the Replicate/Join
construct [18]. A possible way of the analysis of HSAN models is to transform them
into this construct. For this purpose, SANBuilder checks for a tree-like structure in
the dependency graph of an HSAN model. Then, it automatically finds shared states
based on the fusion places and organizes the model using Replicate and Join oper-
ations. The transformation of the HSAN model of an airport to Replicate/Join con-
struct is shown in Fig. 12, which is same as the airport composed model presented in
[22]. For the solution of the resulting model, the technique proposed in [18] or [22] is
employed.
Graph Composition formalism: Another composition formalism, which has been
proposed in the Möbius modelling framework for SANs and other models, is the
Fig. 12. The Replicate/Join transformation of model.
Graph Composition formalism [22]. This formalism does not limit the model hierar-
chy to a tree-like structure and any arbitrary structure (such as ring or mesh) is pos-
sible. SANBuilder can also check for the possibility of the usage of this formalism.
Then, it transforms the corresponding HSAN model and uses the method proposed
in [22] to solve the model.
3.2.7. Analytic solver

If all timed activities of a SAN model are exponentially distributed, it can be rep-
resented by a continuous-time Markov chain (CTMC). The resulting CTMC will be
ergodic if its reachability graph (RG) is finite and fully connected. An ergodic
CTMC can then be solved analytically using standard Markovian solution tech-
niques. Accordingly, the global balance equations of a CTMC may be solved to
compute the steady-state probabilities of its states. Since the state-transition-rate
matrices of such CTMCs are usually sparse, numerical methods such as Gauss-Seidel
and Gauss-elimination [16] are used. Most performance measures of interest, such as
responsiveness (including waiting time, processing time, queue length, etc.) and usage-
level (including throughput and utilization factor) may be evaluated from such steady-
state probabilities.
In SANBuilder, when the state space is being generated, the state-transition-rate
matrix will be constructed. We have implemented two techniques for handling sparse
matrices. One of them uses main memory and the other uses a C++Builder database
table for storing the matrix. The first technique is limited to the amount of free main
memory, but is fast. On the other hand, the second technique is less limited, but is
not fast. SANBuilder automatically computes the steady-state probabilities, the
maximum and average number of tokens of places, throughput of timed or instanta-
neous activities and the average enabling time of timed activities. In addition, it
allows the user to define his/her interested markings and queries that will be com-
puted by the tool when the solution is completed.
Currently, we are working on implementation of some fast and efficient methods
for analytic solution. One of these methods is ‘‘on-the-fly’’ solution technique, such
as [11], which do not need to explicitly store the matrix.
3.2.8. Discrete-event simulator

If an HSAN model or one of its macro activities is composed of one or more non-
exponential timed activities or its state-space is infinite, it may not be solved analyt-
ically. In such cases, discrete-event simulation may be employed to solve the model.
The discrete-event simulation algorithm for SAN models is shown in Fig. 13.
SANBuilder automatically computes the maximum and average number of to-
kens for all places, number of firings, throughput, total enabling time and enabling
probability for all timed activities and the number of firings and throughput for all
instantaneous activities for all models. In addition, it allows the user to define his/her
interested markings and queries that will be computed at the end of simulation or
even while the simulation is in progress.
We are working on implementation of efficient techniques for the simulation of
HSAN models. These methods are based on a method proposed for fast simulation
of SAN composed models [17] and techniques for discrete-event simulation in the
Möbius framework [24].
Fig. 13. Discrete-event simulator of SAN models.

4. Evaluation and comparison
In this section, we will evaluate the performance of state space generator and dis-
crete-event simulator of SANBuilder tool using a well-known model, which has been
used with other modelling tools. Then, we will compare the performance results with
UltraSAN and Möbius tools.
The Kanban model [9] is used as a base model to evaluate several tools, such as,
UltraSAN and Möbius [22]. The model represents a simple factory production line.
The model is divided into four stages. At each stage, an object either completes,
moves to another stage, or returns to be worked on again. Objects leaving stage
one may enter either stage two or stage three. Objects are recombined in the final
stage, after proceeding through stage two or three.
A flat SAN representation of this model is shown in Fig. 14. The capacity of each
state within the model is governed by the value of the Kanban places (Kanban1
through Kanban4). By modifying the value of these places, we can observe how vary-
ing the capacity of the stages affects the overall throughput of the system. We have
also constructed an HSAN representation of the Kanban model that is shown in Fig.
14. Fig. 15(a) shows KanMA macro activity corresponding to each Kanban stage.
Fig. 15(b) shows an HSAN model composed of four KanMA macro activities. K1
through K4 places represent the capacity of each stage.
We have investigated the performance of the state-space generator for the two
models while the hash size is 3,000,017 (a prime number) and the number of tokens
in Kanban places varies from 1 to 5. These executions are on a personal computer
with a Pentium 4, 1.5 GHZ CPU and 256 MB of RAM.
The results are same for both models and are shown in Table 2. The results show
that the number of states will increase considerably when the number of tokens in
Kanban places varies from 1 to 5. As a result, the time of state space generation
is increased, too.
We have also investigated the performance of the discrete-event simulator for the
two models while the number of tokens in Kanban places varies from 1 to 5. For this
purpose, we have executed the simulation for 10 replications each for 1,000,000 units
Fig. 14. A flat SAN representation of the Kanban model.

Fig. 15. HSAN representation of the Kanban model: (a) KanMA and (b) Kanban HSAN model.
Table 2
Results of state space generation of Kanban model
No. of tokens No. of states Time (s)
1 160 0.01
2 4,600 0.10
3 58,400 3.00
4 454,475 44.00
5 2,546,532 1998.00
Table 3
Simulation time for Kanban model
No. of tokens Time (s)
1 176
2 323
3 365
4 501
5 550
of time, while the enabling rate of all timed activities is equal to 1. The results are
(nearly) same for both flat SAN and HSANs models and are shown in Table 3.
In [22] a comparison of the time and memory for state space generation of the
Kanban model by UltraSAN and Möbius is presented. The results are obtained
by execution of both tools on an HP workstation. Since, SANBuilder can run only

on Windows, we could not prepare a same environment for its evaluation to com-
pare the performance results with the above tools.
5. Conclusions
In this paper, we have briefly introduced hierarchical stochastic activity networks

(HSANs). Then, we have presented the structure, features, capabilities and imple-
mentation of SANBuilder modelling tool. SANBuilder has an integrated develop-
ment environment (IDE) for the graphical edition, animation, simulation and
analytic solution of SAN-based models. For the solution of HSAN models, SAN-
Builder checks for the possibility of the employment of composition formalisms,
such as Replicate/Join construct or the Graph Composition formalism. This trans-
formation is done through analysis of the dependency graph of an HSAN model.
We have implemented in SANBuilder some state-of-the-art techniques for simu-
lation and analytic solution of SAN-based models. We have evaluated the perfor-
mance of the state space generator and discrete-event simulator of this tool with a
well-known model. To make this tool more useful for the application on large-scale
systems, we are working to implement efficient methods for steady state and tran-
sient solution and simulation of SAN-based models.
Currently, we are implementing support for two other newly introduced high-level
extensions of SANs, namely coloured stochastic activity networks (CSANs) [4] and
object stochastic activity networks (OSANs) [5] in SANBuilder. In this paper, we fo-
cused on implementation of HSANs in this modelling tool. Details of the implemen-
tation of CSANs and OSANs in SANBuilder will be published in our future papers.
References
[1] M. Abdollahi Azgomi, A. Movaghar, Hierarchical stochastic activity networks, in: Proceedings of
17th European Simulation Multiconference—10th International Conference on Analytical and
Stochastic Modelling Tech. and App. (ASMTA03), SCS (2003) 169–174.
[2] M. Abdollahi Azgomi, A. Movaghar, A modelling tool for hierarchical stochastic activity networks,
in: Proceedings of 11th International Conference on Analytical and Stochastic Modelling Tech. and
App. (ASMTA04), ESM (2004) 141–146.
[3] M. Abdollahi Azgomi, A. Movaghar, An interchange format for stochastic activity networks based
on PNML, in: Proceedings of ICTAPN04 Satellite Workshop on Definition, Implementation and
Application of a Standard Interchange Format for Petri Nets, Bologna, Italy (June 2004) 1–10.
[4] M. Abdollahi Azgomi, A. Movaghar, Coloured stochastic activity networks: definitions and
behaviour, in: Proceedings of 20th Annual UK Performance Evaluation Workshop (UKPEW04),
Bradford, UK (2004) 297–308.
[5] M. Abdollahi Azgomi, A. Movaghar, Modeling and evaluation with object stochastic activity
networks, in: Proceedings of 1st International Conference on Quantitative Evaluation of Systems
(QEST04), Enschede, The Netherlands, IEEE CS Press (2004) 326–327.
[6] M. Abdollahi Azgomi, A. Movaghar, Hierarchical stochastic activity networks: formal definitions
and behaviour, Int. J. Simul. Syst. Sci. Technol. 6 (1–2) (2005) 56–66.
[7] M. Ajmone Marsan, G. Balbo, G. Conte, A class of generalized stochastic Petri nets for performance
evaluation multiprocessors systems, ACM Trans. Comput. Syst. 2 (2) (1984) 93–122.
[8] J. Billington et al., The Petri net markup language: concepts, technology, and tools, in: Proceedings of
24th International Conference on Application and Theory Petri Nets (ICTAPN04), LNCS 2679,
Springer (2003) 482–505.
[9] G. Ciardo, M. Tilgner, On the use of Kronecker operators for the solution of generalized stochastic
Petri nets. NASA Langley Research Center, ICASE Report #96-35 CR-198336 (1996).
[10] T. Courtney et al., The Möbius modeling environment: recent developments, in: Proceedings of 1st
International Conference on Quantitative Evaluation of Systems (QEST04), Enschede, The
Netherlands, IEEE CS Press (2004) 328–329.
[11] D.D. Deavours, W.H. Sanders, On-the-fly solution techniques for stochastic Petri nets and
extensions, IEEE Trans. Software Eng. 24 (10) (1998) 889–902.
[12] D.D. Deavours et al., The Möbius framework and its implementation, IEEE Trans. Software Eng. 28
(10) (2002) 956–969.
[13] M.K. Molloy, Performance analysis using stochastic Petri nets, IEEE Trans. Comput. C 31 (1982)
913–917.
[14] A. Movaghar, J.F. Meyer, Performability modeling with stochastic activity networks, in: Proceedings
of 1984 Real-Time Systems Symposium, Austin, TX, USA (1984) 215–224.
[15] A. Movaghar, Stochastic activity networks: a new definition and some properties, Sci. Iran. 8 (4)
(2001) 303–311.
[16] J.R. Rice, Numerical Methods Software and Analysis, Academic Press, 1993.
[17] W.H. Sanders, R.S. Freire, Efficient simulation of hierarchical stochastic activity network models,
Discrete Event Dyn. Syst.: Theor. App. 3 (2/3) (1993) 271–300.
[18] W.H. Sanders, J.F. Meyer, Reduced base model construction methods for stochastic activity
networks, IEEE J. Sel. Area. Comm. 9 (1) (1991) 25–36.
[19] W.H. Sanders, W.D. Obal II, M.A. Qureshi, F.K. Widjanarko, The UltraSAN modeling
environment, Perform. Eval. 24 (1995) 1–33.
[20] W.H. Sanders, J.F. Meyer, Stochastic activity networks: formal definitions and concepts, in: E.
Brinksma, H. Hermanns, J.P. Katoen (Eds.), LNCS 2090. Springer-Verlag, 2001, 315–343.
[21] J.M. Sowder, State space generation techniques in the Möbius modeling framework, M.S. Thesis,
University of Illinois, Urbana-Champaign (1997).
[22] A.J. Stillman, Model composition in the Möbius modeling framework, M.S. Thesis, University of
Illinois, Urbana-Champaign (1999).
[23] M.A. Weiss, Data Structures and Algorithm Analysis in C, Benjamin/Cummings Publishing
Company, New York, 1994.
[24] A.L. Williamson, Discrete event simulation in the Möbius modeling framework, M.S. Thesis,
University of Illinois, Urbana-Champaign (1998).

1 s2.0 S1569190X0500016X Main

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

1 s2.0 S1569190X0500016X Main

Uploaded by

Copyright:

Available Formats

Simulation Modelling Practice and Theory 13 (2005) 505–524

A modelling tool for hierarchical

system-level performance and dependability modelling. Möbius supports model

2. Hierarchical stochastic activity networks

2.1. A new deﬁnition of SANs

Structurally, an activity network is an interconnection of a ﬁnite number of prim-

The stochastic setting of SANs is called stochastic activity networks. A SAN is

2.2. HSAN models

Hierarchical stochastic activity network (HSAN) models provide hierarchies for

to the ﬁve primitives of SANs. A macro activity is an HSAN submodel, which is

2.3. An example of HSAN models

input fusion places output fusion places

(a) IPn OPm

3. SANBuilder modelling tool

In this section, we introduce the software structure and implementation of SAN-

3.1. Software structure of SANBuilder

D.-E. State Space

Fig. 4. Software structure of SANBuilder.

Fig. 5. A view of the user interface of SANBuilder.

6. Model Animator: SANBuilder can animate models. A feature that is also

3.2. Implementation of SANBuilder

In the following subsections, we brieﬂy describe some important algorithms and

3.2.1. Well-deﬁned checker

analyse the corresponding HSAN model. Well-deﬁned checker constructs a DG for

3.2.2. Model compiler

3.2.3. State space generator

Fig. 8. Input gate deﬁnition form.

3.2.4. State Space Handler

Function HashFunction (State)

Fig. 10. The hash function of state space handler.

3.2.5. Model Flattener

Fig. 11. HSAN ﬂattening algorithm.

3.2.6. Model transformer

Fig. 12. The Replicate/Join transformation of model.

3.2.7. Analytic solver

3.2.8. Discrete-event simulator

Fig. 13. Discrete-event simulator of SAN models.

4. Evaluation and comparison

Fig. 14. A ﬂat SAN representation of the Kanban model.

by execution of both tools on an HP workstation. Since, SANBuilder can run only

In this paper, we have brieﬂy introduced hierarchical stochastic activity networks

You might also like