See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/237194854

Retrieving parameterized simulation models from a database

Conference Paper · January 2001

CITATIONS READS
4 147

2 authors, including:

Csaba Attila Boer

TBA B.V.
25 PUBLICATIONS   437 CITATIONS   

SEE PROFILE

All content following this page was uploaded by Csaba Attila Boer on 13 January 2015.

The user has requested enhancement of the downloaded file.

 RETRIEVING PARAMETERIZED
SIMULATION MODELS FROM A DATABASE

Henk de Swaan Arons, Csaba Attila Boer

Erasmus University Rotterdam,

Faculty of Economics, Dept. of Computer Science,
PO Box 1738, 3000 DR Rotterdam, The Netherlands,
{deswaanarons, acboer}@few.eur.nl

ABSTRACT
Discrete-event simulation models can be parameterized and stored in a relational database. Model pa-
rameters may refer to both static (number of modules used) and dynamic (routes) information. In order
to build a new simulation model generally a modeler has to start from scratch, but one could save
much time and effort if such a model or parts of it could be retrieved from a database containing dis-
crete-event simulation models. In this paper a numerical algorithm is proposed aiming to retrieve sim-
ulation models from a database. This method provides a ranked list of models from the database. The
order of the models in this list is based on their resemblance with the model that the modeler has in
mind. A number of experiments is carried out using the Arena simulation package.

KEYWORDS
Discrete-event simulation; storage and retrieval of models; parameterization of simulation models.

1 INTRODUCTION
A modeler starting to build a new simulation model often has the feeling that he is reinventing the
wheel again and again. Maybe the model he is about to design and implement already exists. Maybe
the modeler designed it himself some time ago or maybe some model exists that sufficiently resembles
the model to be designed. All this would make it worthwhile to store existing models in a database for
later use.
Based on an approach proposed in (De Swaan Arons, 1999) and (De Swaan Arons, 2001) a relational
database model has been designed and developed for storage and retrieval of simulation models. The
design of such a relational database is based on the idea that any simulation model can be parameter-
ized (Schriber, 2000). It was discussed how implementation models could be stored in a database and
how a modeler could retrieve a specific model from it. Several experiments with this approach were
successfully performed with a database implemented in Microsoft Access.
Unfortunately, the database will seldom contain an exact match. The number of possible models is too
large for that. However, among the models in the database there will be several ones that resemble the
model the modeler is looking for. In most cases, for a human being it may not really be difficult to de-
cide which of these models are similar to the wanted model, provided that he has the time to browse
them all. He would even be able to select several models that in his opinion best match the model he
specified. However, it is not trivial to formalize the criteria based on which such a decision is made.
These criteria need to be made explicit in order to implement a computer program which is able to
make this type of decision. Although it may be concluded that a knowledge-based approach would
also be promising, in this paper merely a numerical algorithm is discussed.
In this paper the Arena simulation software is taken as a vehicle, but a similar approach could be used
for other simulation languages.
In the following section a very brief introduction of Arena is given. In section 3 the basic elements of
an Arena simulation model are discussed, such as the number of modules, the various parameters and
the route information. Next, in section 4, a numerical algorithm is discussed that will produce a ranked
list of models taken from the database in order of resemblance to the specified model. The implemen-
tation aspects are crucial to the algorithm and therefore these are discussed in section 5. Finally, some
remarks and conclusions are given in section 6.

2 A FEW ARENA CONCEPTS

Arena (Arena, 1995 & 1998) is a graphical simulation environment developed to build and perform
discrete-event simulation models. It is one of the leading simulation packages at this moment.
In Arena the building blocks are called modules which are grouped based on type and level of func-
tionality. For example, there is a Common Template panel containing the most used modules such as
Arrive (generating the arrivals), Server (representing a resource and/or processing location), Inspect (a
Server with decision capabilities), Statistics (for calculating all kinds of statistics), Sequences (used to
describe the route of products along locations together with the processing times) and Simulate (con-
taining some global information of the simulation, such as the number of runs, warming up period,
etc.). There are also lower (more specific) template panels such as the Transfer Template panel, which
provides special modules concerned with the transfer of products (by, among others, transporters and
conveyors). Although complex models generally contain many modules with less functionality, many
quite impressive (sub)models can already be built with the modules provided by the Common Tem-
plate panel. This is the reason why - for the time being - we restrict ourselves to modules taken from
this panel.
So, given these restrictions, in the following a model consists of a number of Arrive, Server, Inspect,
Sequences modules and a Simulate module. Each of these contains more detailed information. For ex-
ample, the input screen of the Arrive module can be used to provide all kind of information concerning
an arrival process such as the name of the arrival process (Enter Data section), the batch size, the inter-
arrival time (Time Between), the maximum number of batches etc. in the Arrival Data section and in-
formation of how products must proceed after leaving the arrival location in the Leave Data section.
Once the various modules have been inserted in the modeling area, they need to be connected indicat-
ing the routes that might be followed by the products. A Simulate module has to be used to provide
general information of the simulation project such as the length of the simulation, the number of repli-
cations, whether or not a warming up period is needed and so on.

3 THE BASIC ELEMENTS OF AN ARENA SIMULATION MODEL

An Arena simulation model can globally be characterized as follows:
− the number of instances of each type of module; examples are the arrival or the server module;
− the parameters values for each module; examples are the processing time and the capacity of a
server module;
− the route information; this information is very important to discrete-event simulation models. It is
relevant for specifying the connections between the simulation modules. An example is the dis-
tance and the speed of products between two modules.
Although these characteristics are specific for each simulation package, fundamentally there is not
much difference between the ways in which different simulation packages represent the data.
If we know all of these characteristics of a simulation model it can easily be constructed. Therefore, in
order to compare two simulation models (the specified model and one taken from the database) we
use these characteristics. The most relevant aspects of a simulation model are the route information
and the parameter values for each module and the comparison will be based mainly on these features.
In order to find out whether the database contains the model that the modeler has in mind we need to
compare it with each of the models in the database.
In the following example, we want to find out if the classical post office simulation model is present in
the database. According to the information the modeler has provided the following can be established:
− there is a location at which customers enter the post office (entrance);
− there is a location at which customers will be served by one or more resources, in this case employ-
ees (the help desk);
− there is a location at which customers leave the post office (exit).
The route information is as follows:
− customers proceed from the entrance to the help desk;
− after being served they proceed from the help desk to the exit.
The modeler specifies some extra parameters such as:
− customers arrive almost every 5 minutes, so for the inter-arrival times we may use an exponential
distribution with mean 5,
− customers are served in 1 to 5 minutes, but it usually requires 3 minutes. In this case we could use
the triangular distribution, with parameters 1, 3 and 5;
− it takes exactly 30 seconds to get from the entrance to the help desk.

Based on this general information provided by the modeler a simulation model outlined in Figure 1
could be specified. To interpret the information given above and to transform it into a specific Arena-
like model may require the support of some knowledge-based system that interprets the modeler's in-
formation. This is, however, not the subject of this paper.

Figure 1. A simple post office simulation model.

It is the task of the numerical algorithm to compare this model with all the models in the database and
try to find the best match.

4 THE ALGORITHM
Once the modeler has specified the model, the numerical algorithm has the task to assign a rank num-
ber to each of the models in the database expressing the resemblance to the specified model. The
smaller the rank number the more the correspondence would exist between the two models.
Suppose that one model in the database contains a submodel that resembles the specified model. This
submodel will never be found when we emphasize on the similarity of models as a whole which is
done by also taking the number of types of modules into account. Although the specified model may
not resemble one of the models in the database, one of these may contain a submodel that is almost the
same as the specified model and may satisfy the modeler’s requirements.

The flow of the algorithm is depicted in Figure 2.

 Figure 2. The flow of the algorithm.

To find a matching submodel we focus on comparing the main characteristics: the route and parameter
information. Route information is very important in modeling discrete-event systems. Thus we need to
focus on analyzing this part of the model as well. The proposed algorithm also compares the specified
model with all models contained in the database resulting in a ‘distance’ for each of these models to
the specified model. In the following we will explain how we calculate the distance between two mod-
els based on route and parameter information.
Suppose that Figure 3 outlines the specified model. Based on this information, for each model in the
database the algorithm attempts to find a subpath between two modules of types A and B, respective-
ly. By doing so, it considers all parameter information relevant to the specified route a.

Figure 3. The specified model.

Again, for each subpath we define a distance function. If the system has analyzed all subpaths, for
each subpath it will return the corresponding distance between the requested route.
The distance for the subpath a in Figure 3 is calculated as follows:

NrOfParamA NrOfParamB
di = ∑ ( )
wn ⋅ p n − p in + ∑ w ⋅ (p
m m − pim ) (1)
n =1 m =1

where:
− NrOfParamA is the number of parameters in module A;
− NrOfParamB is the number of parameters in module B;
− wn is the weight or penalty factor of the nth parameter;
− wm is the weight or penalty factor of the mth parameter;
− pn is the value of the nth parameter of module A in the specified model;
− p m is the value of the mth parameter of module B in the specified model;
− pin is the value of the nth parameter of module A in the ith model in the database;
− pim is the value of the mth parameter module B in the ith model of the database.

At the end the overall distance value (or ranking value) for route and parameter information together
will be the sum of all distance values of subpaths.

NrOfSubPath
Ranking Value = ∑d
i =1
i (2)

Using this approach the algorithm can easily decide how close each model in the database is to the
specified model or which model from the database can offer a submodel that is close to the specified
model.

5 IMPLEMENTATION ASPECTS
In the following we analyze the route information together with module parameter information. First
we determine for each simulation model the subpaths as we introduced earlier. Then we subtract the
information for each subpath of the simulation model according to the following structure.
− M1 → M2 means that the model has a route from module M1 to module M2;
− the parameter information of M1;
− the parameter information of M2.

Subpath: M1 → M2 (from M1 to M2)

M1 parameter information
M2 parameter information

Figure 4. An element of a data structure.

Therefore, a model represented in this way will have as many elements as subpaths. For example, ac-
cording to this structure we represent the subpaths of the post office model in the following way:

Subpath: A → S (Arrive → Server) Subpath: S → D (Server → Depart)

A parameters: Arrival rate = Exp(5) S parameters: Proc. time = TRIA(1,3,5)
Route time = 0.5
S parameters: Proc. time = TRIA(1,3,5)

Figure 5. The representation of the post office model.

The main purpose of using this structure for representing models is to compare some minor parts of
the specified model with the models in the database.
The following algorithm is designed to analyze and compare the specified model with the models in
the database based on their structure. The algorithm calculates a ranking number for each of the mod-
els indicating their distance to the specified model. Thus, at the end, the user can easily choose the
model (submodel) which is closest to the one he specified.

Start Algorithm
Step 1. Take i representing the ith model from the database which is actually pro-
cessed. At the beginning i = 1.
Step 2. Represent the specified model based on the structure introduced above, let
this be M.
Step 3. Take a model from the database and represent it in the same way. Let this
be Ni.
 Step 4. Take j indicating the jth subpath of the specified model (M), let j = 1;
Step 5. For each element of M we execute the following steps:
Step 5.1. Let mj be the current element (subpath) of M.
Step 5.2. Let dj be a measure indicating the similarity (distance) between
mj and the closest element of Ni that fits the endpoints of mj.
The distance has the maximum value if there are no elements in
Ni that fit the endpoints of mj. Give dj the maximum value.
Step 5.3. Take one by one every element from Ni
If the actual element n of Ni has the same type of starting and
ending points as mj, then compare all its parameters to the pa-
rameters of mj, compute the distance based on (1). As a result
we get a distance value indicating the difference between mj and
n. If this distance value is less then dj, then dj will keep
this value. Take note of n as an element we probably will use as
an existing part of the desired model.
Observation: If there are no elements in N with the same ending
point as mj has, then the distance value dj remains the maximum
value.
Step 5.4. Let j = j + 1
Step 5.5. Take the next element of M.
Step 6. The ranking value of the ith model (represented as Ni) is the sum of all dj
of Ni as stated in (2)
Step 7. Let be i = i + 1
Step 8. If there are more models in the database go to Step 3.
End Algorithm

The best match for the specified model is the model with the smallest ranking value.
It is obvious that the weight factors are crucial to the success of this approach and must be determined
carefully, preferably by expert modelers. For example, the route information is generally considered to
be more important than detailed information concerning the batch size or distribution functions.

6 REMARKS AND CONCLUSIONS

Designing and building simulation models is getting easier and easier with the present simulation
software, but it will never be really easy. It is a craft, craftsmen get better tools, but it will stay a time-
consuming job to build a simulation model. That is why it will be worthwhile to use models that al-
ready have been designed, developed and that may be stored in databases. This paper describes an ap-
proach to retrieve and rank Arena models and even submodels in a database based on their resem-
blance to a model specified by the modeler. Some experiments carried out by hand appeared to be suc-
cessful. Therefore, more experiments will be carried out to test the proposed algorithm. More than 20
Arena models (among others taken from (Arena, 1998)) which have already been stored in an MS Ac-
cess database will be used for testing purposes. The algorithm presented in this paper is being imple-
mented and some preliminary results will be presented at the conference.

REFERENCES
De Swaan Arons H. & Boer C.A. (2001). Storage and Retrieval of Simulation Models, submitted for publication
in the Journal of Simulation Practice and Theory (Elsevier).
De Swaan Arons, H. (1999). Knowledge-Based Modeling of Discrete-Event Simulation Systems. In: Proceedings
of the 1999 Winter Simulation Conference.
Kelton, W.D., R.P. Sadowski & Sadowski. D.A. (1998). Simulation with Arena. Boston: McGraw-Hill.
Pegden, C.D, Shannon R.E. & Sadowski. R.P. (1995). Introduction to Simulation Using SIMAN. New York:
McGraw-Hill Inc.
Schriber T.J., Brunner D.T. (2000). Inside discrete-event simulation software: how it works and why it matters.
In: Proceedings of the 2000 Winter Simulation Conference.

View publication stats