Transportation is traversing a period of big transformations driven by Information and Communication Technology (ICT). For instance, the ubiquitous connectivity guaranteed by 3G and 4G has triggered the emergence of ride sharing services, e.g., Uber and Lyft, in which users reserve a ride through a smartphone app and service providers match them to a fleet of vehicles. Goldman Sachs quantifies the importance of these services by predicting a market of 285 billion dollars in 2030 . In more and more cities, ride sharing services are also determining a transformation of every-day life . This revolution will become even deeper when these services will be provided by Autonomous Vehicles (AVs). Autonomous Mobility on Demand (AMoD) services  will be very cheap for the users, since providers will not have to sustain the cost of labor of the drivers.
One reason for the efficiency of these systems is that vehicles can be shared among many users. To do so, efficient and scalable algorithms are needed. While the Vehicle Routing Problem  has been studied from the 1950s, the success of ride sharing systems has lead to a renovated interest in this decade, where the problem has been specialized to the case of matching ride requests from passengers to available vehicles, while respecting some constraints on users’ waiting and riding time. A particular focus has regarded the computation of condensed vehicle trips to properly aggregate many rides in order to minimize provider’s costs while keeping the user quality of level acceptable. The request-vehicle matching problem has been shown to be NP hard 
. Therefore, a vast literature has developed to propose “good” heuristics with a reasonable computation time to be used in practice and has resorted to simulation to evaluate them. Unfortunately, up to now no reference simulation tool has emerged for this, which is shown by the fact that most of the authors have been forced to build from scratch their own case-specific simulator. The negative consequences are:
Waste of time and effort, to create every time a simulator.
Impossibility to build on the effort of past research.
Difficulty for the community to reproduce and verify results.
On the other side, there are few exceptions of complex transportation simulation tools extended with models of ride sharing systems. However, they are not suitable for the researchers interested in the development of algorithms for ride-sharing, whom we target in this work. The reasons are:
They require to specify scenarios with high level of realism, like economic indicators of the population and of the area, which are not usually available.
Even if available, it takes a long time and effort to figure out how to set them up into the simulators, which would instead be preferable to spend in the inner workings of the algorithms.
They lack flexibility: when developing an algorithm, it is necessary to test it in a vast range of scenarios, instead of just super-realistic one, to generalize the findings.
The level of detail transportation represents an overhead: part of the computation time is spent in representing the detailed movement of vehicles at millisecond scale, which has no big impact on the ride sharing logic.
For these reasons, transportation simulation tools are to be used a-posteriori when, for instance, a transportation authority or company wants to check what is the impact of a ride sharing strategy, already developed and thoroughly studied, on the particular scenario of interest.
In this paper we present AMoDSim, a simulation framework open to researchers in future-generation ride-sharing systems whose design goals are:
Launching massive simulation campaigns to simultaneously test the performance of the algorithms under study, under different settings, is easy and scalable.
By means of modularity, it is easy to implement new algorithms, with minimum modification of the other components.
Results on the performance for both the provider and the user perspective are produced automatically and are simple to analyze.
The code is available111https://github.com/admaria/AMoDSim under the CC BY-NC-SA 4.0 license. The rest of the paper is organized as follows: In Section 2 we review the work in simulation of ride sharing systems. In Section 3 we present the model of AMoD used in AMoDSim. In Section 4 we describe its architecture and in Section 5 we showcase it in a case study in which we compare several provider and user-related metrics of two different matching algorithms.
2 Related Work
In this section we describe the state of the art of the research on autonomous mobility on demand and future generation ride sharing systems, focusing on the simulation tools used. We divide this research in works that use case-specific simulators and complex transportation simulators. The limitations of both has been discussed in the previous section.
2.1 Work Based on Case-Specific Simulators
We emphasize that no code has been made public with any of the studies listed in this subsection, nor the simulators have been described enough to be reproducible. This reinforces the utility of our effort. Santi, Frazzoli et Al. published a series of papers [22, 7, 23] where they proposed mathematical formulations of ride sharing problems and heuristics to solve them. Case studies are shown in New York. Similarly, Ma et Al.  study ride-sharing algorithms using GPS taxi trajectories collected in Bejing. Agatz et Al.  built a simulator for a case study in Atlanta. Within their simulator, an agent can subscribe to a provider either as a rider or a driver. The study better represents systems like BlaBla Car , in which a traveler can publish her future trip in a web portal and other users can hop-in. These systems are now called “carpooling” and are different from ride sharing systems like Uber and Lyft and the future AMoD, in which (i) drivers are continuously operating for hours just to serve other individuals’ trips and (ii) requests for rides arrive continuously in real time and are not announced in advance. Other case-specific simulators were developed for case studies in Seul and Boston in  and , respectively.
2.2 Work Based on Complex Transportation Simulators
Some case studies have been performed extending commercial transportation simulators, like Aimsun [20, 18]. However, commercial tools are usually not available to researchers and their code is closed, impeding the verification and the reproduction of results. To the best of our knowledge, three simulation tools developed by academic institutions have been extended and employed in studies related to AMoD, namely SimMobility  and MATSim [10, 9] and SUMO. The main issue with the first two is the level of complexity that the researcher is required to handle and the performance. They are agent-based, i.e., they simulate the behavior of each single traveler through transportation-specific economic models. In order to do so, the researcher must construct first a synthetic population and describe the economic indicators of the urban network. As discussed in Section 1, this is overkill for research focused on algorithms, which is what we target here. The unsuitability of these tools is testified by the fact that: (i) they are generally used, at least as far as published research visible to us is concerned, only by the very same group that developed them and (ii) researchers have preferred to craft their own case-specific simulators instead of using them. SUMO is a microscopic simulator that has been employed in a recent case study on AMoD in the city of Milan. However, that study does not fill the gap we aim to fill. First, SUMO is a purely microscopic simulator, i.e., it computes the detailed movement of each vehicle,222A particular version of SUMO, called SUMO MESO, is intended to reduce the details in vehicle movement simulation. However, we are not aware of any published study on AMoD systems based on SUMO MESO. which is an overhead that we want instead to avoid, since it has limited interest when studying the dispatching logic in an AMoD system. Second, SUMO does support natively Mobility on Demand services and the authors of  had to write from scratch this functionality, which, however, they do not make publicly available. Third, SUMO needs detailed input, that the authors needed to obtain by cross-correlating several data-sources (Google APIs, mobile phone traces, etc.), while the choice we made in AMoD is to streamline the input definition, sacrificing some realism. Finally, is it not possible in  to specify user-specified quality of service requirements.
2.3 Other work
NOT IN THIS DRAFT
3 Model of Autonomous Mobility on Demand
We now present the model of AMoD service implemented into the simulator. The model includes a fleet of vehicles, a coordinator managing it and users. Users send trip requests to the coordinator, which runs matching algorithms or simply orchestrates the distributed computation running in the vehicles, in order to decide how to match them to the available vehicles. A trip request consists of two stop-points, one for the pick-up and one for the drop-off. Each stop point is a tuple , where is the pick-up or drop-off point, is the preferred time at which the user wishes to be picked up or dropped off, is the maximum extra-time the user tolerates to be picked up or dropped off, with respect to the preferred time.
At any given time, each vehicle has a set of planned stop-points organized in a certain sequence , that we call schedule. Each schedule is associated with a cost , which can be defined in different ways to take into account provider or user-related metrics. For example, this cost could be the kilometers traveled to accomplish that schedule, or some indication of the travel or waiting time of the users served by that schedule. The goal of the provider is to create and continuously update the schedule of each vehicle of its fleet, in order to optimize the costs , subject to respecting the time constraints of all the users. Observe that this model is general enough to represent different types of optimization: (i) both provider cost or user level of service can be optimized, as this boils down to the way the cost is defined; (ii) one can simply study the overall cost optimization, or min-max optimization, etc.; (iii) the optimization can be both centralized, in case a single coordinator decides all the schedules , or distributed, in case, for instance, each vehicle optimizes its own schedule. While the model is general, we have currently only implemented the strategies described in Section 3.2.
3.1 Time constraints
We define a schedule of a vehicle feasible, if the time constraints of all its stop-points is satisfied. Let us suppose and that is the time needed to complete , i.e., the time for the passenger to board (alight), in case of pick-up (drop-off), that the current time is and the current vehicle location is . Let us denote with
the estimated time to go from a locationto . Then the estimated time at which the stop-point will be served is:
The estimated delay of each stop-point , for . The provider must only compute feasible schedules for each vehicle in the fleet. AMoDSim is able to simulate on-line optimization algorithms, in which the schedules are continuously modified. To avoid violating some user constraints, the feasibility should be checked at any modification. For example, suppose we modify by inserting a new stop-point at position , obtaining a new schedule . The detour the vehicle does to serve determines an additional delay on all the stop-points after the -th. If we denote with the estimated stop-point time of after the insertion, the additional delay is and it is easy to show that:
where is the time for alighting or boarding related to . To check whether the modified schedule is feasible, not only must we check that the time constraints of the new are satisfied, but also that the time constrains are satisfied for all the stop-points already present in the schedules, i.e., for .
3.2 Examples of optimization strategies
To give a more concrete idea of the model we discussed in the previous section, we now describe two heuristics we implemented in AMoDSim and some possible assumptions about the request constraints expressed by users. We adopt such heuristics and assumptions in the case study of Sec. 5. However, we emphasize that the simulator is more general and can be used in different ways.
Recall a request sent by a user is composed by a stop-point for the pick-up and another for the drop-off. We assume that the user would like to be picked-up immediately, i.e., and to be dropped-off as in the ideal case in which a vehicle is immediately at her disposal and can bring her to the destination in the shortest path, without detours, i.e., .
We implement two optimization strategies, namely Radio-Taxi and Insertion Heuristic. With the former each vehicle can serve one passenger at a time, while the latter allows ride sharing, i.e., the same vehicle can serve multiple passengers at a time.
We first describe the Insertion Heuristic, loosely inspired by . The cost function is chosen in order to represent the user experience. More precisely, the cost of a schedule is the sum of the estimated delays , as defined in Sec. 3.1, of all its stop-points, i.e., . The Insertion Heuristic attempts to minimize the marginal cost when serving an additional request. Suppose a new request is sent, consisting of the stop-points for the pick-up and drop-off, respectively. Assigning the new request to any vehicle, will increase the cost of its schedule, i.e., the sum of the delays suffered by its stop-points. Let us take any vehicle and denote with the schedule obtained from by inserting the pick-up in the -th position and the drop-off in the -th position, with . If the modified schedule is infeasible, we set . We compute the best placement of drop-off and pick-up, which minimizes this increase in cost, i.e.,
We repeat the same computation for all the vehicles and we choose the one whose marginal cost is minimum, i.e.:
Finally, we assign the request to vehicle and place the pick-up and drop-off in the -th and -th positions, respectively.
strategy is a constrained version of Insertion Heuristic, in that we impose that each pick-up be followed in any schedule by the correspondent drop-off, which ensures that at most one passenger is in the vehicle at any moment.
3.3 Vehicle Movement
All vehicles travel through the links of the network, i.e., roads, at a predefined cruising speed. Each link has a length, which determines the time needed to traverse it. Obviously, when a vehicle alternates between a stop-point and another, its speed does not go from 0 to the cruising speed and back to 0 instantaneously. Therefore, we introduce a parameter (), which represents the time lost for accelerating (decelerating). When a vehicle reaches a stop-point , we keep it in that node for an additional time , before sending it again to the link toward the next stop-point.
4 Software Architecture
AMoDSim is a simulation platform developed on top of Omnetpp. It is designed to be configurable, modular, event-based, algorithm-oriented and extensible with custom optimization strategies and network topologies.
The simulator models the road network as a set of nodes, i.e., geographical locations that could be origins and destinations of the service requests, connected through links, i.e., road connections between different locations. A vehicle is represented as a packet traveling through the links. A node is a compound-module composed of three sub-modules: queue, routing and application. A node has one queue module per each outgoing or incoming link. Each Queue module forwards (receives) packets to one of the outgoing links (from one of the incoming links). The Routing module (i) decides to which of the outgoing links a packet should be forwarded and (ii) checks, every time a vehicle passes, whether the node is one of its stop-points, in which case the vehicle is passed to the Application module. The Application module implements multiple functions:
It generates user requests, as pairs of stop-points (one for the pick-up and one for the drop-offs). The generation obeys to a pre-determined stochastic process. So far, Poisson arrivals are implemented.
It receives all the vehicles for which the node in question is a stop-point, checks the next stop-point, accessing a data-structure storing all the schedules and sends the vehicle to it. At the same time, it also notifies the coordinator, so that it can update the schedule in question.
It keeps the vehicles that are idling at the node with an empty schedule. In this case, it also receives a signal from the coordinator if a new schedule is assigned to the idling vehicles and sends them to their new stop-point.
The Coordinator manages the incoming trip requests, implements the trip allocation strategies and assigns each request to a vehicle, according to the implemented optimization strategy. It has been designed to be easily extensible with custom allocation strategies. We implemented a modular Coordinator within a hierarchical structure where the superclass implements the standard functions. One can extend such superclass and implement the logic of her matching algorithm.
4.1 AMoD Performance Metrics
AMoDSim collects data during its execution and produces a set of results that enable statistical analysis related to both the point of view of the provider and of users.
Regarding the provider viewpoint, AMoDSim provides the following information per-vehicle: (i) distance traveled, (ii) number of passengers on board, (iii) requests picked-up but not yet dropped-off, (iv) number of pick-ups already in the schedule but not yet completed, (v) total requests assigned, (vi) the time the vehicle has spent idle or with passengers, where ranges from 1 to the number of per-vehicle seats.
Moreover, for each of the collected metric, AMoDSim computes aggregated fleet statistics, as sum, minimum, maximum, mean, standard deviation, median and 95th percentile.
At each time frame, the following information about the users’ requests received up to that time are collected: (i) length of the submitted requests, (ii) number of requests that the system has received and assigned to the vehicles, (iii) number of requests that the system has rejected because it could not serve them within the time constraints, (iv) number of requests that the system is processing at the snapshot time.
The level of quality for the users is described by the following per-user quantities: (i) time that users spent in the pick-up location waiting for the vehicle, (ii) actual time that the user spent in the vehicle, (iii) Stretch, i.e., the ratio between the actual trip time and the preferred one, which is the time between the preferred pick-up and drop-off times.
5 Case Study
We showcase the capabilities of AMoD in a simple case study, in which we launched a campaign of 1800 simulations. We compare the performance of the Insertion Heuristic to the Radio-Taxi. We show how AMoDSim allows to find interesting insights on the AMoD systems and answer questions like: what is the fleet size needed to sustain a certain request rate? Which kind of vehicles should be employed (of how many seats)? What is the sharing level, i.e., how effectively are we able to condensate different user rides in few vehicle schedules? By how much sharing rides allows to reduce the fleet size needed? How efficient is vehicle usage, e.g., how much time vehicles are idle? We underline that the findings we get are not necessarily general properties of every AMoD systems, but depend on the particular optimization strategy we adopt and the particular scenario. Therefore, our goal is to show how other researchers can obtain similar findings with AMoDSim about their strategies and their scenarios. Finally, we show the computational performance of AMoDSim. We are aware that the quality of AMoDSim cannot be validated only by the case study we present here. Part of our future work is to apply AMoDSim to different scenarios and to validate by comparing it with other simulators. This latter point requires careful thinking, since other simulators are not directly comparable, for the reasons discussed in Section 1. We also believe that the best way to make AMoDSim reach full maturity is its adoption by other researchers for their studies, which would help in understanding and improving its limits.
We use Manhattan Grid that covers an area of , equivalent to Manhattan, with static link travel times as in . We consider different configurations of the fleet of vehicles to study the performance of multiple ride-sharing degrees and fleet size. We perform simulations starting from single-seater up to 10-seater minibus and a fleet of 500 up to 9000 vehicles. We assume a cruising speed of and a constant acceleration and deceleration of mpss, resulting in a (see Sec.3.3) as in . Thus, the vehicles have a constant acceleration (deceleration) of mpss (mpss). Users submit requests with Poissonian arrivals as in  with rate ranging from 20 up to 640 requests per hour per compatible with the scenarios employed in the literature [7, 15]. As for the of a pick-up (drop-off) stop point , i.e. the time need for boarding (alighting), we assume 5 seconds (10 seconds) as in . All results are collected running 4h simulations.
In this section, we first give an example of analysis possible in AMoDSim and then discuss its computational performance.
5.2.1 Sharing opportunities for an AMoD provider.
We investigate the factors determining the sharing degree and its impact on the provider and the users. The sharing degree is the capacity of an AMoD provider to exploit the fact that a single resource (vehicle) can be used to serve multiple requests. This concept, at the core of the sharing economy, cannot be quantified in a single value, but emerges from a set of different indicators that we discuss here. Fig. 2 shows the performance of Radio-Taxi. It is clear that the system is saturated: only 35K requests are served over 65K and the number of idle vehicles goes down to zero in few minutes. Fig. 3 shows that under the same conditions, Insertion Heurisitc with a fleet of 4-seater 2K vehicles allows to meet all the requests. Observe also that the total number of kilometers traveled, a proxy for the provider cost, decreases considerably by increasing the number of seats, since the sharing opportunities increase.
The sharing degree is well summarized by Fig.4, which shows the fraction of time vehicle spend, on average, with 0 (idle), 1, 2, … passengers. Intuitively, if we allow users to express a tight extra-time constraint , the sharing opportunities shrink and we can just afford few passengers at a time, in order to meet the constraints of all of them.
Note that, even with a long , more than 6 seats are rarely utilized. This suggests that, if we want to implement a minibus-like service, strategies different from Insertion Heuristic must be used (which is an interesting subject to investigate). Observe also that high capacity vehicles would be fully utilized only if is too tight. In other words the type of vehicles to be used depends on the type of service that the provider wishes to offer and the level of service users expect.
5.2.2 Mean waiting time.
In a RadioTaxi-based AMoD system, the only way to serve a higher service demand is to increase the fleet size. Moreover, a large fleet reduces the Waiting Time (WT), which is shown in Fig. 4(a). With the Insertion Heuristic another parameter impacts the user experience, namely the vehicle seats. In Fig. 4(b) we use large points to indicate the first value of request rate in which we observed the system is in saturation, i.e., it is not able to serve all the requests, e.g., Fig.2. Observe that when the system is not saturated, the best WT are measured with 1 seater vehicles, since each is dedicated entirely to a single user each time and the user does not make detours due to sharing with others. However, the system saturates at only 160req/h/. On the contrary, larger vehicles allow to serve a more intense demand without saturation, which translates in a better WT for the users.
5.2.3 Computation time and memory consumption.
In this section we discuss the single-run computation time and the peak memory consumption of AMoDSim, which we observed in our case study. Note that comparison with other simulators is not possible here for the reasons discussed in Sec.2: the case-specific simulators are not available and the transportation simulators are out of scope and would have required input data that do not exist for the scenarios considered. Fig. 5(a) and 5(b) show how both the computation time and the memory consumption grow with the number of vehicles and the rate of requests, as expected. Fig. 5(c) shows how the increase in computation time is significant moving from single-seater to 2-seater vehicles and is low moving from 4-seater to 10-seater. This may be due to the fact that vehicles spend most of the time with no more than 4 passengers anyway (Fig.4).
NOT IN THIS DRAFT
NOT IN THIS DRAFT.
-  BlaBla Car. https://www.blablacar.com/.
-  MESO: Mesoscopic version of SUMO. http://sumo.dlr.de/wiki/MESO.
-  OMNeT++. https://www.omnetpp.org/.
-  AA.VV. Vehicle Routing. SIAM-MOS, 2nd edition, 2014.
-  N. A.H. Agatz, A. L. Erera, et al. Dynamic ride-sharing: A simulation study in metro Atlanta. Transport Res B-Meth, 45 ‘(9):1450–1464, 2011.
-  Sabina Alazzawi, Mathias Hummel, Pascal Kordt, Thorsten Sickenberger, Christian Wieseotte, and Oliver Wohak. Simulating the Impact of Shared , Autonomous Vehicles on Urban Mobility - A Case Study of Milan. In SUMO User Conference, 2018.
-  J. Alonso-Mora, S. Samaranayake, et al. On-demand high-capacity ride-sharing via dynamic trip-vehicle assignment. PNAS, 114(3):462–467, 2017.
-  R. Basu, A. Araldo, et al. Implementation and Policy Applications of AMoD in multi-modal activity-driven agent-based urban simulator SimMobility. Transport Res Rec, 2018.
-  J. Bischoff and M. Maciejewski. Simulation of City-wide Replacement of Private Cars with Autonomous Taxis in Berlin. In ANT. Elsevier Masson SAS, 2016.
-  P. M. Boesch, F. Ciari, et al. Autonomous Vehicle Fleet Sizes Required to Serve Different Levels of Demand. Transport Res Rec, 2542:111–119, 2016.
-  S. Burgstaller, D. Flowers, et al. Rethinking Mobility: The ’pay as you go’ car: Ride hailing just the start. Technical report, 2017.
-  R. R. Clewlow and G. S. Mishra. Disruptive Transportation: The Adoption, Utilization, and Impacts of Ride-Hailing in the United States. Technical report, UC Davis, 2017.
-  J. Elpern-Waxman. Transportation Terms: Dwell Time, 2017.
-  M. Hyland and H. Mahmassani. Dynamic Autonomous Vehicle Fleet Operations: Optimization-Based Strategies to Assign AVs to Immediate Traveler Demand Requests. Transport Res. C-Emer, 92:278–297, 2018.
-  J. Jaeyoung, R. Jayakrishnan, et al. Design and Modeling of Real-time Shared-Taxi Dispatch Algorithms. TRB 92nd Annual Meeting, 2013.
-  J. Jung, R. Jayakrishnan, et al. Design and Modeling of Real-time Shared-Taxi Dispatch Algorithms. In TRB Annual Meeting, volume 8, 2013.
-  A. Y. S. Lam, Y. Leung, et al. Autonomous-Vehicle Public Transportation System: Scheduling and Admission Control. IEEE Trans. Intell. Transp. Syst., 17(5):1210–1226, 2016.
-  M. P. Linares, L. Montero, et al. A Simulation Framework for Real-Time Assessment of Dynamic ride sharing demand responsive transportation models. In WSC, 2016.
-  S. Ma, Y. Zheng, et al. T-Share : A Large-Scale Dynamic Taxi Ridesharing. In ICDE, 2013.
-  L. M. Martinez, G. H. A. Correia, et al. An agent-based simulation model to assess the impacts of introducing a shared-taxi system: an application to Lisbon. JAT, 49:475–495, 2015.
-  S. Robinson. Measuring bus stop dwell time and time lost serving stop with london ibus automatic vehicle location data. Transport Res Rec, 2352(1):68–75, 2013.
-  P. Santi, G. Resta, et al. Quantifying the benefits of vehicle pooling with shareability networks. Proc. Natl. Acad. Sci., 111(37):13290–4, 2014.
-  M M Vazifeh, P. Santi, et al. Addressing the minimum fleet problem in on-demand urban mobility. Nature, 557(May), 2018.