Simulation tools

Numerous computer programs can now be used for generic simulations. Each of these tools follows a different model-construction paradigm.
The major characteristics of certain simulation programs are described in the next four sections. The first section is devoted to classical OR simulation tools, which are based on the concept of process and/or push/pull rules. The second section describes tools that use artificial intelligence methods. The third section reviews certain programming libraries that can be used in model construction. Finally, the fourth section reviews the major features of the different programs and tools.

OR tools

OR encompasses a wide range of tools for specifying, constructing and running models.

These tools use different paradigms to represent the real world. The discrete-event paradigm includes classical languages such as GPSS/H® and Slam II® (Pritsker 1986). These tools have features similar to those of Simprocess® and Arena® and follow the process-interaction paradigm or the event-scheduling paradigm.

In fact, Simprocess is based on the description of graphical processes that describe the model’s behavior.

The following are the main characteristics of Simprocess:

1. It is a hierarchical, event-oriented simulation tool.
2. It can generate cost reports. 
3. Its simulations are based on activities, not machines. 
4. It uses templates. 
5. It uses additional logic (if, then, else). 
6. It considers and completely defines resources and can use fractional resources. 
7. Due to its hierarchical structure, each process can have an operation named process that defines a complete process, which enables the hierarchical definition of complete processes.

This can be done in a similar way in Arena®, which is very similar to Simprocess® (Figure 1).

 

 Figure 1. Simprocess and Arena(r) models.

This hierarchical process-definition tool can use templates, generate complete reports, etc.

An Arena’s important feature is that its models can be very similar to the real world (using DLLs inside simulation models and Visual Basic for Applications® allowing the use of specialized code). This makes Arena a powerful simulation package, because if the process-interaction paradigm cannot represent reality, all of the particularities can be programmed in VB or with an external DLL.

A DLL can also recover some information from the simulation model and send it, via TCP/IP, to a receiver that acquires and processes it[1]. This can be useful for constructing training systems (Fonseca, Casanovas et al. 2004). Figure 3 shows an example of an Arena model.

These packages use the process-interaction paradigm to describe the models. Other software programs, however, do not follow this paradigm, such as Witness®. This software follows a special paradigm (Witness 1998) (Figure 2). In fact, this software constructs processes using push/pull rules in the different model elements.

Figure 2. Witness model.

This methodology justifies the need for elements (which represent the real machines of the system) in simulation models, whereas Simprocess, Arena, GPSS and others only have operations. This is useful for representing more realistic models. However, if the Witness elements cannot fully represent the complexity of the system’s elements, problems can arise. To overcome this obstacle, Witness includes process definitions inside the entities. In this case, elements do not represent machines from the real world but rather operations, like in Arena and Simprocess.

Witness allows if…then…else rules to be defined in its push/pull rules[2], which allows entity routes to be modified. The different entities and resources[3] in Witness have attributes, but the model cannot easily modify these attributes, due to the limitations of this simulation language.

Artificial intelligence simulation software

Artificial intelligence (AI) simulation models are usually based on multi-agent systems (MAS). One of the most appealing approaches is Swarm, a set of libraries created by the Santa Fe Institute[4], which is designed to support complex simulation models.

Figure 3. Swarm logo.

The nucleus of a Swarm-based simulation is the model itself. Unlike other methodologies, the model has no external structures (in an event-scheduling simulation engine, the nucleus basically consists of a simulation loop and an event list, which are not a part of the model). In a simple case, the model is a structure named Swarm, occupied by a set of agents and a chronology of the activities that the agents will perform. Each agent is an object, created by the Swarm libraries and specialized through an inheritance mechanism.

In Swarm, the simulation-model construction process has a common set of tasks, but since each set of agents “lives” in a different environment, this is not a universal process.

In a Swarm simulation, the environment can also be modeled using an agent. The simulation kernel can therefore be reduced to the Swarm environment. For instance, in a simulation representing the evolution of a certain predator and its prey, the agent that represents the environment can also represent the growth of the vegetables that the prey eats.

Figure 4. Swarm model structure example.

Obviously, this agent has a special status in the simulation model, but in the program parameters this agent is treated just like any other.

In fact, in the general case, the environment used by the agents consists of the agents themselves. This means that no specific agents are created to describe the behavior of the model. Some agents have more influence over the model than others, but the system manages all agents equally.

Once the user has defined the agents and their relationships, all of the agents are added to the Swarm system. The user writes a chronograph of activities for each agent and defines how time is simulated in the system. The set of actions is performed by the agent in the specified order.

These chronographs are created by using the instances of the structures of the Swarm library to fill the object/message structures. Once the chronograph is set, the Swarm model is ready to run.

Agent name:	Description:
Agent2D	Represents agents in a 2D world.
DirectAgent2D	Moves in a specified direction.
User2D	Follows other agents.
Marcus2D	Two behaviors: Incubation: like a DirectAgent2D. Resisting influence. When the agent has consumed all of its energy resisting, it enters an incubation period.
SocialAgent2D	Has strong relationships.
Alex2D	Follows the state of other agents. Adds observations to its state.
Glen2D	Implements the following algorithm: Find a target agent. Tell it to do something. If the target agent does not perform the action, follow it and tell it to perform another task.

Table1. Swarm agents.

Table 1 details the most important Swarm agents and Figure 4.9 shows a Swarm model structure.

A Swarm model is of no interest if no data can be acquired by running it. According to the Swarm philosophy, a system has a set of agents that can acquire data: the observers.
 

Figure 5. Swarm observer.

For instance, an observer agent (Figure 6) can see the number of prey and show the evolution of the population in real time using graphics. Other agents can analyze the spatial distribution of the predators.

Observer agents are Swarm agents like all the others, but their chronographs focus on acquiring data from the model. In fact, Swarm is a set of protocols that can describe the behavior of objects (objects named agents that experiment with space and time).

Another interesting system is Framsticks (Komosinski and Szymon 2000). This system tests the evolutionary capacity of creatures designed by the modeler. The environmental conditions are usually similar to earth conditions. The system works in a three-dimensional environment and allows the physical structures of the creatures to relate to the environment.

 

Name: Owohyw Ris Genotype: rrCCii(rXX[| T :379.564],r(rXX[@ 0 :-3.182][| G :1.749],X[| 0 :-135.911,G :0.878]),X) Average horizontal speed: 0.002

 Figure 6. Framsticks agent.

Organisms are described by genomes and a neuronal network communicates with the environment. This network also processes the signals that come from the environment and implements behavior.

The creatures have energy needs and the notion of energy efficiency. As a result, they develop survival mechanisms: they passively take energy from the environment and, more aggressively, they kill other creatures to take their energy. The simulator allows the user to see the creatures’ evolution. Specifically, it allows the user to study the evolution of the creatures’ movement mechanisms and their ability to find energy, avoid predators and catch prey. From the definition of the initial creature characteristics, complex behaviors can emerge – behaviors that can be analyzed and studied. Also its representation determines their movement capacity and hence their survival effectiveness.

 

 Figure 7. Two Framsticks  structures.

These two systems create a global behavior (emergence). Swarm works with multiple intelligent agents that have defined behavior. From their actions, an emergent behavior appears. These agents usually do not have equivalence in the empirical real world and are usually too abstract to make social sense (Werner 2000). This sometimes makes the task of redefining agent behavior impossible (because it is difficult to completely define the behavior of some individuals). Framsticks works with creatures that implement a network. Framsticks worlds usually do not have equivalence in the real world. Its utility lies in the ability to analyze the characteristics of the different elements.

Other systems are MASON, RePast, AgentSheets. MASON is a single-process discrete-event simulation core and visualization toolkit written in Java, designed to be flexible enough to be used for a wide range of simulations, but with a special emphasis on “swarm” simulations of a very many (up to millions of) agents. The system is open-source and free, and is a joint effort of George Mason University’s Computer Science Department and the George Mason University Center for Social Complexity. MASON may be downloaded at http://cs.gmu.edu/eclab/projects/mason/ (Luke, Cioffi-Revilla et Alt. 2004).

Repast are in alpha stage of development, while AgentSheets is commercial software that allows the definition of different agents that interact together.

Figure 8. AgentSheets environment.

In the previous figure, the AgentSheets environment is shown

Simulation programming libraries and infrastructures

From the DEVS formalism, we can define simulation languages by using the specification paradigm to directly construct the model.

DEVSJAVA uses Java to construct simulation models following the DEVS formalism. This system is based on the DEVS formalism and does not have a specific scope; hence, we can model any kind of system. For more information about DEVSJAVA, see Zeigler and Sarjoughian (2003).

Another standard infrastructure, High Level Architecture (HLA), can create simulations made up of different software components.

Complex simulations usually involve a combination of various elements that have different objectives and structures. As a result, these components must often be modified in order to use them in the model. Hence, it is sometimes easier to implement a new system. In fact, traditional simulation models are not reusable or interoperable in different scenarios and applications.

Interoperability is related to reusability. Interoperability means that reusable components can be combined without modifying the code.

Interoperability includes the ability to combine different simulation components, sometimes with operations that take place in real time. This approach involves considering how simulation components interact in a traditional simulation program. Rather than developing a simple program running on an isolated computer, we need to develop a set of programs that can run together on multiple computers of different types that interact with each other in a real-time environment. For instance, to create a training model for the nuclear industry, different simulation models need to be developed. Some can represent the movement of the different elements in the factory; others can represent real-time elements that the user frequently modifies while the model is running. A standard must therefore be developed to interconnect these elements. To solve this problem, an area of the DoD called the Defense Modeling and Simulation Office (DMSO) developed HLA. Its main purpose was to support the needs of Army-related projects. It is now widely used in many other areas. The DoD shares HLA information inside and outside the US, helps new users evaluate and implement simulation infrastructures and reduces complexity and costs with tools and documentation. Applications outside the DoD include traffic and industrial simulations.

In HLA, a simulation model is a hierarchy of components with an increasing level of aggregation. The lower level may contain the model of a system component, a mathematical model, a queue model or a rule-based model. The model is implemented using software that produces the simulation. Simulations carried out as a part of an HLA simulation model are called federates. In HLA, simulations that include a number of federates are called federations. Various instances of a specific federate can exist, which means that HLA simulation models are modular. Federations can include much more than just simulations, such as human interfaces to assist the interaction with machines in real time, data analyzers, etc.

Summary

The following table (Table 2) presents the major features of the simulation models described above and others.

The user column summarizes the programming knowledge needed to use the system. Level 3 indicates high programming knowledge, while Level 0 indicates that the user does not need any programming knowledge.

The Source column shows if the source is available for its modification without restrictions.

The interface columns shows the way the user interact with the application.

Name	Language	Interface		Goal	Source	Version	User
Framsticks	N/A	Software	MAS		No	V 2.11	1
Swarm	Objective C, Java	Libraries	MAS		Yes		3
Arena	Visual Basic	Software	Discrete event simulation		No	V 8	0-3
Witness	Proprietary language	Software	Discrete event simulation		No	V 2006	0-2
LeanSim	C++	Software, Libraries	Discrete event simulation,  training systems construction		Yes	V 1.0	0-3
SLAM	Proprietary language	Text editor	Discrete event simulation		No	V 4.2	1
GPSS/H	GPSS	Text editor	Discrete event simulation		No	V 4.3.5	1
Vensim PLE	N/A	Software	Continuous simulation		No	V 5.5d	0
MASON	Java	Libraries	MAS		Yes	V 11	3
Repast	Java	Libraries	MAS		Yes	Alpha	3
AgentSheets	N/A	Software	MAS		No	V 2.5	0

 Table 2: Analyzed simulation systems.

---

[1] An application of this type was developed in the LCFIB to analyze, in real time, a set of systems that control the AGV fleet of a major food company. A communication library made it possible for the model (constructed with Arena) to receive external information through TCP/IP. This communication allows the overall system to be debugged without the problems that would be created by a real experiment.

[2] The TO rule of a Witness element can define the direction of an entity. With this rule, we can define if…then…else rules using all elements of the model (“if atr=1 then PUSH machine(1) else PUSH machine(2) endif”). With these rules, the entity path can easily be modified using entity attributes or model attributes.

[3] In Witness, resources are the elements needed to perform an operation in a specific element (machine).

[4] Santa Fe Institute, 1399 Hyde Park Road, Santa Fe, New Mexico, 87501, USA.

[5] Computing Laboratory of the Barcelona School of Informatics.

References:

Fonseca i Casas, Pau; Casanovas, Josep; Montero, Jordi. 2004d. LeanSim® virtual reality distributed simulation suite. Proceedings of MSO 2004.

Komosinski, Maciej; Ulatowski, Szymon. 2000. Framsticks. In: Kybernetes: The International Journal of Systems & Cybernetics, Vol. 29, No. 9/10.

Pritsker, A. 1986. Introduction to simulation and SLAM II. Halsted Press.

Werner, Roland. 2000. Structure, flow, change: Towards a social systems simulation methodology. Social Systems Simulation Group. San Diego State University. Witness. 1998. User’s Manual, Version 9. Lanner Group.

Zeigler, Bernard P.; Sarjoughian, Hessam S. 2003. Introduction to DEVS modeling and simulation with Java: Developing component-based simulation models. Resources http://www.acims.arizona.edu/EDUCATION/education.shtml (accessed 17 January 2005).