SIMULATION USING BUILDING BLOCKS
Edwin Valentin
Alexander Verbraeck
Delft University of Technology
Faculty of Technology, Policy and Management
Systems Engineering Group
P.O. Box 5015, 2600 GA Delft, The Netherlands
ABSTRACT
In this paper we sketch how the use of building blocks
provides added value for improving the effectiveness of
simulation studies. Research conducted by other groups
regarding building blocks is in our view not yet sufficient
for successful application in the field of discrete event
simulation. In addition the sets of building blocks provided by simulation vendors do not provide the added
value we expect. To improve the effectiveness of simulation studies we identified a set of requirements for the
architecture of building blocks. It was possible to implement this architecture in existing simulation environments. In a case for modeling business processes in
banking environments we used a set of building blocks
that has been designed according to the mentioned requirements, to illustrate the improved effectiveness.
1 INTRODUCTION
Contrary to what we have been expecting for a long time,
discrete event simulation is an instrument which is not
used on a day-to-day basis by decision makers, even for
data-intensive decisions that require quantitative analysis.
We see the (perceived) low effectiveness of simulation
studies as the major reason for the lack of use of simulation as a problem solving instrument. This low effectiveness is in our opinion caused by several reasons. Examples are that the insight provided by the first models leads
to new questions of decision makers which the models
cannot answer, that the modeled situation changes before
the simulation study could be finished, that simulation
experts and decision makers speak and think in different
‘languages’ and that the simulation expert lacks background knowledge of a domain to correctly solve the
problem using simulation.
Looking at the construction of discrete event simulation models, we notice that this process has a highly repetitive character. Especially when developing models in
the same domain or for the same organization, similar
modeling constructs are being used over and over again. It
seems very logical to structure and package these repetitive processes, and make them available for the modeler
for repeated use. Using the standard simulation statements, it can take quite long to create a complex model,
but with larger, pre-constructed blocks, the modeler
should be able to create the model in less time. Our hypothesis is that the concept of these pre-constructed
blocks will also improve the effectiveness of simulation
studies for discrete events simulation models. To stay
independent of the software engineering concept of ‘components’, we will use the more neutral term ‘building
blocks’ in this paper. Building blocks are very close to
objects in object orientation, but they possess improved
functionality for aggregation, and much attention is paid
to fully specifying the interfaces of the building blocks.
In the second section of this paper we will show how
building blocks are described in literature and how they
are currently implemented in some of the popular discrete
event simulation tools. We notice that building blocks are
used, but we observe all kinds of different architectures.
In the third section of the paper we evaluate the different
architectures used in the current tools and we deduce a set
of requirements for an overall architecture of discrete
event simulation building blocks. Section four shows that
this new architecture satisfies the identified requirements.
Finally we will illustrate our architecture for building
blocks using a case study for business process redesign in
a financial environment.
2 BUILDING BLOCKS IN LITERATURE AND
PRACTICE
As mentioned before, the concept of building blocks is not
completely new. Several architectures for simulation
building blocks can be found both in literature and in current simulation tools.
2.1
Building blocks in literature
Analogous to the development of component based software (Allen & Frost, 1998; Szyperski, 2001; Herzum &
Sims, 2000; Heinemann & Councill, 2000), simulation
model builders are using components to construct their
models. When constructing a model of a complex system
that in reality consist of several components from different vendors, e.g. a part of a factory with a number of ma-
chines, it would be ideal to construct a simulation model
of that factory from simulation components that have a
one-to-one match with the machines on the factory floor
(Sarjoughian & Cellier, 2001). Ideally, these components
can be downloaded from the web-sites of the machine
vendors and can be plugged into any simulation model
because of standardized interfaces. At the moment, however, these standard interfaces and “open” simulation environments hardly exist, and it will take several years
more before even part of this vision is realized. Even
worse, we need to think about the architectures of these
building blocks that would allow such advanced use.
Fishwick (1998) and Pegden et al. (2001) provide first
ideas for these interfaces and functionality of components,
but the existing commercially available simulation tools
do not yet allow the use of these types of components.
The research performed by Kasputis and Ng (2000) is an
example of possibilities for building blocks with the current technologies. They illustrate the possibility of reaching a higher effectiveness in their simulation studies by
using a set of components for the simulation models
which they developed for models of the US Navy. However, their solution is not easy to generalize, because these
components are fixed within one organization, and require
simulation software of the US Navy.
2.2
Building blocks in practice
In practice we see that a lot of the current discrete event
simulation software tools provide some kind of building
blocks. Building blocks can be applied on three different
aggregation levels. At the bottom level, we see generic,
domain independent building blocks like a queue and a
resource, actually wrapping the concepts of the simulation
language in a user-friendly way. At the second level,
building blocks are used as part of the simulation tool
focussing on a special domain. In addition, some tools
offer the possibility for users to develop or extend building blocks according to their own, very specific, needs.
Examples of sets of building blocks for a special domain are the material handling building block sets of
AutoMod, the Contact Center and Factory Analyzer libraries of Arena and the MedModel library of Promodel.
These tools and packages are all described in Peters et al.
(2001). The user construction of building blocks for a
special domain is for instance available within the simulation tools Arena, eM-plant and Extend.
3 REQUIREMENTS FOR THE ARCHITECTURE
OF BUILDING BLOCKS
The requirements for simulation building block libraries
come from two different sources. The first set of requirements is mainly based on literature and is aimed at supporting to improve the effectiveness of simulation studies.
The second set of requirements follows from experiences
with the architecture of available simulation libraries,
which we tested in several projects (Verbraeck et al.
1998; Versteegt & Verbraeck, 2001; Saanen, 2001; Verbraeck & Valentin, 2001).
3.1
Requirements based on literature
The first set of requirements for the architecture of simulation building blocks is based on an analysis that looks at
the possible contribution of building blocks to the improvement of the effectiveness of a simulation study. The
steps for a simulation study of Banks (1998) have been
used as a basis to look for possible improvements.
REQ 1:Usable within several simulation studies
The development of building blocks is a time-consuming
task. No matter how many experience a simulation analyst
has, it would be very uncommon to get the full pay-back
of the extra investment for creating building in one simulation study. Therefore, the building blocks should be applicable in more than one simulation study.
REQ 2: Applicable in current simulation tools
The available commercial simulation tools have taken
years to develop and to reach a high-level of user friendliness. Even though better founded concepts like the
DEVS-framework (Zeigler et al., 2000) and pure object
oriented simulation (Balci et al., 1997) are available, the
average simulation expert is not able to use these frameworks. He/she is more convenient using one of the currently available commercial simulation tools (Swain,
2001).
REQ 3: Support easy model development
The development of a simulation model is more than just
the coding of the model. If possible, the building blocks
should also ease the phases of conceptualization of the
system, before the model construction can start, and give
support with the gathering of data during the model construction phase (Banks, 1998).
REQ 4: Resulting models should be understandable for
problem owner
Simulation models are not just meant to generate numbers, they should also provide insight in the system. We
see the necessary insight on two different levels. One
level is that the structure of the model is understandable
for the problem owner, i.e. that he/she recognizes the
processing of the simulation model. The other level is that
the working of the system can be assessed, e.g. through a
visualization the problem owner understands. In addition,
the quantitative output always remains important. The
user will almost always use the output in the decision
making, but not before credibility has been assured
through understanding of the working of the model.
REQ 5: Resulting models should be ready for VV&A
After the step model construction, simulation studies are
followed by verification and validation before the simulation run can be performed (Banks, 1998). The models we
construct using building blocks should enable us to do
easy and fast verification and validation of the model. The
accreditation is already part of requirement 4.
REQ 6: Easy adaptation
Systems that are modeled in a simulation study, usually
evolve over time. This means that when the simulation
models are used for answering questions over a prolonged
period, the model builder should be able to adapt the
models to the system changes with minimal effort. The
building blocks should be capable of handling these
changes, and if possible easing the change process.
REQ 7: Maintainable and extendable
In addition to easy changing the models built with building blocks, the building blocks themselves should also be
easily adaptable. Even though a set of building blocks
might seem perfect for the first study, next projects might
require different, or more often, extended functionality of
the building blocks. The building block architecture
should support easy changes or extensions in the building
blocks.
3.2
Requirements based on experiences with current
simulation tools
When we have a closer look at libraries in existing simulation tools, we observed some positive and negative
characteristics. The experiences with these characteristics
in different projects triggered us in defining the following
requirements for our own architecture:
REQ 8: Domain specific blocks with a manageable size
In several of the existing building blocks, we see a limited
set of very powerful building blocks with lots of features
that can be switched on or off. Usually these building
blocks have extensive user interfaces. This indicates that
the building blocks contain functionality that is not required every time, which means overhead in the building
blocks, overhead for the user, and problems with maintenance. Still we want to be able to have building blocks
that show some domain specificity and that are not as
general and small as a queue or a resource.
REQ 9: Not closed, but also not completely open
Building blocks in the tool Arena are compiled and you
cannot have a look inside. The building blocks of eMplant are completely open and you can change each attribute value and call every internal function. Both options
have their disadvantages, so a trade-off needs to be made.
REQ 10: Flow of objects and method calls
The flow oriented simulation tools like Arena, Witness
and AutoMod are clear and easy to use for visualization.
The object oriented tools like Extend and eM-plant handle
a lot by method calls, which makes them powerful for
complex coding. A trade off needs to be made between
the object oriented advantages of using methods and the
flow oriented advantages of clarity and animation.
4 A NEW ARCHITECTURE FOR SIMULATION
BUILDING BLOCKS
In the previous section we defined the requirements for an
architecture for simulation building blocks from a technical standpoint (based on available simulation tools) and a
process-oriented standpoint, based on the steps in a simulation study. In this section we will first of all explain how
we face the technical requirements and by that explain
how the process-oriented requirements are met as well.
4.1
Relationships between building blocks
So far we just spoke about individual building blocks. In
practice, a consistent library of building blocks is usually
needed to carry out a simulation project. One of the questions for the architecture is which mechanisms are important for providing the relationship between building
blocks. In one of our projects for simulating passenger
movements in airport terminals, we assumed that inheritance would be a major relationship between different
types of building blocks. Inheritance would decrease the
efforts in maintenance and provide the model builder with
a clear structured set of building blocks. In this project,
we defined a large set of building blocks, that included
check-in counters, gates, souvenir shops, and security
checks, for modeling the infrastructure of the airport. In
our abstract view, we noticed an inheritance structure to
handle all these building blocks, see Figure 1 for a small
subset using UML (Rumbaugh et al, 1999).
GenericArea
<abstract>
0..n
CompoundArea
SingleArea
CheckInCompoundArea
GateCompoundArea
Gate2CompoundArea
Figure 1:
WalkArea
Walk2DArea
LeisureArea
ConveyorArea
ShopArea
SittingArea
HandlingArea
HandlingGroupArea
HandlingStateArea
HandlingScheduleArea
Inheritance structure of building blocks
While performing simulation studies with this inheritance structure, we found out that we more or less
satisfied requirements 1 to 6, but maintenance and extendibility (REQ 7) were extremely hard. Because of the
many different characteristics in the infrastructure building blocks, the ‘pure’ inheritance tree we started with,
provided more and more problems over time. Parts needed
to be duplicated between building blocks far away in the
tree, and in other cases abstract artifacts that were not
meant to be included in the models had to be entered high
in the inheritance tree. This made it harder for the model
builders to understand the models as well. As a result we
had a closer look at the concepts behind the areas.
What we observed over and over again was that
smaller repetitive parts existed within our building blocks,
that were not meant to be handled as a single part of a
simulation model. In fact these were smaller building
blocks, that were not meant to be visible to the model
builder, but only to the building block developer. These
so-called building block elements are the finer structure
that the building block developer uses to create, extend,
and adapt the model building blocks.
4.2
Private versus public
To handle the difficult requirement that a building block
should be as open as possible for reasons of clarity, yet as
closed as possible to avoid that the user damages the
building block (REQ 9), we see clear interfacing as a good
solution, combined with “hiding” of information. The
open / closed issue is mostly an problem because of accessing information or methods a user is not allowed to
use or change. By defining specific interfaces around a
building block, this problem is solved. Secondly, information within the building block should be split up in
private and public information. In the current simulation
tools some technical opportunities are already available to
do this, such as creating a special sub-frame in eM-plant
and using a unique-hidden operand within Arena. Thirdly,
the public information and functions of a building block
should be reachable using the most basic calls provided
within the simulation language, so the building blocks can
easily cooperate with the statements of the used simulation environment, which is not hard to achieve according
to our experiences (shown in the example in section 5).
4.3
4.4
Domain specific sets of building blocks
We see a set of model building blocks, consisting of a
larger set of building block elements as a tool that will
support in simulation studies within a certain problem
domain. However, within each problem domain one can
always identify one or more studies that cannot be solved
in an effective way using the proposed set. As a result we
limit ourselves not only to a problem domain, but within
that domain to a set of issues we can solve.
To improve the use of the set of model building
blocks, we take three things into account:
• Model building blocks are representations of items
one can clearly identify within a problem domain
(helps to satisfy REQ 1).
• The user interface – both the terms in the forms to fill
in and the animation provided – contains the terminology of the problem domain of the problem owner
(satisfies REQ 4).
• Development of new model building blocks using
(new) building block elements will lead to the ability
to solve new issues within the identified problem domain (solves REQ 6).
In the simulation studies for airport terminal modeling, we
saw that the aggregation mentioned in section 4.1 could
be used over and over again, to define larger aggregations,
which in the end became very project specific. All the
concepts mentioned above helped to achieve this goal.
One example for the airport building blocks a project specific library for terminal evacuation, which could easily be
built on top of the terminal specific building blocks,
sometimes by replacing the control building block elements by “evacuation specific” controls.
Insta nce s in sim ula tion m od e l
(p roje ct sp e cific)
Proje ct sp ecific
b uild ing b locks
D om a in sp e cific
b u ild in g b locks
Flow and objects
It is our experience in many discrete event simulation
projects that problem owners think in terms of flows
(REQ 10). They notice a passenger flow through an airport, a document flow through an organization, or flowing
envelopes or packages through a mail sorter. In order to
stay close to this view, we usually support this flow in the
building block structure, but we use object oriented
mechanisms for control. Especially in the control, more
algorithmic features are useful, which are best provided
by object oriented mechanisms. The building block elements for control can then be used as element in the flow
supporting model building blocks. By using this combination, the models visualize the flow that the problem
owner can easily recognize (REQ 4).
B uild ing b lo ck e le m e n ts
(g e ne ric an d d om a in sp e cific)
level of aggregation
Both the building blocks and the building block elements possess a very well specified and clear interface to
the other building blocks or building block elements.
What we found out is that composition or aggregation
might be a more important structuring mechanism than
inheritance.
When we implemented this structure for the airport
terminals, we were also able to maintain our building
blocks. We took this even a step further and defined inheritance trees of building block elements, but not anymore for the model building blocks. Because we knew
what types of building block elements together form a
model building block, we defined an interface for the
model building block, that supports the user in configuring the model building block by choosing the building
block elements of which it is built up. This possibility not
only improved the easy model construction (REQ 3), but
also enabled models to be more easily recognized by the
problem owner, thanks to the detailed knowledge available in the building block elements (REQ 4).
Sim ula tion conce p ts a nd
sta te m en ts p ro vid e d b y th e
sim ula tion lan g ua g e
Figure 2:
Inheritance structure of building blocks
As a result, we found out that the architecture of model
building blocks we developed, also supported the usability
within several simulation studies (REQ 1). Our libraries
were implemented in current simulation tools, so we also
satisfied REQ 2.
4.5
Remaining advantages of the architecture
Projects carried out with these architectures of simulation
building blocks showed that some of the features that we
chose provide even more advantages than we thought on
beforehand.
One of the advantages of the clear one-to-one representation of the object system in the simulation building
blocks is that models can be built by people less experienced in the use of a simulation environment, because
they are just copying components they observe in their
own system into the simulation model. There is, of course,
also a danger attached to this: a model is a reduction of
the depicted system, and anyone not aware of that can
deduce invalid conclusions from running the model. Another advantage that surfaced during our studies is that
data gathering – usually one of the most cumbersome
tasks of a simulation study – is much easier, because the
information needed from the modeled system is defined
by the information to be entered in the pre-defined and
carefully designed (user) interfaces of the different model
building blocks. All observations show that we succeed to
support easy model development (REQ 3).
REQ 5 looks like a tough requirement. In the studies
we carried out, we found that VV&A was greatly helped
by the fact that each building block is usually extensively
tested before handing it over to model builders. Therefore,
modeling errors have not to be searched in the detailed
simulation code, but rather in the entered data and the
higher-level model structure. Furthermore, the building
block interfaces are designed to show problem domain
terminology, so expert validation and accreditation are
easier than projects where models have been built from
low-level simulation building blocks that usually show
terms understandable for simulation experts, not domain
experts. A final advantage is that the building block usually include collection of statistics for the most common
performance indicators in the domain. This saves time in
providing the client with the first results.
5 CASE STUDY INTERNATIONAL BANKING
Ayad and Sol (2002) have identified several alternatives
for business models for banks. As part of the research,
they investigated two different international payment
systems in two different countries, which are part of the
same banking organization. The main question they
wanted to answer was: “Will our new business model
provide the cost savings we expect?”. Several variables
that influence the performance indicators for this question
have been identified: location of databases, accessibility
of information, allocation of tasks to countries or a central
organization, personnel allocation to perform tasks and
order of executing tasks.
To be able to give quantitative answers to these questions, a simulation model had to be constructed. Because
of the required model flexibility, the high number of tasks
and processes and the further use of the model in later
stages of the research, the choice was made to use building blocks. A second reason was that we expected to use
these types of building blocks in more business process
related (research) projects. After preliminary research, we
defined four high-level types of building blocks:
• Actors who perform tasks, but do not know anything
about the rest of the process.
• Databases that store information about the customer
and about payments / documents / generic items.
• Task-allocators that assign tasks to be performed to
actors who have the right competencies to perform
the required tasks.
• Process steps which are all kinds of actions performed on the payment/document/item, like “Claim
actor” , “Perform task”, “Retrieve from database” and
“Check consistency with database”.
These building blocks have been implemented in the
Arena simulation language with several variants for each
building block. Figure 3 shows the conceptual model for
the “Capture Order Process”, one of the many processes
in the banking study. Figure 4 shows a screen dump of the
model part of the same process, that was created using the
building blocks.
Arrive of payment
Select actor to
perform "Input
payment"
Select actor to
perform "check
input"
Claim actor for
task "Input
payment"
Claim actor for
task "check
input"
Perform task
"Input payment"
Check information of
the 'payment
Country A' database
Add information to
the 'payment
Country A'
database
Release actor of
task "Input
payment"
Figure 3:
Perform task
"check input"
WRONG
Adjust information
of database
'payment
Country A'
CORRECT
Release actor of
task "Input
payment"
Conceptual example bank process
The building blocks were created in Arena, and as the
implementation shows, construction within Arena was
successful. The model building blocks are very close to
the standard building blocks that Arena provides. The
main difference is the way actors are handled. In Arena it
is determined immediately which instance of a “resource”
should be used for a process. In these models we use a
task allocator to uncouple the document flow and the actors. In this way we succeed in fulfilling the requirement
about flow and control (REQ 10).
Figure 4:
Implementation of “Capture Order Process”
6 CONCLUSIONS
In this paper we identified the major success factors for
applying building blocks in discrete event simulation
studies. These were aggregation rather than inheritance,
separation between building block elements and building
blocks, using well defined interfaces, hiding of private
variables and attributes, showing the flow in the building
blocks, but controlling in a more OO and algorithmic way,
and creating a hierarchy for domain specificity. The resulting architecture can be implemented on top of existing
commercially available simulation tools, and has been
successfully applied in different domains for a number of
simulation studies. Further research will focus on testing
the development and use of building blocks by simulation
experts who are not yet familiar with this architecture.
ACKNOWLEDGEMENTS
The authors acknowledge the support of the BETADE
research program for funding, and want to thank Nadia
Ayad for providing the material for the banking case.
REFERENCES
P. Allen, S. Frost. Component-Based Development for Enterprise Systems. Cambridge University Press, 1998.
N. Ayad; H.G. Sol. “Development of New Geographically Distributed Business Models for Global Transactions”. In: R.H.
Sprague, J F Nunamaker (eds.); Proceedings of the 35th
Hawaiian International Conference on Systems Sciences,
IEEE, 2002, CD-ROM, 8 p.
O. Balci; A.I. Bertelrud; C.M. Esterbrook; R.E. Nance. “The
Visual Simulation Environment Technology Transfer” In:
S.Andradottir, K.J.Healy, D.H.Withers and B.L. Nelson
(eds). Proceedings of the 1997 Winter Simulation Conference. IEEE, 1997, p.1323-1329.
J. Banks. Handbook of simulation; Principles, Methodology,
Advances, Applications and practice. John Wiley & Sons,
1998.
G.T. Heinemann, W.T. Councill. Component-Based Software
Engineering. Addison-Wesley, 2001.
P. Herzum, O. Sims. Business Component Factory. OMG, 2000.
S. Kasputis and H.C. Ng. “Composable simulations” In: J.A.
Joines et al.(Eds.), Proceedings of the 2000 Winter Simulation Conference, p.1577-1584.
C.D. Pegden; V. Kachitvichyanukul; J.O. Hendrikson; R.G.
Ingallsand B.W. Schmeiser. “Simulation environment for the
new millennium (panel)” In: B.A. Peters et al. (Eds.) Proceedings of the 2001 Winter Simulation Conference, IEEE,
2001. p.541-547.
B.A. Peters; J.S. Smith; D.J.Medeiros; M.W.Rohrer. Proceedings of the 2001 Winter Simulation Conference, IEEE, 2001.
J. Rumbaugh, I. Jacobson, G. Booch. The Unified Modeling
Language Reference Manual. Addison-Wesley, 1999.
Y.A. Saanen. “Designing Software for Robotised Terminals” In:
Proceedings AAPA Conference, 2001.
H.S. Sarjoughian; F.E. Cellier (Eds.). Discrete Event Modeling
and Simulation Technologies: A Tapestry of Systems and AIBased Theories and Methodologies. Springer-Verlag, 2001.
J.J. Swain, “Power Tools for Visualization and Decision Making”. MS/OR Today, February 2001, p. 52-63.
C. Szyperski. Component Software, 2nd edition. Addison
Wesley, 2001.
A. Verbraeck; E.C. Valentin. “The use of building blocks to
enhance flexibility and maintainability of simulation models
and simulation libraries” In: N. Giambiasi, C. Frydman
(Eds.), Proceedings ESS’2001 – 13th European Simulation
Symposium 2001, p. 973-979.
A. Verbraeck; Y.A. Saanen; E.C. Valentin. “Logistic Modeling
and Simulation of Automated Guided Vehicles”. In: A. Bargiela, E. Kerckhoffs (Eds.) Simulation Technology: Science
and Art. 10th European Simulation Symposium and Exhibition. 1998. p. 514-519
C. Versteegt; A. Verbraeck. “Concepts for safety control for the
concurrent use of infrastructure in intelligent transport systems using AGVs”, In: Proceedings 8th World Congress on
Intelligent Transport Systems, 2001, CD-ROM, 8 p.
B.P. Zeigler; H. Praehofer, T.G. Kim. Theory of Modeling and
Simulation : Integrating Discrete Event and Continuous
Complex Dynamic Systems. Academic Press, 2000.
AUTHOR BIOGRAPHIES
Alexander Verbraeck is an associate professor in the
Systems Engineering Group of the Faculty of Technology,
Policy and Management of Delft University of
Technology, and a part-time full professor in supply chain
management at the R.H. Smith School of Business of the
University of Maryland. He is a specialist in discrete
event simulation for real-time control of complex
transportation systems and for modeling business systems.
His current research focus is on development of generic
libraries of object oriented simulation building blocks in
C++ and Java. Contact information:
<[email protected]>
<www.tbm.tudelft.nl/webstaf/alexandv>
Edwin Valentin is a researcher in the Systems
Engineering Group of the Faculty of Technology, Policy
and Management of Delft University of Technology. His
specialty is the development of domain-dependent generic
discrete-event simulation libraries. Edwin participates in
the BETADE research program on developing new
concepts for designing and using building blocks in
software engineering, simulation, and organizational
modeling. Contact information:
<[email protected]>
<www.tbm.tudelft.nl/webstaf/edwinv>