RinSim is an extensible logistics simulator with support for (de)centralized algorithms for pickup and delivery problems and AGV routing. The simulator focuses on simplicity and consistency making it ideal for performing scientific simulations. Further, software quality is a priority resulting in an ever improving test suite and documentation.

RinSim uses Maven for managing its dependencies. RinSim can be added to your Maven project by including the following in your pom file, where x and y represents the preferred version number. More detailed instructions are available.

<dependency>
	<groupId>com.github.rinde</groupId>
	<artifactId>rinsim-core</artifactId>
	<version>3.x.y</version>
</dependency>

Other modules can be added similarly:

<dependency>
	<groupId>com.github.rinde</groupId>
	<artifactId>rinsim-ui</artifactId>
	<version>3.x.y</version>
</dependency>
<dependency>
	<groupId>com.github.rinde</groupId>
	<artifactId>rinsim-experiment</artifactId>
	<version>3.x.y</version>
</dependency>

For more detailed instructions on how create a Maven project in Eclipse and add RinSim as a dependency see the instructions. For release notes of the latest release click here.

Once the simulator is installed, you are ready to explore the simulator. It is recommended to start by running and studying the examples. When using Maven in Eclipse, the RinSim JavaDocs are automatically made available making 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 or ask them on StackOverflow using the RinSim tag.

RinSim is developed at AgentWise in the iMinds-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 used in both research and education. Several publications rely on RinSim for their experiments and RinSim is used in a course on multi-agent systems as a testbed for students.

RinSim is open source under the Apache License Version 2.0. From version 3.0.0 RinSim uses semantic versioning, this means that if you are using features introduced in version X.Y.Z it is safe to upgrade to any version greater than X.Y.Z but smaller than X+1.0.0.

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. 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 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. 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.

The GUI can be configured using the View class. The GUI can be customized using Renderers.

• View: 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.