GRAPHICAL OBJECT ORIENTED SIMULATION WITH SIMIO
Patrick Kirchhof, Nicolas G. Meseth
University of Osnabrueck
email: Patrick.Kirchhof@uos.de, Nicolas.Meseth@uos.de
KEYWORDS
Simio, Object-oriented, Manufacturing
ABSTRACT
While object orientation has long become a standard in
software development, it has not been fully embraced in
simulation modeling. There are many simulation frame-
works which offer object oriented modeling based on a
programming language but no sophisticated graphical
tool. This paper describes Simio, a new simulation soft-
ware, which simplifies model building by fully integrat-
ing an object-oriented modeling approach. Simulation
models are built from objects, which are stored in ob-
ject libraries and can be reused in multiple projects.
Models themselves can be instantiated as objects in
other models. A comprehensive set of standard ob-
jects is contained in Simio, while more refined ones
can be developed completely graphically, and without
the need for programming. Following the concept of
object-orientation, objects are created through compo-
sition of existing objects, sub-classing existing objects,
and overriding their behavior, or by building new objects
from scratch. This paper is to provide a comprehensive
overview of the Simio simulation software with a focus
on its underlying object-oriented paradigm.
INTRODUCTION
Although the roots of object orientation can be traced
back to simulation (Dahl and Nygaard 1966), the
paradigm is not widely applied in today’s simulation
software (Robinson 2005; p. 624). In the field of sim-
ulation of manufacturing systems process-orientation is
the predominant modeling paradigm of commercial sim-
ulation systems. Tools such as Rockwell Arena or En-
terprise Dynamics are well known examples belonging
to this category. Process-oriented modeling is consid-
ered intuitive and effective in practice, but there are also
drawbacks. Modularity and reusability are limited and
maintenance is difficult due to the dependencies within
a model. Minor changes to the simulated system can
prove to be very difficult to implement because changes
have to be made at many different places in the sim-
ulation model (Edwin C. Valentin and Alexander Ver-
braeck 2005; p. 655). Others argue that the greatest
limitation of the procedural modeling paradigm is the
lack of extensibility (Joines and Roberts 1999; p. 133).
Object-oriented modeling constitutes a compelling alter-
native, because it is well suited for simulation and in-
troduces many benefits. Although today many vendors
of industrial simulation software claim their system pro-
vides object-oriented modeling capabilities, this is only
partly correct. No product known to the authors fully
supports an entirely graphical and object-oriented mod-
eling approach without the need for programming. Most
of today’s tools contain a set of generic objects that can
be used for model composition. The modeler can cus-
tomize these base objects and enhance their function-
ality by developing code in a programming language.
Thus, the use of these tools is very limited unless the
user is capable of programming in the supported lan-
guage. Well known examples are Extend, which uses
a procedural language similar to C, or Anylogic, which
integrates with Java (Edwin C. Valentin and Alexander
Verbraeck 2007; p. 788). PlantSimulation (former em-
Plant) uses SimTalk, a procedural language designed for
programming simulation applications (Bangsow 2008;
p. 89). Another group of tools such as Simul8 can
be used completely graphically without the necessity of
programming, but is limited to a fixed set of modeling
objects.
This paper’s intention is to give an overview of the
Simio1 simulation software, a new system which fully
supports object-oriented modeling in a purely graphical
manner without the need for programming2 . The most
interesting features are pointed out, and it is shown
how the modeler benefits from the underlying object-
orientation. Therefore, the following section explains
how object-orientation is applied in Simio. Afterwards,
three different ways to extend Simio’s functionality are
described. The paper concludes with a summary of the
most important aspects of the object-oriented modeling
approach and its implications for the modeler.
1 Simio TM is a commercial product of Simio LLC.
2 The term programming in this work is defined as typing code
in a programming language such as C# or Java. Creating a pro-
gram by clicking and arranging symbols is not considered pro-
gramming in this context.
OBJECT ORIENTATION IN SIMIO
Simio Object Paradigm
In Simio, simulation models are built through the com-
position of objects and the definition of their behav-
ior and interaction. Objects of any complexity can be
stored and categorized in libraries. A set of objects with
basic functionality is contained in the standard library
included in Simio. It comes with a pre-defined set of
basic objects, which includes a source, sink, server, com-
biner, separator, as well as different types of links. These
basic building blocks suffice to build simple models, but
in most real life cases they must be extended.
Custom objects are stored in user defined libraries,
which can be shared and reused across multiple projects.
According to the equivalence principle there is no differ-
ence between an object and a model. Every model is by
definition also an object and can thus be instantiated
into another model (C. Dennis Pegden 2008; p. 230).
This is highly efficient because every model can be hi-
erarchically used as a building block in a higher level of
models.
It is important to note the difference between object li-
braries and libraries of process templates known from
other commercial process-oriented tools such as Arena.
Template libraries in process-oriented simulation tools
contain templates and not objects. Templates are hier-
archically constructed from basic building blocks, which
are a graphical representation of a piece of functionality
in a process-oriented simulation language. A typical ex-
ample would be a template for a complex workstation,
which is made of several building blocks such as resource,
queue, delay etc. Therefore templates are not more than
the logical organization of elementary constructs of the
underlying simulation or general purpose programming
language into a more abstract logical construct, gener-
ally combined with a visual parametrization interface.
In contrast, objects in Simio are true objects, which in-
herit attributes and behavior from their parent classes,
allow their behavior to be modified (overridden) and ex-
tended, encapsulate their internal structure, and know
abstraction and polymorphism. Objects own process
definitions that specify their behavior and can be viewed
as the equivalent of a method in object-oriented pro-
gramming. Process definitions are built fully graphical
from a comprehensive set of modeling elements called
steps. The processes of any standard library object are
also modeled using steps and can therefore be viewed
and edited.
Objects and therefore models can have properties and
states. A property can be thought of as a named param-
eter of an object instance and is usually constant dur-
ing a simulation run. States are output responses that
change throughout the execution of the object logic.
An object can define its own set of events and use those
events to trigger processes. Objects are designed follow-
ing the event-listener pattern and can evaluate events
fired by other objects. This is useful to control the in-
teraction between objects.
Building models in Simio is done using the graphical
modeling interface, which divides an object (or model)
into seven different views. While in the facility win-
dow the user composes the model from existing objects,
he can specify the resulting object’s appearance in the
external window. In the process, data, and interface
window, the user defines the object’s behavior. More-
over, the dashboard and results window allow the user
to watch the model’s response during the simulation
and define and analyze corresponding simulation exper-
iments.
It should be noted that no programming is required and
that the skills needed to build custom objects via inher-
itance are purely modeling skills and not programming
skills (C. Dennis Pegden 2008; p. 231). Object libraries
in Simio and template libraries share the same idea of
user-defined libraries, but differ with regard to the mod-
eling paradigm they are designed for. How objects can
be defined and customized is explained in greater detail
below.
Object Types
Any object in Simio is a subclass of either one of the
types displayed in figure 1. These classes provide basic
functionality, which serves as a starting point for the
development of more refined objects. They only define
generic behavior to provide a very general basis for mod-
eling individual object definitions. Objects in the stan-
dard library are also descendants of one of these basic
types.
Figure 1: Class diagram showing the basic object types
contained in Simio.
Every object is derived from the Intelligent Object class.
Intelligent Objects have the optional ability to be seized,
released or follow a schedule. They are abstract and
cannot be instantiated.
Fixed objects have a fixed location and are used to
model stationary things in a system like machines in a
manufacturing system, a plant in a supply chain model
or a counter in an airport.
Objects of the Agent class are intended for agent-based
modeling approaches in which a large number of in-
dependently acting agents form the system’s behavior.
Agents can move freely through continuous space with-
out the need of a specified network of paths. They can
detect other objects and react to their actions. In the
current version of Simio, Agents are not yet fully func-
tional and cannot be used.
Entity objects are derived from the Agent type and rep-
resent non-stationary objects that have the ability to
move along specified paths and nodes. Paths and nodes
can be grouped into networks in order to limit the scope
of Entities. They can enter and exit other stationary ob-
ject types (Fixed, Node, Link ) and can be transported.
The Transporter class is derived from the Entity class
and can therefore also move along a specified network.
Transporters add the capability to load, carry, and un-
load other objects. By default they follow the shortest
path to their destination but other modes of behavior
such as following a fixed route are also regarded.
Node objects are derived from the Fixed object class and
are intended to represent vertices in a network, i.e. the
starting or ending point of a Link object, or the entry or
exit points of a Fixed object. At a Node, Entity objects
may be loaded or unloaded by a Transporter. Nodes can
be equipped with a crossing logic which can be executed
when being visited.
Links represent the edges in a network. Links have a
length and can be split into sections for their graphical
representation. Each Link must have a starting and an
ending point defined by Node objects.
Projects and Object Libraries
In Simio, simulation models are part of a Project, which
is saved in a project file and contains all the elements
of the model. A project comprises at least one model.
By distributing a single project file, an entire simulation
project can be shared between users.
Objects modeled in Simio can be reused in other
projects by loading the respective object into a differ-
ent project as a library. The models contained in the
loaded project file appear as a user defined library be-
low the standard library and can be used for modeling
alike. Like models of the standard library they can also
be extended and sub-classed. Models can be password
protected so that they can be parameterized, used, and
distributed, but their inner working is hidden and can-
not be changed.
Both, the basic objects and the objects in the standard
library described above are domain neutral and can be
used in a wide variety of application areas (C. Dennis
Pegden 2008; p. 233). Domain specific extensions to
generic simulation packages provide a modeling aid in a
certain domain and most vendors offer specialized mod-
eling constructs (Edwin C. Valentin and Alexander Ver-
braeck 2005; p. 654). Simio does not include domain
specific extensions, but it is easy to develop and share
custom objects and libraries. Thus, domain specific li-
braries can be created from user defined objects and
distributed as a project file.
The past section has given an overview of how the
object-paradigm is applied in Simio. As stated earlier,
in most scenarios the standard library’s objects are not
sufficient. Simio offers a number of ways in which it’s
functionality can be enhanced and they are subject of
the next section.
EXTENSIBILITY
The extensibility of a simulation tool is a critical factor
for its acceptance in practice. Simio offers three general
ways to implement functionality that is not provided
by the standard library. The following sections describe
those three ways and give examples for each.
Creating Custom Objects
For simple models with little specific logic, the stan-
dard library described above is a good start. By nature,
though, simulation models tend to require very specific
and sometimes complex logic to model real world situ-
ations. Simio offers a simple way to extend the library
without having to write a line of code.
Consider for example the server object from the stan-
dard library. It has a set of two nodes, one input and
one output node, both having their own queue. Imagine
this server should have a second output node, because
it should serve two types of customers (entities) sepa-
rately, and each type should leave the server through a
separate exit. The steps required to implement this are
straightforward and do not demand any programming
skills.
The starting point for creating the new server model
MyServer is the server object from the standard library.
By dragging it to the project library, a new object class
is created as subclass of the server. Subclassing has
the benefit that all parts of the parent class are auto-
matically inherited. Those include all states, properties,
elements, and processes, and only the extended func-
tionality must be added.
To add the second node and to make it visible to the
user, it must be added to the object’s external view.
This can be done by selecting a node from the ribbon bar
and placing it wherever it should appear. Preferably, it
should be next to the existing output node. After adding
a new node to the external view it must be connected
to the object’s internal logic.
so called elements. Elements are static parts that have
a certain, in most cases general, functionality that they
provide the object with. The station element, for exam-
ple, represents a physical place where entities can reside.
The server from the standard library has three station
elements to represent the different places an entity can
be within the server. The first station is used to model
the input buffer where all arriving entities wait to be
processed. The second contains an entity for the time it
is processed. After the entity is finished processing, it
enters the output station, which represents the server’s
output buffer. If the new output node should have its
own output buffer, a new station in the process view
must be added and connected to the output node.
Connecting a station to a node in this context means
adding the right steps that send (transfer) an entity from
the station to the node. The right place to add this step
in case of the server object is the OnEnteredProcessing
process. This process takes care of an entity that was
sent to the processing station and makes it wait in a
delay step until the processing time has elapsed. Af-
terwards, the process transfers the entity to the output
station. Now that MyServer has two output stations,
the process must be enhanced to decide to which sta-
tion to send an entity based on some criteria (e.g. the
value of an entity’s state). This can be done by drag-
ging in a decide step from the library and setting the
condition accordingly. The second branch of the decide
step must now be equipped with a transfer step to send
the entity to the alternative station.
Finally, when the entity enters the new station, it
should immediately be sent to the external output node
through which it leaves the object (if the node has suf-
ficient capacity left; otherwise the entity waits in the
station until the node’s capacity becomes available).
Therefore, a process that is triggered whenever an en-
tity enters the station must be created. Because the
steps are the same as for the first output buffer, one can
simply copy the OnEnteredOutputBuffer process and re-
name it.
To subsume, the necessary steps to extend the server
to distinguish two types of entities are the following, of
which cam all be done graphically:
1. Create a model MyServer subclassing the server
model (drag & drop)
2. Add a node in the external window (drag & drop)
3. Add a station in the process window (drag & drop)
4. Add decide and transfer step to OnEnteredProcess-
ing (drag & drop)
5. Create new process OnEnteredOutputBuffer2 and
add transfer step (drag & drop)
This simple example was to show how the user can
extend Simio without any programming. Nonetheless,
Simio offers a powerful application programming inter-
face (API), which allows flexibility that goes beyond cre-
ating custom objects.
Customs Elements and Steps
The first way to programmatically extend Simio is to
create custom elements and steps. Simio ships with a
class library that contains interfaces which can be im-
plemented to define a new element or step. Because
Simio and its API are based on the .NET framework,
steps and elements can be programmed in any .NET
language. Therefore, Simio is not platform independent
and can only be used under Windows systems.
Elements
To define a custom element one must implement the
IElement interface. It specifies a single method
Initialize(), which is called at the beginning of a
simulation run. Here the programmer specifies what
the element does, and has access to the simulation con-
text via an object which is passed in the method as an
argument. One possible application would be to sched-
ule events in the event calendar before the simulation
begins.
Elements can be viewed as complex objects that belong
to a model. Therby elements can fulfill very different
functionality. The station element, for example, is a
place where entities can sit within a model, and therefore
represents a physical location. In contrast, the file ele-
ment enables an object to read data from a file, and thus
represents a connector to the outside world of Simio.
Connectors to different data sources are good examples
for custom elements. To enable the model to query data
from a SQL Server database, the user could implement
a new element and make the connection string config-
urable as a property of the element.
Steps
Elements are most useful when combined with accord-
ing steps that in some way reference the element. To
create a new step, the user must implement the IStep
interface and put the desired functionality in its only
method Execute(). The method is run when the step
is executed as part of a process. To continue the exam-
ple of the SQL server connector, a useful step would be
one that executes a SQL query statement against the
connection specified by the connector element.
The possibility to define new elements and steps is very
powerful. It enables the modeler not only to extend
Simio within the tool itself, but to implement logic that
interacts with the outside world. A database connec-
tor is a good example. Other useful elements could be
ones that query web-services on the internet or retrieve
data from a structured file format such as XML. It is
also possible to implement standardized connectors for
widely used ERP and PPS systems, such as SAP or Mi-
crosoft Dynamics NAV.
Design Add-Ins
The second way Simio offers to extend the software pro-
gramatically is by writing design add-ins. An add-in
is a compiled .NET library (.dll). Add-in libraries are
automatically displayed in the ribbon menu when they
are put in the designated folder, and can be activated
by clicking on the corresponding icon. For Simio to rec-
ognize a valid design add-in, the class must implement
the provided interface IDesignAddIn. A design add-in
has a name, description, and a custom icon property, all
of which are set by the programmer. More important,
though, is the interface’s sole method Execute(); this
is the method that is invoked when the user activates
the add-in from the Simio software menu.
Within this method, the programmer has access to the
currently open facility window and its model through
the API provided by the Simio software. The program-
mer is offered methods to add objects to the model and
place them by specifying their coordinates, delete ob-
jects from the model, and to set the model’s properties.
Thus, one has the same possibilities as a modeler who
creates a model using the Simio GUI.
The option to create models programmatically makes
it possible to dynamically generate models from exter-
nal data sources. The data-driven simulation approach,
where information about objects in the model is re-
trieved from different applications that already host this
information, can thus be implemented with Simio. A
good example is to automatically read the bill of mate-
rials from an ERP system instead of inserting it manu-
ally.
Another application for custom design add-ins is to load
models stored in a different file format. For this purpose,
the add-in fulfills the task of translating the foreign for-
mat into a Simio model. This way, models from other
simulation tools such as Arena could be transformed into
a Simio model automatically. For companies using other
tools, who would like to migrate to Simio, but do not
want to re-implement their existing models, this could
be an option.
As described in this section, Simio offers three different
levels to achieve extensibility. Thereby, creating custom
library objects is even possible for non-programmers.
This is an enhancement that could widen the range of
users that can successfully apply simulation. In most
cases, the driver of a simulation study is one who un-
derstands the business processes, but is not familiar with
programming. Simio has the potential to close this gap.
CONCLUSION
This paper has introduced the new object-oriented sim-
ulation software Simio. Simio is the first truly object-
oriented simulation software, which embraces all bene-
fits of the object-oriented paradigm in an entirely graph-
ical manner. Most importantly, Simio allows the mod-
eler to easily create custom objects to meet highly spe-
cific requirements with no need for programming, tak-
ing advantage of inheritance. Nonetheless, the option
to extend Simio programmatically is also available and
twofold: custom steps and elements (the atomic units of
functionality) as well as so called design add-ins (appli-
cation plug-ins with full access to the software) release
the modeler of any restrictions of what can be modeled.
Within in the scope of this paper, the author’s tried to
give an overview of the benefits that derive from true
object-orientation in a simulation tool; possible draw-
backs such as a potential loss of performance, were not
commented on. As Simio is a very novel tool, further
investigations must be made to fully evaluate the tool
with more aspects regarded.
REFERENCES
Bangsow S., 2008. Fertigungssimulationen mit Plant
Simulation und SimTalk: Anwendung und Program-
mierung mit Beispielen und Lösungen. Hanser,
München. ISBN 9783446414907.
C. Dennis Pegden, 2008. Introduction to Simio. In
S.J. Mason (Ed.), 2008 Winter Simuation Confer-
ence: Miami, Florida, USA, December 7 - 10, 2008.
IEEE, Piscataway, NJ. ISBN 978-1-4244-2708-6, 229–
235.
Dahl O.J. and Nygaard K., 1966. SIMULA - an
ALGOL-Based Simulation Language. Communica-
tions of the ACM, 9, no. 9, 671–678.
Edwin C. Valentin and Alexander Verbraeck, 2005. Re-
quirements for domain specific discrete event simula-
tion environments. In M.E. Kuhl (Ed.), Proceedings
of the 2005 Winter Simulation Conference: Orlando,
Florida, USA, December 4 - 7, 2005. IEEE, Orlando,
Fl. ISBN 0-7803-9520-4, 654–663.
Edwin C. Valentin and Alexander Verbraeck, 2007. Do-
main specific model constructs in commercial simu-
lation environments. In S.G. Henderson (Ed.), Pro-
ceedings of the 2007 Winter Simulation Conference:
Washington, DC, USA, December 9 - 12, 2007,.
IEEE, New York, NY. ISBN 1-424-41306-0, 785–792.
Joines J.A. and Roberts S.D., 1999. Simulation in an
object-oriented world. In P.A. Farrington; H.B. Nem-
bhard; D.T. Sturrock; and G.W. Evans (Eds.), Pro-
ceedings of the 1999 Winter Simulation Conference.
Winter Simulation Conference.
Robinson S., 2005. Discrete-event simulation: from the
pioneers to the present, what next? Journal of the
Operational Research Society, 56, no. 6, 619–629.