RinSim is an extensible MAS (Multi-Agent System) simulator. The simulator focusses on simplicity and consistency which makes it ideal for performing scientific simulations. Further, there is huge focus on software quality which results in an ever improving test suite and JavaDoc comments. RinSim supports pluggable models which allow to extend the scope of the simulator. Out of the box, RinSim currently focusses on MAS for PDP (Pickup and Delivery Problems). You can easily extend RinSim by introducing your own custom models.

Click the image above to view a demonstration movie of the simulator.

The RinSim simulator uses Maven for managing its dependencies. We recommend the Maven plugin for Eclipse. Once this is installed and a new Maven project is created, RinSim can be added by including the following in your pom file.

<dependency>
	<groupId>com.github.rinde</groupId>
	<artifactId>rinsim-core</artifactId>
	<version>2.1.0</version>
</dependency>

Other modules can be added similarly:

<dependency>
	<groupId>com.github.rinde</groupId>
	<artifactId>rinsim-ui</artifactId>
	<version>2.1.0</version>
</dependency>
<dependency>
	<groupId>com.github.rinde</groupId>
	<artifactId>rinsim-problem</artifactId>
	<version>2.1.0</version>
</dependency>

Once the simulator is installed, you are ready to explore the simulator. It is recommended to start by running and studying the simple example. Note, that when using Maven in Eclipse, the RinSim JavaDocs are automatically made available which makes exploration of the code much easier. The remainder of this page gives a high level overview of the simulator. If you have questions or like to stay up to date about RinSim you can subscribe to the mailing list at this page.

RinSim is being developed at AgentWise in the DistriNet group at the Department of Computer Science, KU Leuven, Belgium. The lead developer is Rinde van Lon. Valuable contributions were made by Bartosz Michalik and Robrecht Haesevoets.

RinSim is being used in both research and education. It is used in several publications on multi-agent systems and it is used in a MAS course as a testbed for students.

This section gives a brief overview of the most important elements of the simulator. For a deeper understanding you can have a look at the examples, the source code, and the tests.

In RinSim terminology, the parts of the simulation that define the problem and environment are called models, the parts of the simulation that solve the problem (i.e. the solution, the collective adaptive system) are called agents. The design of RinSim allows for easy use and recombination of models to configure a simulation problem. When the problem is configured, the programmer can focus on solving the actual problem by designing a collective adaptive system without having to worry about accidentally violating simulation consistency. The following figure shows a high-level component diagram:

Actions that agents can take are considered to be part of the problem not the solution, e.g. a vehicle that can pickup things or can communicate with other vehicles. Actions define the problem space in which a good solution has to be found.

The Simulator class is the heart of RinSim. Its main concern is to simulate time. This is done in a discrete manner. Time is divided in ticks of a certain length, which is chosen upon initializing the simulator (see examples and code).

Of course time on its own is not so useful, so we can register objects in the simulator, such as objects implementing the TickListener interface. These objects will listen to the internal clock of the simulator. You can also register other objects, as we will see in a moment.

Once started, the simulator will start to tick, and with each tick it will call all registered tickListeners, in turn, to perform some actions within the length of the time step (as illustrated here). Time consistency is enforced by the TimeLapse objects. Each TickListener receives a single TimeLapse object every tick, the time in this object can be 'spent' on actions. This spending can be done only once, as such an agent can not violate the time consistency in the simulator. For example, calling RoadModel#moveTo(..) several times will have no effect.

As you can see there is also an afterTick, but we'll ignore this for now.

Apart from simulating time, the simulator has little functionality on its own. All additional functionality (such as movement, communication, etc.) that is required by your simulation, should be delegated to models. These models can be easily plugged (or registered) in the simulator.

Out of the box, RinSim comes with three basic models: RoadModel, CommunicationModel and PDPModel. When this is not enough, it is easy to define your own custom model.

• RoadModel: simulates a physical road structure. The RoadModel allows to place and move objects (RoadUsers) on roads. It comes in two flavors:
  • GraphRoadModel: A graph based road model, objects can only move on edges of the graph. Several maps are currently available here.
  • PlaneRoadModel: A plane based road model, objects can move anywhere within the plane.
• PDPModel: the pickup-and-delivery model. The model collaborates with the RoadModel, the models comes with three different _RoadUser_s: Vehicle, Parcel and Depot. Vehicles can transport Parcels from and to Depots. The model enforces capacity constraints, time windows and position consistency.
• CommunicationModel: simulates simple message-based communication between objects implementing the CommunicationUser interface. It supports both direct messaging and broadcasting. It can also take distance, communication radius, and communication reliability into account. Messages between agents are send asynchronously (as illustrated here).

The GUI is realized by the SimulationViewer, which relies on a set of Renderers.

• SimulationViewer: is responsible for rendering the simulator. Specific renderers can be added for each model, for the provided models there exist default renderers.

• Renderer: is responsible for rendering one model (or more). Examples are the RoadUserRenderer to do basic rendering of objects in the RoadModel, or MessagingLayerRenderer to visualize messages between agents. When introducing new models you can create new custom renderers for these models.

Simulation entities are entities that are the actual objects in our simulation, such as agents, trucks, and packages. They can implement the TickListener interface and/or other interfaces to use additional models. Once registered in the simulator, the simulator will make sure they receive ticks (if required) and are registered in all required models.