Simulation Modelling Practice and Theory 116 (2022) 102430

Contents lists available at ScienceDirect

Simulation Modelling Practice and Theory

journal homepage: www.elsevier.com/locate/simpat

A simulation and control framework for AGV based transport

systems
Joaquín López a ,∗, Eduardo Zalama b,c , Jaime Gómez-García-Bermejo b,c
a System Engineering and Automation Department, EEI, University of Vigo, 36310 Vigo, Spain
b ITAP, University of Valladolid, Paseo del Cauce s/n 47011 Valladolid, Spain
c
Centro Tecnológico Cartif, Valladolid, Spain

ARTICLE INFO ABSTRACT

Keywords: This paper presents a flexible framework to simulate transport systems based on automated
Automated Guided Vehicle (AGV) guided vehicles (AGVs). The framework used to perform the simulation also serves to implement
Simulation the different policies and algorithms in the global control system.
Robotics frameworks
For all mobile platforms, regardless of their application, there is great interest in having
Fleet sizing
the model in a simulation environment. However, transport systems tend to be complex, with
many vehicles needing to execute many tasks at the same time. Furthermore, when analyzing
the global control system, there is no need for a detailed simulation of each AGV. That is why
most researchers do not use modular control frameworks, such as the robotic operating system
(ROS), to simulate the global system. Instead, they use specific simulation tools that require
the definition of the simulated scheduling, routing and allocation policies in specific languages
or models. As an alternative, our approach extends the global control framework by replacing
the on-board control modules and devices by an event simulator that models the AGV behavior
statistically. With this approach, the control policies and methods are only implemented once;
they are used and tested in simulation and later in the final system. Also, tasks are easily model
and verified using a Petri Net-based model. This model is directly implemented in the executive
module that coordinates all the other modules in the framework.
This simulation framework has been used during the implementation of several projects
which included an autonomous logistics system for hospitals, a warehouse internal transport
system using autonomous forklifts, and a factory logistics transport system using tugger trains.
Examples of how the simulation can help in the design of some parameters such as fleet size
and scheduling policies are also included in the paper.

1. Introduction

The increasing demand for online orders, accelerated by the COVID-19 pandemic, has brought logistics and transportation the
forefront. The need for efficiency and flexibility throughout the supply chain, including warehouses, has motivated the research
for improving logistics strategies [1]. Automated guided vehicles (AGV) are widely used in this context as a part of a reliable and
flexible internal transport system. The automation of logistics vehicles can also bring other benefits, due to reductions in costs and
operating times [2–4]. Logistics automation is not restricted to factories or warehouses and can be applied in a wide variety of
buildings. Autonomous vehicles can carry raw materials and finished goods in productive centers such as factories or workshops,
and many types of items such as meals, laundry or medicines in hospitals, care homes, or hotels.

∗ Corresponding author.
E-mail addresses: joaquin@uvigo.es (J. López), ezalama@eii.uva.es (E. Zalama), jaigom@eii.uva.es (J. Gómez-García-Bermejo).

https://doi.org/10.1016/j.simpat.2021.102430
Received 27 May 2021; Received in revised form 30 September 2021; Accepted 27 October 2021
Available online 13 December 2021
1569-190X/© 2021 The Author(s). Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license
(http://creativecommons.org/licenses/by-nc-nd/4.0/).
J. López et al. Simulation Modelling Practice and Theory 116 (2022) 102430

Many types of vehicles have been automated according to the items they have to transport which include order pickers, stacker
trucks, forklift trucks, reach truck lifts, low-lift pallet trucks, and tugger trains. Besides the vehicles, an ad hoc planning and control
system together with some infrastructure changes might be required. Since this could lead to substantial investment, it is prudent
to identify possible constraints by performing an analysis of the vehicle’s capability and impact on efficiency. This analysis can be
performed by simulation that can include identification of other issues such as deadlocks, traffic rules, congestion, efficiency and
delays in the delivery of the items. Furthermore, simulation can help to test parameters that influence the optimization of the system
such as traffic routes and vehicle numbers.
Conventional approaches used in simulating AGV-based transportation systems can be divided into two types [5]: Analytical
techniques and simulation techniques. The analytical models define the tasks and traffic of the system as mathematical equations
and can optimize the system. However, for complex systems that include a lot of variables and parameters (tasks, AGVs, a wide
diversity of routes, building devices and so on) like the ones included in this research, the analytical models can become difficult
to construct. Moreover, to obtain these analytical models it is necessary to make many simplifications and assumptions about the
system. The more assumptions and simplifications are considered, the more likely it is for the system to become unreal.
In the mobile robots field, most of the modular control frameworks are also used for simulation by replacing the hardware
drivers modules with a simulator module. This is the case for the robotic operating system ROS [6], the Carnegie Mellon robot
navigation toolkit (carmen) [7] or the robotics integrated development environment (RIDE) [8] that can replace the hardware
drivers modules with a simulator module such as Gazebo [9] or the virtual robot experimentation platform V_REP [10]. The simulator
models the robot’s behavior and interactions with the working environment to estimate the state (position) and sensor readings. The
communication between those modules is based on a message publish/subscribe mechanism. Since the simulator module produces
and subscribes the same messages as the hardware driver modules, the control modules do not need to be changed.
However, when simulating a complex transportation system to estimate the number of AGVs and evaluate different routing and
planning policies, there is no need for a detailed simulation of each AGV. Furthermore, with so many tasks and AGVs, the detailed
simulation could be unfeasible. Instead, analytical techniques [11] or ad-hoc traffic simulation tools such as ARENA [12] are widely
used. That means reprogramming or modeling the traffic and planning policies in specific simulation languages. Instead, this paper
proposes a two-level simulation system using the same control framework. The low-level simulation system aims to test the on-board
control systems and uses traditional mobile robot simulators (in our case Gazebo). The high-level simulation system aims to analyze
and estimate parameters of the global control system and uses the same control framework, replacing the on-board control modules
with an event simulation module.
Therefore, the main contribution of this paper is a flexible simulation framework for AGV transport systems based on the control
framework. The control, planning and scheduling modules are the same in both frameworks providing several benefits:

• There is no need for a specific simulation model of the control, planning and scheduling mechanisms.
• It is a modular and flexible framework where all the extensive modules used in ROS can be directly integrated and used in
simulation.
• Tasks are easily modeled and verified using a Petri Net-based model.
• Sampled data such as task arrivals can be easily included into the simulation process.
• Using a high-level light simulator allows faster simulation times and increases the workload of the system. That is especially
interesting when evaluating worst-case traffic conditions for long periods of time.

This paper is organized as follows. The next section introduces the work related to this research. The global description of the
transportation system is presented in Section 3. The control framework and the simulation framework are described in Sections 4
and 5 respectively. Finally, a results section includes some examples of the parameters that can be estimated using the simulation
framework.

2. Previous work

Simulation has been extensively applied in the design of autonomous transport systems at two different levels. The lowest level
focuses on the navigation capabilities of the vehicles (on-board control) while the highest level focuses on the global control to
optimize routing, allocation and scheduling policies.
For all the mobile platforms, regardless of their application, there is a great interest in having the model in a simulation
environment. One benefit of doing so is that it can be used by many people at the same time, and a number of studies and experiments
can be conducted with no need for the physical robots. For that purpose, we need to simulate rigid body dynamics considering
variables such as inertia, mass, friction, velocity, etc. Fortunately, rapid progress in computer graphics has led to a number of
physics engines, mainly motivated by the animated movie and computer games industries, but also of great benefit to robotics.
Some of the most popular open-source 3D simulators for robotics are V_REP [10], ARGoS [13], Simbad [14], and Gazebo [9].
V_REP includes by default the Bullet, ODE, Vortex and Newton physics engines. Gazebo uses the ODE physics engine. The Unified
System for Automation and Robot Simulation (USARSim) [15] is based on the Unreal Tournament game engine. ARGoS, on the
other hand, uses 2D and 3D custom physics engines. Most of these simulators can be programmed in C or C++ although some of
them can also be programmed in Phyton (e.g., Gazebo, Webots) or Java (e.g., Simbad, USARSim).
There are several studies comparing different simulators. For example, the survey published in [16] compares Gazebo, V_REP
and ARGoS. The study presented in [17] includes commercial robotic simulation software (Easy-Rob and Rob.Tbx.) and open-source
simulators (Gazebo, Webots, Simbad, USARSim, MRDS and MisionLab). This research uses Gazebo in most of the projects, although

2
J. López et al. Simulation Modelling Practice and Theory 116 (2022) 102430

some use V-REP. The decision to use them was mainly based on the models that they already included and because both of them
are easily integrated in ROS.
The goal for the highest-level simulation is to find a set of parameters to meet user requirements and maximize system
performance [18]. Those parameters include: the number of AGVs that will affect system performance; the task dispatching rules
that set the criteria to assign the transportation requests to AGVs; the charging policy that decides when to recharge the batteries to
make sure the robot does not run out of buttery in the middle of a task; the idle policy to choose what to do when a robot finishes
a task and there is no new task (go to a rest area, recharge the batteries or move to the place where it is expected to start the next
task); finally, the route planning and traffic management policy. Most industrial AGVs have predefined routes as sequences of nodes
but still some alternatives routes can still be selected in order to avoid traffic problems.
Many researchers have studied and used different high-level simulation models for applications that include an AGV-based
transport system. A discrete event simulation model of reconfigurable automatic assembly systems is presented in [19]. The material
needed by the robotic assembly stations is transported by an AGV based material supply. The goal in this case is to support the layout
planning and evaluation of reconfigurable assembly systems. Additionally, in manufacturing systems but adapted to the Just-in-Time
(JIT) philosophy, the essay presented in [5] presents experimental design features and analysis of simulation results. A discrete event
simulation model was used in [20] to compare the performance of different trajectory planning strategies. Simulation models and
metamodels were developed in [18] to validate the original model and evaluate the system performance to assist factory managers
in making the proper decisions. Simulation was proposed in [21] to demonstrate the effectiveness of multi-load vehicles and in [22]
to show the system performance enhancement using the same kind of vehicles. Simulation sequential metamodeling (SSM) was used
in [12] to determine the optimal vehicle fleet size in an automated material handling system at an automotive factory. Finally, some
studies investigate the influence of the AGV transport system over the performance of a flexible manufacturing system (FMS) [23].
Most of the systems proposed above are linked to one particular application. Furthermore, the simulation models are implemented
using a specific simulation software tool. For example, in [19] the simulation model was developed in the Siemens Tecnomatix Plant
Simulation software tool. The discrete event simulation model described in [20] was built using the tool for operations modeling and
analysis in space (TOMAS) simulation package [24]. The ARENA software package was used in [5] to develop the simulation model.
In [12] a discrete-event simulation was used for the multi-stage, multi-product series and parallel network paint shop, and applied
ARENA in the modeling stage. The simulation models of the AGV system in [18] were constructed using the FlexSim simulation
software.
The use of those simulation tools requires the definition of the planning, scheduling, allocation and control policies that are the
objective of the evaluation. The simulation framework proposed in this paper uses the same planning, scheduling, allocation and
control modules as the control framework.
None of the solutions presented in the literature include both high-level and low-level simulation at the same time because they
deal with two different problems. The solution proposed here also uses two simulation levels but the control framework of both
simulation systems is the same one used to control the physical system.
There are some common parameters that need to be evaluated in all the different applications mentioned before such as the
number of AGVs needed, the delivery delays, minimum size of items in some stock areas, or the minimum battery level reached
during operation. Other parameters are application dependent but they can be obtained using the simulation framework proposed
here.

3. Global description of the transportation system

AGVs need to transport different items according to their applications. Most solutions used in autonomous hospital logistics
systems transport their items in carts and use some kind of flat robotic platform that lifts the cart [25]. In warehouses where items
are placed on pallets, the AGVs are usually some kind of automated forklifts [26]. Tugger trains can be used to transport stock
material to working locations in a factory because they can supply different stations with different materials efficiently [27]. In
some cases, the storage area can be considered a flat map while other cases include some three-dimensional structures such as
shelves where the items need to be located. The hooking and releasing process can also be very different depending on whether
pallets, carts or other containers are transported.
However, at the executive level, tasks for all these applications are quite similar and can be performed using the same tools.
The main task consists of the autonomous transportation between two points in the working environment. They need to grab the
load from the pick-up point, transport it and leave it in the dropping point. Furthermore, there is also always an event that starts
the execution of the transportation task even though the source of this event can be different. For example, a sensor might detect
the presence of a new cart to be transported, a user might request the transportation service in a GUI interface, or an enterprise
resource planning system (ERP) decides to reorder some items in the warehouse.
Fig. 1 shows the main elements that take part in two different transportation systems designed by our research group. Both
are centralized systems with a central server that coordinates the multirobot and multiuser system. The first one (Fig. 1) is an
autonomous logistics system for hospitals that uses a platform to lift carts containing meals, laundry or medicines [25]. The system
was developed by Proingesa S.A. in collaboration with the research center CARTIF and EEI, University of Vigo. A transportation
task is started whenever a cart is detected in the pick-up area during the scheduled time. For example, a food cart is detected in
the kitchen pick-up area during lunchtime. Therefore, the sensors located in the pick-up areas are connected to the central control
system. Robots have to transport carts from the industrial area (kitchen and laundry facilities) to the patient areas. However, they
leave the cart at the beginning of the patient area and the hospital staff distributes the food to the patients’ rooms. Most hospitals

3
J. López et al. Simulation Modelling Practice and Theory 116 (2022) 102430

Fig. 1. HospBot: Hospital transportation system.

have several floors and robots need to use elevators to move between floors. In this case, the elevators are also connected to the
central control system. A similar situation occurs when there is some security door in the robot path that needs to be open when
the robot approaches. The connections of all these devices are depicted in Fig. 1.
The second application (Fig. 2) is an autonomous warehouse storage system that uses autonomous forklift robots [26]. All the
goods come packed on pallets that need to be stored on shelves in the permanent storage area. The forklifts move them between
the different areas: reception area where customers leave their pallets, permanent storage area, temporary storage area and the
shipping area where users pick them up. The system was developed as a research project and was tested in a warehouse located in
the Parque Tecnológico Logístico (PTL) of Vigo. In this case, a transportation task can be requested by a user from a GUI or directly
from the ERP that decides where the pallet should be placed. For example, a customer arrives with some pallets and a company
employee leaves them in the reception area. In some cases, those pallets can be detected by a sensor connected to the central server.
The connections of all these devices are depicted in Fig. 2.
The last application for our simulator was to evaluate the possibility of using AGVs in an automobile factory to provide material
to one of the cells where the exhausts were fitted to the car. In this case, we only used the simulation part to create a report on
the estimation of the fleet size and changes needed to ensure the supply of items to the production cell. In this case, all the internal
transport systems for the other cells were human-driven vehicles (forklifts, tugger trains, etc.).

4. Control framework

Most control frameworks with a significant complexity are modular because dividing the control functions into modules simplifies
the problem. Each module is responsible for a certain functionality. However, modules have been implemented on different abstract
levels in many architectures. One of the most popular and more independent ways to implement each module is as an independent
process. The control modules developed in our applications are independent processes and can be divided into two sets:

• On-board control. The modules included in this group are executed in the on-board computer of each Robot. They implement
different functions to control each AGV including all the safety issues that cannot depend on the communications with the
central server;

4
J. López et al. Simulation Modelling Practice and Theory 116 (2022) 102430

Fig. 2. CargoBot: Warehouse storage system.

• Global control: This group includes the modules that are executed in the central server. They implement functions to coordinate
the AGVs, control the building devices and provide the interface with users. The on-board control set of each AGV is considered
as a single high-level module.

Both subsystems present a modular architecture where the modules are independent processes that share information through a
publication/subscription model. Each module registers with the central server and specifies the types of messages it publishes and
the types it listens for. However, the ways the connections are established between the modules are different:

• The on-board control system was developed with ROS [6] and for each topic, a communication channel between nodes is
established. Nevertheless, all nodes need to start by connecting to a central process to establish the channels.
• Communications between modules on the Global control system are managed using Java Inter Process Communication
(JIPC) [8]. All modules establish a single channel with a central process in the central server. Any message passed to the
central server is immediately copied to all other subscribed processes.

We decided to use ROS at the on-board level because it is currently the most popular framework to develop robotic projects. There are
ROS packages for most robotic sensors and actuators as well as packages that implement many navigation functions. Furthermore,
ROS has excellent simulation tools.
Even though it is possible to control multiple robots (including several independent systems) with ROS, in this case it entails an
overload in the communications traffic that is not acceptable in channels with restricted bandwidth. Instead, the communication
between each robot and the central system was implemented via JIPC using only one Wi-Fi channel per AGV. The goal is to use the
building wireless to exchange information between the AGVs and the central system. Another advantage of JIPC is that many of
the global control modules such as the GUIs are Java programs (and can thus be executed in different platforms). Furthermore, the
main tool to implement ROS communications in java (rosjava) was not available for the latest ROS1 current versions (ROS Melodic
and ROS Noetic).

4.1. On-board control

Even though the modules on this set depend on the transportation application and kind of AGV used, some common features
are shared by most of them. Fig. 3 represents the more significant modules for a factory transportation system [27] that uses tugger
trains to deliver stock material to working locations in a factory. Modules can be grouped in four different layers:

5
J. López et al. Simulation Modelling Practice and Theory 116 (2022) 102430

Fig. 3. On-board control framework.

• Hardware drivers layer. The hardware server modules isolate the control methods from the hardware details. They govern
hardware interaction acting as drivers for the hardware devices. Most of these devices are used in navigation, hooking and
releasing carts or interfacing with the users.
• Control layer. This layer implements the navigation functions such as determining the position of the robot (Localization),
maneuvers to hook and release carts (Maneuvers manager) and the reactive control that is responsible for following the planned
path (Path follower).
• Executive layer. This contains only one module that coordinates the sequence of actions that need to be executed by all the
other modules to carry out tasks. This module is part of RoboGraph [28].
• Interface layer. The modules in this layer serve on the one hand as graphical user interfaces and on the other as an interface
to connect with the control system on the central server (RobotWeb Interface).

A more detail description of these modules can be seen in our papers describing some of these applications [25,26].

4.2. Global control

The central server is the computer that runs the modules that coordinate the whole system. Since the central server is a critical
system, most applications include a backup server to take the role of the main server whenever a problem occurs.
Fig. 4 presents the whole system including the Global control framework and the on-board framework of each AGV. The modules
in the Global control framework exchange information using a message publish/subscribe mechanism named JIPC that provides a
central communication process and a client library. Only one module of each AGV (RobotWeb Interface) is connected to the central
server. Modules belonging to the global control framework can be grouped in the same layers as the on-board framework. In this
case the only program in the hardware driver layer is a module named BuildingInterface that manages all the information between
the devices of the building and the rest of the system. All the building devices are connected to some I/O Modbus interface. These
interfaces are connected to the central server via Ethernet using the Modbus protocol. The control layer includes two modules:

6
J. López et al. Simulation Modelling Practice and Theory 116 (2022) 102430

Fig. 4. Global control framework.

• Task manager. Handles task scheduling and task resource allocating. For example, all the transportation tasks need to allocate
an AGV. In most of these applications all the AGVs have the same functionality so every AGV can carry out any kind of task.
The task manager services can also be required once the task is started. For example, when transporting carts labeled with
RFIDs, the AGV reads the TAG id and sends a message to the Task manager, which should reply with a destination point.
• Traffic manager. Handles all the route planning and controls the traffic. The AGVs follow the path and stop if they find an
object in their way. That object can also be another AGV. The obstacle collision avoidance is a reactive algorithm carried out
by an on-board module (path follower). This is a safety process that cannot depend for example on network problems.

Various methods can be used to design the route planning and traffic control algorithms that detect [29] and avoid [30] deadlock
situations. We use a centralized approach where the central server supervises the state of all AGVs. Still, the vehicles have a high
level of autonomy and can operate without connection to the server for some time. Routes are created on top of the map employing
a GUI using unidirectional lanes when possible. However, in some applications there are some areas such as double direction lanes,
workstations, intersections or elevator zones where only one vehicle should be allowed to avoid a possible deadlock. In our system,
those areas are user-defined as exclusion zones. The traffic manager plans the routes using the improved Dijkstra algorithm proposed
in [31] that produces the path as a sequence of nodes. Access to the exclusive areas is managed by the traffic manager. The
AGVs follow the route autonomously but before reaching the first node of an exclusion zone, they have to request access from
the centralized traffic manager. For example, when an AGV requests to enter one elevator zone, the traffic manager makes sure that
the elevator zones on the start and destination floor are not locked by another vehicle. If they are free, the manager gives access to
the AGV and locks both zones. As soon as the AGV leaves the last node of the destination elevator zone, it unlocks both zones.
This simple solution relies on the developer skills defining the routes and exclusion zones to avoid possible deadlock situations.
However, we have found through extensive simulation that it is very difficult even for a well-trained developer to consider all
possible scenarios. In fact, detecting problems of this nature is one of the purposes of simulation. The focus of this research is not
to develop a better deadlock avoidance algorithm but to investigate the use of extensive simulation as a tool to detect possible
unwanted situations regardless of the dispatching, scheduling and routing algorithms used. Since the simulation framework is the
same as the control framework and we can add stress to the systems by adding more tasks and AGVs, we force those unlikely
scenarios in the simulation.

7
J. López et al. Simulation Modelling Practice and Theory 116 (2022) 102430

4.3. Task modeling, executing and monitoring

Modules below the executive layer implement low-level actions and report events during the execution of those actions.
The executive layer commands and coordinates the execution of the actions, dealing with different outcomes to carry out the
transportation tasks. It is therefore responsible for task decomposition, dispatching, monitoring and error recovery. The relatively
complex missions or tasks must be first defined as a sequence of actions or low-level commands. A popular choice for representing
executive functions are Petri Nets (PNs) [12] that embody a well-known tool for modeling this dynamic behavior. Each of the
transportation tasks is implemented in one or more PNs. The resulting system is very flexible since a modification in a task is easily
implemented with minor changes in the corresponding PNs.
We use a tool named RoboGraph (RG) [28] to implement the executive layer in the on-board control and the Global control.
RG can deal with modules connected with IPC, JIPC or ROS and it has been used in several multirobot applications, such as a
hotel assistant project (BellBot [32]), a surveillance project (WatchBot [33]), a tour guide system (GuideBot [34]), an autonomous
vehicle [35], a hospital transportation system [25] and a warehouse storage project [26]. RoboGraph is used first to define the tasks
as PNs and then to load and execute the control sequences modeled on the PNs. Each one of these functions is carried out by a
module (Fig. 3 and Fig. 4):

• RoboGraph GUI is an Integrated Development Environment (IDE) for defining and debugging the tasks as PNs. The IDE
includes editing tools to publish and subscribe to messages/topics of all the modules already included in the system without
writing any code. Besides editing, it also includes tools to analyze and debug the PNs. The analysis can be carried out using
algebraic analysis and reachability graph-based analysis. The debugging tools include the real-time presentation of the state
(marking) of all the PNs that are currently running, and the playback of a previously logged execution.
• RoboGraph dispatch carries out the task executions: loads the PN’s task previously defined with the IDE and starts the
execution according to the initial marking of the main PN. When executing a task, this module sends messages to other
modules to request the execution of basic actions according to the plan defined in the PNs and the events (messages) produced
by the running modules. Furthermore, even the execution of a PN is also considered an action that dispatch executes. All the
interaction between modules is done by publishing and subscribing to messages. Therefore, problems such as a crash in a
module do not block dispatch and simple mechanisms to detect and recover from a failure or exception situation can be
defined within the PNs.

Both modules are independent processes (Fig. 4). While the transportation system is operating, only dispatch needs to be running
even though the GUI can be executed to display the current state of the PNs. The GUI in monitor mode subscribes to different
dispatch messages that report the evolution of the PN’s state. Using this information, the GUI shows the status of the different
running or waiting Petri nets. Every running Petri net is shown in a different tab with the current marking presenting a snapshot of
the status of the system. Another option is to log all these messages published by dispatch into a database. We use this information
for debugging and analyzing the performance of the system.
The description of a task for a specific application will help to clarify the way PNs are used to define and execute the tasks.
A typical task executed by service robots for hospitals is the distribution of meals from the kitchen area to the patient areas. At
mealtime, food carts are filled up in the kitchen and placed in the pick-up area. The cart is detected by a sensor and a message
reporting that a new cart needs to be delivered is issued. The destination of the cart can be determined in several ways such as
using some kind of tag attached to the cart or preassigned according to the cart position. In the Global control system, a PN such as
the one in Fig. 5 starts the transportation task. The foreground color of transitions and places represents PN execution information
such as if the module or modules referenced in a transition/place are already running in the system. When the RG dispatch module
starts a PN, it subscribes to all the messages used as events that can change the state of the PN and registers publishers for all
the messages included in the actions. The first transition labeled as start in Fig. 5 represents a timeout (300 ms) that needs to be
included in the ROS PNs to deal with ROS delays on registering messages. That is not necessary for IPC and JIPC PNs but we still
add the transition without condition for the sake of generality.
Once the start transition is fired, the token from the init place is removed and a new token is added to the waiting place.
That place has no actions associated since the only purpose is to wait for some of the events that can start a transportation task
(sensor_loaded request, sensor_empty request or manual request). sensor_loaded and sensor_empty requests are messages published by
the BuildingInterface module whenever a sensor in the kitchen area detects a loaded cart or a sensor in the patient area detects an
empty cart. In both cases, when the transition is fired a place named select_robot is marked and a request to allocate a robot is sent
to the Task Manager module. Once a robot is selected, Task Manager sends the selected reference in a message and the transition
robot_selected is fired. For the first case, the place deliver_meal receives a token and a start PickDropTag PN message is issued. For the
second case, the place return_cart receives a token and a start PickDrop PN message is issued. In both cases, the net_started transition
has no conditions associated so the waiting place receives a token again. The other branch of the PN deals with manual requests
from the GUI.
Fig. 6(a) shows the PickDropTag PN that can be started in the deliver_meal place of the PN in Fig. 5. In a similar way, Fig. 6(b)
shows the PickDrop PN started in return_cart place. The error branches are not included for the sake of simplicity. Both PNs present
a similar sequence of actions and events that include messages from/to on-board modules and Global control modules.
The Request Path place action is to send a message to the Traffic Manager module (Fig. 4) to request a path for the robot. The
transition Send Path to Robot is fired when the outcome message with a path is received. This transition also has one action associated

8
J. López et al. Simulation Modelling Practice and Theory 116 (2022) 102430

Fig. 5. Main Petri Net that models a single transportation task.

(publish a message to follow the path) that is sent to the robot. That message commands the on-board RG dispatch module (Fig. 3)
to execute the follow path PN in the robot. Once the robot reaches the goal, the on-board RG dispatch module (Fig. 3) reports the
end of the PN with a message that fires the Goal Reached transition in the PickDrop or PickDropTag PN.
The pick maneuver modeled in the Pick place and Pick Done transition on both PNs (Fig. 6) is carried out by the on-board
maneuvers manager module (Fig. 3).
The PickDropTag PN includes some extra actions to read the cart tag to figure out where the cart needs to be delivered while
the PickDrop PN is used to return the empty carts that can be delivered in any empty spot on the cart return area.
A total of eighteen tasks are modeled each one using several PNs. However, many basic PNs are used in several tasks. For
example, both PNs in Fig. 6 use the follow path PN. As a matter of fact, that PN is used by most transportation tasks including the
charge battery task because the robot needs to follow the path from its current position to the battery charger position.
PN properties make them also good candidates for task analysis and performance evaluation. Significant research has been done
in this area for industrial applications [36] and mobile robots tasks [37]. Among other properties, they can be used to check for
liveness, boundedness and reachability. Furthermore, there are several Petri Net tools such as PIPE [38] that include a wide variety
of modules for different kind of analysis.

5. Simulation framework

Using a real environment and a physical AGV to evaluate the performance in the initial design phases can be a complex, expensive
(in time and resources) and even risky (possible damage to equipment and people) assignment. Instead, simulating the robotic system
provides an easy way to start testing a new design, reducing costs and possible hazards. The frameworks presented in the previous
sections show that the autonomous transportation system integrates a relatively large number of modules that need to be tested
and analyzed to find the optimal configuration before the final implementation. However, testing the lowest level on-board control
modules requires a realistic world accuracy that is different from the one needed for the global control modules.

5.1. On-board control simulation

There are many robot simulators such as Gazebo [9], V-REP [10], Webots [39] or Stage [40] that can be included in one or several
robotic frameworks. Simulators such as Gazebo support the use of different physics engines (ODE, Bullet, DART and Simbody) to

9
J. López et al. Simulation Modelling Practice and Theory 116 (2022) 102430

Fig. 6. A couple of PNs in the Global control.

create physics phenomena such as rigid body collisions with an outcome similar to the real world. Fig. 7 represents the way Gazebo
can be used to simulate the behavior of the AGV. Gazebo simulates the interaction of the robot with the environment including the
sensor readings. Comparing frameworks in Fig. 7 with the one in Fig. 3 we can see that the simulator replaces the Hardware drivers
layer producing and subscribing to the same topics as the drivers so that all the other modules remain the same. We use that kind
of simulation when designing the on-board control system.

5.2. Global control simulation

There are many reasons to start designing the global system using a simulator:

• The budget for the project is going to depend on some parameters such as the number of AGVs needed. For complex systems,
the use of a good simulator is essential to estimate these parameters correctly.
• In some cases, the design and implementation of the autonomous transport system must be carried out in parallel to the
construction of the building where the system is going to be installed in order to meet project delivery dates. In such situations,
the only available map of the building is some kind of CAD map used for the construction. Because most applications need
some kind of occupancy map, a tool to convert a CAD map to an occupancy map was created.
• It is a good practice to design some elements of the building that take into account the needs of the autonomous transportation
system.
• The simulator can provide information to make the system more efficient. For example, we can detect traffic bottlenecks and
design alternative routes to avoid them.

10
J. López et al. Simulation Modelling Practice and Theory 116 (2022) 102430

Fig. 7. Gazebo on-board simulation framework.

As in the case of the design of each AGV, a possibility could be to use Gazebo, adding all the robots to the working environment.
However, for applications with many robots such as the ones included here, that could mean simulating many sensors for all the
robots, which would be very CPU consuming. Moreover, the purpose of the simulation at this level is to debug the Global control
modules and to determine some parameters such as the number of AGVs required to carry out the job. In this case, there is no need
for a physical engine to model the robot interaction with the environment and sensor readings.
Since at this point we are not debugging the navigation functions for each AGV, we can use the simulation framework proposed
in Fig. 8. For each robot, the hardware, hardware drivers and control layers are replaced by an eventSim module. This module
estimates statistically the robot action times and outcomes. The executive layer is the same because the communication interface
(messages) remains the same.

5.2.1. Simulating robot actions

The on-board eventSim module simulates actions such as follow trajectory, take elevator, leave elevator, hook up cart, release
cart or dock into the charger by estimating the time for each one of these actions. There are different ways to generate the times that
go from deterministic values stored in a log file to random values generated according to some probabilistic distribution function.
The most popular is a normal distribution:
1 −(𝑥−𝜇)2 ∕2𝜎 2
𝑃 (𝑥) = √ 𝑒 (1)
𝜎 2𝜋
where 𝑥 is the execution time. The average 𝜇 and variance 𝜎 2 are usually obtained experimentally. As in the random arrivals, we
need a methodology for pulling random action times according to the previous distribution. We use the Box–Muller Transform [41]
to generate independent N(0, 1) random numbers because it is a more computationally efficient alternative to the inverse transform
sampling method. Briefly, first, a couple of random numbers (𝑝1 , 𝑝2 ) are pulled form a uniform distribution in the interval [0, 1].
Then we obtain the distributed independent N(0, 1) variables (𝑡1 , 𝑡2 ) as:
√
𝑡1 = −2𝑙𝑜𝑔(𝑝1 )𝑐𝑜𝑠(2𝜋𝑝2 ) (2)

11
J. López et al. Simulation Modelling Practice and Theory 116 (2022) 102430

Fig. 8. Global simulation framework.

√
𝑡2 = −2𝑙𝑜𝑔(𝑝1 )𝑠𝑖𝑛(2𝜋𝑝2 ) (3)

Finally, to obtain the samples for a normal distribution with mean average 𝜇 and variance 𝜎 we need to scale the variable by
the standard deviation 𝜎 (square root of the variance) before adding the mean 𝜇.
Most AGVs use electric drives powered by batteries that require periodic recharging. The task manager uses, among other
parameters, the AGV battery level for the task allocation mechanism. If the AGV’s battery level is insufficient to perform a task,
it should be assigned to another AGV. A common allocation policy in all our systems is that when an AGV has no task allocated,
it should wait docked in one of the charging stations. This is accomplished by using the charge battery task as the default task.
Therefore, it is necessary to simulate the battery level for each AGV. Fig. 9 shows the AGV battery level while it is moving with
and without load. From these data, obtained experimentally, a couple of polynomial regression equations are obtained that serve
to obtain the simulated battery levels and to predict the value at the end of a task. Many factors influence this curve. For example,
a new battery is expected to provide better performance than an old one. The results in Fig. 9 where obtained with new batteries.
As expected, experiments with older batteries show a similar battery discharge shape but shorter in time. The task manager module
assumes the worst battery performance allowed. If performance drops below that level, a maintenance message is displayed to
replace the batteries.

5.2.2. Simulating job requests

Transport requests might have different sources depending on the application. For example, they can be related to the activation
of a sensor that detects a cart to be transported, a request of a user, or a message sent from the ERP system. As in the case of
robot actions, their arrival times can be modeled using different statistics. The more popular case is to assume a Poisson process.
Therefore, the time between each pair of consecutive requests has an exponential distribution with an arrival rate parameter 𝜆. In
addition, each of these inter-arrival times is assumed to be independent of other inter-arrival times. In this case, the probability that
the event will occur during the time interval [0, t] is:

𝑃 (𝑎𝑟𝑟𝑖𝑣𝑎𝑙 < 𝑡) = 1 − 𝑒−𝜆𝑡 (4)

For the simulation, we need a methodology for pulling random arrival times according to the previous distribution. First, a
random number 𝑝 is pulled form a uniform distribution in the interval [0, 1]. Then we obtain the time t inverting Eq. (4):
𝑙𝑛(1 − 𝑝)
𝑝 = 1 − 𝑒−𝜆𝑡 ⇒ 𝑡 = − (5)
𝜆

12
J. López et al. Simulation Modelling Practice and Theory 116 (2022) 102430

Fig. 9. Battery level versus time while the AGV is moving with and without load.

5.3. Task analysis and simulation

There are many advantages using PNs:

• Task modeling. It is a very efficient way to model any kind of discrete event system. For example, they have been used
extensively to model manufacturing systems.
• Task analysis. Some PN properties such as liveness, boundedness, deadlock-free, etc. can be used to characterize the dynamic
system behavior. Many analysis methods have already been developed due to their popularity in other fields.
• Task execution. Using RoboGraph, the definition of the task as hierarchic PNs is already the program executed by RoboGraph
dispatch.
• Task debugging. RoboGraph includes tools to debug tasks both, in real-time and off-line.
• System analysis. RoboGraph includes the possibility of logging all the messages that report the evolution of the PNs into a
database.

The messages logged while executing the PNs in a database can be used to analysis the performance of the system that can help to
determine important parameters such as the number of robots needed to meet the user requests. Using the simulation framework
presented here, many control modules including the executive layer modules can be the same as the one designed for the control
framework.
The focus of this research is not planning and control algorithms but the use of extensive simulation as a tool to detect possible
problems in those algorithms. Some of these problems arise only under specific conditions or scenarios. By stressing the system by
adding more tasks and AGVs, we force those unlikely scenarios in simulation. It is therefore desirable to extend the simulation time
so that a greater number of scenarios can be carried out. For that purpose, the simulation time will run faster than real time. This is
possible because the proposed simulation framework requires much fewer resources than if we completely simulated all AGVs using
some tool such as Gazebo. The simulation time is a parameter shared by all the modules. Some of them such as the event simulators
and the executive module need to take it into account. In particular, the PNs include timers and schedules that can use real time
or simulated time. The timers are used to program actions that need to be executed for a limited time and also for timeouts. The
schedulers are used to define periods of day such as lunchtime and dinnertime associated to some regular tasks and maintenance
tasks.

6. Results

The system has been used in different applications such as transporting pallets in warehouses [26], transporting carts in
hospitals [25] and transporting parts in a factory [27]. The purpose of performing the simulation is twofold. Firstly, to size the
fleet of robots properly when the number of AGVs is needed to estimate the project budget. A small number of robots might lead to

13
J. López et al. Simulation Modelling Practice and Theory 116 (2022) 102430

Fig. 10. Areas where the robots pick up carts, drop carts and charge their batteries.

delays in the transportation tasks because there are no robots available to deal with the demand. However, there is a point where
increasing the number of robots might also lead to traffic delays due to traffic congestion. Secondly, to validate the system and detect
design problems before it is installed in the factory. For example, to make sure there are no traffic problems such as deadlocks and
to find the existence of bottleneck points to remove. In the next subsections, one example of each of these issues is presented in a
different application.

6.1. Sizing the robot fleet

In general, increasing the number of robots in the system should improve the performance, reducing delivery times. A project
that was carried out in a factory to transport parts to the production line will be used to analyze this issue. The task here is to
move carts from the storage area to a cell on the production line. Every time a cart is emptied in the cell, a tugger train should pick
up a loaded cart in the storage area and release it in a temporary storage area on the side of the production cell. Then, the train
picks up an empty cart in this temporal storage area and brings it back to the storage area. Trains that do not have a task assigned
are connected to a battery charger in an area close to the storage area. Fig. 10(a) shows a map of both areas (storage and battery
charging) while Fig. 10(b) shows the temporal storage area by the productions cell. The AGV path is defined by a sequence of circles
linked by arcs. Green circles are regular nodes and red nodes belong to an exclusion area. The factory includes two production lines
and AGVs need to transport carts to one cell in each line.
The goal of this project was to study the possible automation of this transport line in a factory where all the other lines that
provide other cells of the factory were manual. Furthermore, since the cells need parts in a wide variety of shapes and sizes, they
are provided by a wide variety of vehicles such as forklift trucks, reach truck lifts, low lift pallet trucks, stacker trucks, order
pickers, tugger trains (also known as ‘‘logistic trains’’) and others, all driven by humans. This traffic was modeled as an occupancy
probability for each of the nodes (Fig. 10) in the trajectory of the transportation line to be automated. Those statistics were obtained
from the information provided by sensors added to the former human-driven vehicles. At the same time, other parameters needed
for simulation were recorded such as the average speed on each node of the path. Those parameters serve to define the events
generated by the eventsim module (Fig. 8).
In a similar way, the transport requests were modeled by recording the requests during a week and assuming a Poisson process.
Therefore, the time between each pair of consecutive requests has an exponential distribution with an arrival rate parameter 𝜆.
Random arrivals were generated according to the process described in Section 5.2.1
To speed up the process we did not use a low-level simulator for each robot. The goal here is not to debug the robot control
system as described in Section 5.2.2. Instead, a basic robot simulator was used were most of robot actions such as travel from
one node to the other, pick up a cart, drop a cart or plug the charger were modeled as atomic actions with a normal distribution
execution time.
As presented in Section 4.3, tasks at the executive level are modeled using several PNs. For example, the main PN for a single
transportation task that is carried out by one vehicle is similar to the net in Fig. 6(a). The aim of using simulation here was to find
the system requirements to provide the production cell with a sufficient stock of parts.

14
J. López et al. Simulation Modelling Practice and Theory 116 (2022) 102430

Fig. 11. Running tasks versus waiting tasks for the two AGVs case.

Fig. 12. Running tasks versus waiting tasks for the three AGVs case.

All the messages published by RoboGraph about the evolution of the PN marking were stored in a database to obtain several
statistics later that help to find the optimal number of autonomous vehicles (Section 4.3). An easy way to find out if the number
of robots is enough to avoid a disruption in the supply chain is to execute the simulation for a long period of time and see if
such disruption occurs. That is the case if we use two AGVs in this transport line. Fig. 11 shows the number of running and waiting
transportation tasks versus time. A transportation task request is produced each time a cart in the temporal storage area (production
cell) is empty. For the results shown in Fig. 11, the capacity of the buffer in this area has been increased to 8 carts. The number
of running tasks after a short period of time is always two, meaning that both robots are busy all the time. Since the task requests
cannot be fulfilled by only two robots, the number of pending tasks increases until it reaches a point that the production cell is out
of stock (time 21:22). At that time there are 2 running tasks and 6 pending tasks. Since each task request means an empty cart, all
the carts in the production cell are empty and there is a disruption in the supply. Once the disruption is detected, the cell and all
the production line is stopped, no more task requests are issued and eventually (time 22:15) the AGVs finish the pending tasks.
Increasing the number of AGVs to three produces a quite different situation as shown in Fig. 12. In this case, robots are able to
carry out all the tasks even though they do not have much time to charge the batteries. However, sometimes a task is requested
while both robots are busy but soon that request is performed by one AGV.
Fig. 13(a) shows the distribution of tasks among the three AGVs. The policy to allocate tasks to AGVs provides a uniform
distribution of tasks to avoid excessive wear of an AGV compared to others. On the other hand, Fig. 13(b) shows the time share of
AGVs between tasks to transport carts to the production line 1 (blue), production line 2 (green) and charging the battery (red).

6.2. Validating the system

Many issues can be tested in simulation to evaluate if the system meets the performance required. The system requirements can
be specified in different parameters such as a maximum delay in the delivery of items or average items delivered. For example, in

15
J. López et al. Simulation Modelling Practice and Theory 116 (2022) 102430

Fig. 13. Distribution of tasks among robots and time among tasks.

Fig. 14. Portion of the industrial floor.

the hospital transportation system, the meals transportation tasks are demanded only at certain intervals of time: breakfast time,
lunchtime and dinnertime. Lunches should be delivered within the lunch period. In addition, in order to keep food warm, every
cart should be delivered to the patient area within a maximum time. In this kind of application, the AGVs routes are defined to
minimize the path of the AGVs in the patient’s area because that can be a source of problems. In a multi-storey building the cart
drop-off areas on the patient floors are located close to the elevators. AGVs move only from the elevators to those areas. On the
industrial floor, AGVs move between the kitchen, laundry room and elevators.
Fig. 14 shows the user interface for a hospital with twelve floors and nine AGVs. The main window has twelve tabs to select the
floor that we want to visualize. For the selected floor, the possible paths are drawn over the map. The path is a sequence of nodes
(circles) linked by arcs. Green nodes are regular path nodes, yellow nodes are elevator nodes and violet nodes are nodes currently
occupied by AGVs. The navigation pane on the left allows to select the floor (top) or the robot (bottom).
Fig. 15 shows a portion of the plan of a patient floor for the same building. AGVs leave the elevators (yellow nodes) and drop
off the carts in the area in front of the elevator.

16
J. López et al. Simulation Modelling Practice and Theory 116 (2022) 102430

Fig. 15. Drop off area in front of an elevator in the patient floor.

After several simulations with different configurations, we concluded that twelve active robots could perform the transportation
with the performance parameters required. The simulations help to detect some weak points in the configuration initially proposed
such as traffic distributions that lead to deadlocks and bottleneck points. For example, this hospital has two industrial floors (−2
and −1) and initially two elevators were assigned to move the AGVs between these floors. Floor −2 is where the kitchen is located.
Floor −1 is where the AGVs move to different areas where the other six elevators are located. This is, all the AGVs have to move
from floor −2 to floor −1 first. Then move in floor −1 to one of the other six elevators to go to the rest of the floors.
Using the PNs evolution data stored in the simulation database, Fig. 16 represents the time that the AGVs were using the elevators
while delivering dinner. The two elevators used between floors −2 and −1 named ‘‘Ascensor Z4 1’’ and ‘‘Ascensor Z4 2’’ represent
a bottleneck making the robots wait longer than expected. The total distance traveled by the robots is close to 24 km to transport
62 carts. Each robot was waiting for different events (access to elevators, elevators move to other floor, access to restricted areas
and so on) almost 46% of the time spent in each task. The average execution time of a task was 18 min and 35 s. A Gaussian
normal distribution (Eq. (1)) was used to model the generation of meal carts in the kitchen. Here, 𝑥 is the time elapsed between
the generation of two carts. The average 𝜇 and variance 𝜎 2 were obtained experimentally.
This situation changes when two new elevators are assigned to the AGVs as shown in Fig. 17. In this case, the waiting time spent
in each task was reduced to 42% and the average execution time of a task was 19 min and 39 s.
During the two hours taken to deliver all the meals from the kitchen area to the corresponding floors and return the empty carts,
most robots where busy and had almost no time to charge the batteries. However, that is not a problem because afterwards they
have time to charge their batteries when demand for the remaining tasks (transporting medicine and laundry carts) is much lower
and spread over time. Fig. 18 shows that during this period of time the number of running tasks was close to 12. At some points
there were even up to four carts waiting to be transported in the kitchen area.

7. Conclusions

This paper presents a flexible simulation and control framework for autonomous transport systems based on AGVs. In the process
of developing applications like these, two levels of simulation are usually applied. The first level is an initial test for the navigation
system of the AGVs and the process is very similar to other robotic systems. At this level, the modular control frameworks (ROS,
Carmen, etc.) are also used for simulation by replacing the physical robots with a simulation module.
In the second simulation level is used to estimate the fleet size, evaluate routing policies and allocation mechanisms. Most of the
bibliography on simulation of internal transport systems for different kinds of buildings such as factories, warehouses and hospitals
deal with this simulation level. However, the simulators at this level are implemented using specific simulation software tools that
do not follow the control framework. The work presented here extends the idea for the first level of simulation using the modular

17
J. López et al. Simulation Modelling Practice and Theory 116 (2022) 102430

Fig. 16. Intervals of time when elevators are occupied by the AGVs during dinnertime with the initial configuration.

Fig. 17. Intervals of time when elevators are occupied by the AGVs during dinnertime with the new configuration that adds two elevators between the industrial
floors.

control framework. This approach presents several advantages: The first one is that there is no need for a specific simulation model
of the control, planning and scheduling mechanisms. It is a modular and flexible framework where all the extensive modules used
in ROS can be directly integrated and used in simulation. This facilitates the testing of different policies by replacing the modules
that implement those policies. In addition, in the control system that we propose, tasks are easily modeled and verified using a Petri
Net-based model.
This framework has been used in several projects such as an autonomous logistic system for hospitals [25], a warehouse internal
transport system that uses autonomous forklift robots [26] and a parts transporting system in a factory that uses tugger trains [27].
Examples of how the simulation can help in the design of some parameters such as the size of the fleet and policies are shown in
the results sections.
Finally, we want to point out that even though it was not required in any of the projects carried out during this research, an
accurate, realistic-world simulation of the whole system can be achieved with the framework proposed here. This more realistic
simulation can be obtained by replacing the simulated AGVs in Fig. 8 for the framework in Fig. 7. Fig. 19 shows the resulting
framework. Of course, this detailed simulation is obtained at the cost of greatly increasing the computational load. This approach
can be useful in applications where the interaction between robots needs to be simulated.

18
J. López et al. Simulation Modelling Practice and Theory 116 (2022) 102430

Fig. 18. Meal delivery running tasks versus waiting tasks during dinnertime.

Fig. 19. Simulation framework for a world accuracy simulation framework.

19
J. López et al. Simulation Modelling Practice and Theory 116 (2022) 102430

Acknowledgments

The research has been partially funded by ‘‘Programa Retos Investigación del Ministerio de Ciencia, Innovación y Universidades,
Spain (Ref. RTI2018-096652-B-I00)’’. We would also like to thank all the people that contributed in other projects where this research
was carried out [25–27].
Funding for open access charge was provided by Universidade de Vigo/CISUG.

References

[1] D. Smith, S. Srinivas, A simulation-based evaluation of warehouse check-in strategies for improving inbound logistics operations, Simul. Model. Pract.
Theory 94 (2019) 303–320.
[2] S. Lothar, Z. Lindu, Worldwide development and application of automated guided vehicle systems, Int. J. Serv. Oper. Inf. 2 (2) (2007) 164–176.
[3] B. Sigal, S. Edna, E. Yael, Evaluation of automatic guided vehicle systems, Robot. Comput.-Integr. Manuf. 25 (2009) 522–528.
[4] L. Sabattini, V. Digani, C. Secchi, G. Cotena, D. Ronzoni, M. Foppoli, F. Oleari, Technological roadmap to boost the introduction of AGVs in
industrial applications, in: 2013 IEEE 9th International Conference on Intelligent Computer Communication and Processing, ICCP, 2013, pp. 203–208,
http://dx.doi.org/10.1109/ICCP.2013.6646109.
[5] S.E. Kesen, O.F. Baykoç, Simulation of automated guided vehicle (AGV) systems based on just-in-time (JIT) philosophy in a job-shop environment, Simul.
Model. Pract. Theory 15 (3) (2007) 272–284.
[6] M. Quigley, K. Conley, B. Gerkey, J. Faust, T. Foote, J. Leibs, R. Wheeler, A.Y. Ng, ROS: An open-source robot operating system, in: ICRA Workshop on
Open Source Software, Vol. 3.2, Kobe, Japan, 2009, p. 5.
[7] M. Montemerlo, N. Roy, S. Thrun, Perspectives on standardization in mobile robot programming: the carnegie mellon navigation (CARMEN) toolkit, in:
IROS, IEEE, 2003, pp. 2436–2441.
[8] J. López, D. Pérez, E. Zalama, A framework for building mobile single and multi-robot applications, Robot. Auton. Syst. 59 (3–4) (2011) 151–162.
[9] N. Koenig, A. Howard, Design and use paradigms for gazebo, an open-source multi-robot simulator, in: 2004 IEEE/RSJ International Conference on
Intelligent Robots and Systems (IROS)(IEEE Cat. No. 04CH37566), Vol. 3, IEEE, 2004, pp. 2149–2154.
[10] E. Rohmer, S.P. Singh, M. Freese, V-REP: A versatile and scalable robot simulation framework, in: 2013 IEEE/RSJ International Conference on Intelligent
Robots and Systems, IEEE, 2013, pp. 1321–1326.
[11] S. He, J. Luo, Deadlock control of autonomous vehicle storage and retrieval systems via coloured timed Petri nets and digraph tools, Int. J. Prod. Res. 47
(12) (2009) 3253–3263.
[12] B. Dengiz, O. Belgin, Simulation optimization of a multi-stage multi-product paint shop line with response surface methodology, Simulation 90 (3) (2014)
265–274.
[13] C. Pinciroli, V. Trianni, R. O’Grady, G. Pini, A. Brutschy, M. Brambilla, N. Mathews, E. Ferrante, G. Di Caro, F. Ducatelle, et al., ARGoS: a modular,
parallel, multi-engine simulator for multi-robot systems, Swarm Intell. 6 (4) (2012) 271–295.
[14] L. Hugues, N. Bredeche, Simbad: an autonomous robot simulation package for education and research, in: International Conference on Simulation of
Adaptive Behavior, Springer, 2006, pp. 831–842.
[15] S. Carpin, M. Lewis, J. Wang, S. Balakirsky, C. Scrapper, USARSim: a robot simulator for research and education, in: Proceedings 2007 IEEE International
Conference on Robotics and Automation, IEEE, 2007, pp. 1400–1405.
[16] L. Pitonakova, M. Giuliani, A. Pipe, A. Winfield, Feature and performance comparison of the V-REP, gazebo and argos robot simulators, in: Annual
Conference Towards Autonomous Robotic Systems, Springer, 2018, pp. 357–368.
[17] A. Staranowicz, G.L. Mariottini, A survey and comparison of commercial and open-source robotic simulator software, in: Proceedings of the 4th International
Conference on Pervasive Technologies Related To Assistive Environments, 2011, pp. 1–8.
[18] J.C. Chen, T.-L. Chen, Y.-C. Teng, Meta-model based simulation optimization for automated guided vehicle system under different charging mechanisms,
Simul. Model. Pract. Theory 106 (2021) 102208.
[19] A.B. Viharos, I. Németh, Simulation and scheduling of AGV based robotic assembly systems, IFAC-PapersOnLine 51 (11) (2018) 1415–1420.
[20] M.B. Duinkerken, J.A. Ottjes, G. Lodewijks, Comparison of routing strategies for AGV systems using simulation, in: Proceedings of the 2006 Winter
Simulation Conference, IEEE, 2006, pp. 1523–1530.
[21] U. Bilge, J.M. Tanchoco, AGV systems with multi-load carriers: basic issues and potential benefits, J. Manuf. Syst. 16 (3) (1997) 159–174.
[22] J.R. van der Meer, R. de Koster, Using multiple load vehicles for internal transport with batch arrivals of loads, in: New Trends in Distribution Logistics,
Springer, 1999, pp. 197–214.
[23] K. Foit, G. Gołda, A. Kampa, Integration and evaluation of intra-logistics processes in flexible production systems based on OEE metrics, with the use of
computer modelling and simulation of AGVs, Processes 8 (12) (2020) 1648.
[24] H.P. Veeke, J.A. Ottjes, TOMAS: Tool for object-oriented modelling and simulation, in: Proceedings of the Business and Industry Simulation Symposium.
Washington DC [SCS] Pp, 2000, pp. 76–81.
[25] J. López, D. Pérez, R. Pinillos, S. Domínguez, E. Zalama, J.G. García-Bermejo, Diseño y desarrollo de un sistema de transporte reconfigurable para entornos
hospitalarios, Rev. Iberoam. Autom. Inf. Ind. 9 (1) (2012) 57–68.
[26] J. López, D. Pérez, I. Vaamonde, E. Paz, A. Vaamonde, J. Cabaleiro, Building a warehouse control system using ride, in: Robot 2015: Second Iberian
Robotics Conference, Springer, 2016, pp. 757–768.
[27] R. Samaniego, R. Rodríguez, F. Vázquez, J. López, Efficient path planing for articulated vehicles in cluttered environments, Sensors 20 (23) (2020) 6821.
[28] J.L. Fernández, R. Sanz, E. Paz, C. Alonso, Using hierarchical binary Petri nets to build robust mobile robot applications: RoboGraph, in: IEEE International
Conference on Robotics and Automation, 2008. ICRA 2008, IEEE, 2008, pp. 1372–1377.
[29] M. De Ryck, M. Versteyhe, F. Debrouwere, Automated guided vehicle systems, state-of-the-art control algorithms and techniques, J. Manuf. Syst. 54 (2020)
152–173.
[30] R.L. Moorthy, W. Hock-Guan, N. Wing-Cheong, T. Chung-Piaw, Cyclic deadlock prediction and avoidance for zone-controlled AGV system, Int. J. Prod.
Econ. 83 (3) (2003) 309–324.
[31] J.B. Orlin, K. Madduri, K. Subramani, M. Williamson, A faster algorithm for the single source shortest path problem with few distinct positive lengths, J.
Discrete Algorithms 8 (2) (2010) 189–198.
[32] J. López, D. Pérez, E. Zalama, J. Gómez-García-Bermejo, Bellbot-a hotel assistant system using mobile robots, Int. J. Adv. Robot. Syst. 10 (1) (2013) 40.
[33] J. López, D. Pérez, E. Paz, A. Santana, WatchBot: A building maintenance and surveillance system based on autonomous robots, Robot. Auton. Syst. 61
(12) (2013) 1559–1571.
[34] J. López, D. Pérez, M. Santos, M. Cacho, Guidebot. a tour guide system based on mobile robots, Int. J. Adv. Robot. Syst. 10 (11) (2013) 381.
[35] J. López, P. Sánchez-Vilariño, R. Sanz, E. Paz, Implementing autonomous driving behaviors using a message driven Petri net framework, Sensors 20 (2)
(2020) 449.

20
J. López et al. Simulation Modelling Practice and Theory 116 (2022) 102430

[36] J. Flochova, A Petri net based supervisory control implementation, in: SMC’03 Conference Proceedings. 2003 IEEE International Conference on Systems,
Man and Cybernetics. Conference Theme-System Security and Assurance (Cat. No. 03CH37483), Vol. 2, IEEE, 2003, pp. 1039–1044.
[37] W. Chung, G. Kim, M. Kim, Development of the multi-functional indoor service robot PSR systems, Auton. Robots 22 (1) (2007) 1–17.
[38] N.J. Dingle, W.J. Knottenbelt, T. Suto, PIPE2: a tool for the performance evaluation of generalised stochastic Petri nets, ACM SIGMETRICS Perform. Eval.
Rev. 36 (4) (2009) 34–39.
[39] M. Olivier, Cyberbotics LTD-webotstm: Professional mobile robot simulation, Int. J. Adv. Robot. Syst. 1 (1) (2004) 40–43.
[40] B. Gerkey, R.T. Vaughan, A. Howard, The player/stage project: Tools for multi-robot and distributed sensor systems, in: Proceedings of the 11th International
Conference on Advanced Robotics, Vol. 1, Citeseer, 2003, pp. 317–323.
[41] G.E. Box, A note on the generation of random normal deviates, Ann. Math. Stat. 29 (1958) 610–611.

21