Shared and automated mobility has been prevailing and changing the paradigm of next-generation urban transportation systems, leading to disruptive concepts such as Mobility-as-a-Service (MaaS) and transportation network companies (TNCs), such as Uber and Lyft. TNCs have been efficiently identifying the missing links between demands (customers) and supplies (mobility service providers), and bridging them through innovative platforms and smartphone apps to facilitate the completion of mobility needs. In spite of never-ending criticisms to TNCs such as avoiding government regulations and inducing excess traffic demands [1
], they keep evolving by providing feasible solutions, such as ride-hailing, pooled TNCs, and different tiers of transportation needs [3
Recently, new car-pooling services emerging in major U.S. cities [5
] offer the most affordable ride price in exchange for a little walk of customers to/from designated pickup and drop-off (PUDO) locations with respect to their origins and destinations. Such flexibility in PUDO locations can be considered as a demand-side cooperative strategy. It is similar to the travelling salesman problems (TSP) with moving targets, which have been explored in the field of operation research for years [6
]. Such flexibility in travel behaviors of customers may impact overall system efficiency and sustainability [8
], such as vehicle miles traveled (VMT), emissions, and energy consumption, although the emerging on-demand mobility services rely on many other types of studies, such as studies of existing services, stated preference studies, and policy studies [9
]. However, whether the anticipation holds and how much SAM (shared automated mobility) service will be impacted due to the demand-side cooperation is still unknown.
To address all the challenges mentioned above, or in other words to assess the mobility and sustainability impacts of SAM services with demand-side cooperation, this paper proposes a demand-side cooperative (DC) SAM service optimization model and an open-sourced microscopic simulation platform. The DC ride matching is formulated as a capacitated vehicle routing problem with repositioning (CVRPR) and is solved by a commercial solver (Gurobi). Under the operational constraints, such as SAV seat capacities and maximum walking distances, the DC ride matching strategies aims to optimize the overall profit of the proposed SAM service, which considers both maximizing the serving rate (to obtain more revenue) and minimizing the travel distance, travel time, and energy consumption (to reduce the fleet operational cost). The proposed service can potentially benefit the customers and the entire transportation system by reducing the detoured portions and dead-heading time of SAV trips. The proposed DC-SAM is framed in the Simulation of Urban MObility (SUMO), an open-source and multi-modal microscopic traffic simulation tool. It is capable of modeling not only vehicular traffic dynamics in detail but also customer behaviors (including customer–vehicle interactions) via its unique application programming interfaces (APIs), i.e., “TraCI” [10
]. This enables the proof-of-concept study of the proposed DC-SAM service in a dynamic environment where the ride matching and repositioning (i.e., re-optimization) are performed continuously as the system evolves (e.g., new on-demand ride requests pop up). In addition, a real-world network of New York City (NYC) is coded and ride demands as well as background traffic are synthesized to evaluate the performance of the proposed DC-SAM service.
Compared to existing studies, the major contributions of this paper involve but are not limited to:
Development of a demand-side cooperative (on-demand) shared automated mobility (DC-SAM) service which can further improve system efficiency.
Modeling of the proposed system in an open-source and multi-modal microscopic simulation platform in a dynamic environment with more realistic settings, including real-world roadway network, background traffic impacts, SAV dynamics, and customer–SAV interactions. This platform has the potential for extended microscopic traffic modeling and analysis related to MaaS.
The rest of this paper is organized as follows: Section 2
introduces the background information and the relevant literature on SAM modeling and fleet operation. The proposed framework of DC-SAM system and the ride matching algorithm are illustrated in Section 3
, followed by a NYC network case study as Section 4
. The details of discussion, including comparison study and comprehensive sensitivity analyses are elaborated in Section 5
. The last section concludes this paper with further discussion and future work.
On-demand shared mobility has been considered as a cost-effective strategy to fulfill transportation demand without compromising traffic congestion, fuel consumption and air quality [11
]. In particular, ridesharing refers to the rides in a vehicle among individual travelers (a driver or customer) whose itinerary is in the proximity of both space and time, although the system in which customers may not share the vehicle at the same time can also increase congestion [1
]. With the emergence of smartphones and the Internet, for-hiring pooled services research and development has focused on online ride-matching programs as well as real-time traveler information delivery. Thanks to both the rapid advances in information and communication technologies and increased concerns for contemporary transportation issues (e.g., congestion, environment, and parking), more affordable, secure, and accessible Mobility on Demand (MOD) [12
], shared ride [13
], and pooled TNC services have been provided continuously by transportation network companies (TNCs) via smartphone apps, such as Uber and Lyft [14
]. Based on positional elements, Furuhata et al. proposed a systematic classification scheme over the ridesharing patterns and discussed some significant challenges and future directions, mainly from the perspective of matching agencies [15
Due to the significant progress of autonomous vehicles (AV) in the past decade, the convergence of AV technology and pooled TNC service, i.e., shared automated mobility (SAM) as well as shared automated vehicles (SAVs), has received considerable attention and holds great promise for transforming urban land use as well as alleviating many traffic-related issues in city regions. Some studies started from a limited-scale of SAV deployment or designated transit service scenarios [16
]. Burns et al. numerically simulated a city-wide SAV fleet operation, where homogeneous trip rates and simplified distance estimation were assumed to reduce computational load [18
]. Brownell proposed an autonomous taxi network (ATN) system with a ridesharing option as an alternative transit solution [19
]. A simplified agent-based model was proposed by Fagnant and Kockelman to estimate the effectiveness of SAVs by replacing the fleet of private vehicles in Austin, TX area [20
]. Later on, they improved their modeling capabilities by introducing the dynamic ridesharing option [21
]. Similarly, Zhang et al. developed an agent-based model for SAV operation with the consideration of dynamic ridesharing to explore its impacts on urban parking demand (with the potential to eliminate up to 90% of parking spaces) [22
]. Recent studies evaluated the opportunities of the SAM system to serve as the feeder to facilitate public transit operation [23
]. When integrating with transportation electrification, the shared autonomous electric mobility (SAEM) system may have profound impacts on both transportation and power grid operations [24
]. However, almost all the modeling efforts are limited to numerical analysis or agent-based approaches, which cannot represent the traffic dynamics in realistic manner or the delicate interactions between different road users (including both vehicles and customers). Very few studies have implemented the ridesharing models in a microscopic simulation environment. Alam and Habib used VISSIM to simulate the impacts of SAV operation in Halifax, Canada, but a rule-based SAV dispatch algorithm was deployed for simplicity, and the results are far from being optimal at the system level [27
From a mathematical perspective, the dynamic ridesharing (DRS) problem can be categorized into the well-known vehicle routing problem (VRP), or more specifically dynamic VRP [28
]. Due to the computational complexity of VRP, a myriad of studies have been focused on developing efficient heuristic approaches to solve DRS problems under different scenarios [31
]. Furthermore, with the introduction of mobile apps and improved services from TNCs, variants of DRS problems have emerged. Wang considered a DRS problem where drivers or riders may accept or reject the ride-matching assignment provided by the system [33
]. Simonetto et al. proposed a computationally efficient dynamic ridesharing algorithm based on a linear assignment problem and federated optimization architecture [34
]. In a follow-up study, they examined the impacts of cooperation and competition between ridesharing companies through the Mobility-as-a-Service (MaaS) platform, and showed that the competition could worsen the on-demand mobility service, especially in the presence of customer preferences [35
]. To improve system efficiency, Coltin and Veloso proposed a heuristic algorithm to coordinate ridesharing routes and matching, which may smoothly transfer customers between different vehicles [36
Most of the aforementioned DRS studies, however, assumed door-to-door services. Only a few consider more flexible pickup and drop-off (PUDO) locations, which may potentially provide system-wide benefits for the ridesharing service due to the demand agglomeration effects [37
]. Li et al. developed an enhanced ridesharing system where the users may be collectively picked up or dropped off, and the preliminary numerical study showed that the proposed system could improve the overall travel time [38
]. Zhao et al. also relaxed the PUDO location constraints in the ridesharing problem and performed a case study in Matlab [39
]. Although the results from these studies were promising, their validation was limited to numerical analyses only without considering the dynamic nature of the system. Therefore, modeling and evaluation of the proposed DRS system in a microscopic traffic simulation environment would be very valuable, which is a focus of our paper.
4. Case Study
The proposed demand-side cooperative shared automated mobility service (DC-SAM) simulation was implemented and studied in SUMO with the New York City (NYC) network (see Figure 4
). The Open Street Map (OSM) provides the detailed roadway network and default traffic signal plans in the region, which is imported in the SUMO platform. Shared automated vehicles (SAVs), SAV routes, background traffic, and movements of customers (either waiting or on-board) are illustrated in Figure 4
The SAM demand was extracted from a New York City Taxi and Uber Trips study [47
], which provided a vast amount of individual taxi trips in the city from January 2009 to June 2015. In this paper, a small sample from one taxi company’s trip data on 1 June 2015 was selected. The original information of each trip includes pickup and drop-off (PUDO) locations, PUDO times, customer counts, vendor information, and transaction data (i.e., fare). In the simulation, a total of 140 trips were selected as the baseline SAM demand and synthesized according to the PUDO locations (as the surrogates of origins/destinations) and pickup time (as the surrogate of request time).
4.1. Simulation Setup
Four vehicles with three available seats (i.e., the maximum occupancy per vehicle is 3) were set as the SAV fleet to serve the SAM demand over the network. These SAV behaviors were finetuned in the SUMO simulation by adjusting the driver imperfection indicator to be 0 (i.e., perfect driving), and setting the desired time headway to be 1.5 s, which is different from the background traffic of human-driven vehicles (i.e., 2 s). At the beginning of the simulation, these SAVs were assigned to random locations and got ready for the execution of different ride matching models: 1) heuristic matching; 2) optimal matching without demand-side cooperation (ONDC); and 3) optimal matching with demand-side cooperation (ODC). Within every system optimization time window, the service coordinator monitored available SAVs and unserved demands, based on which a designated pickup/drop-off plan was calculated depending on the selected ride matching models. For the optimization models (ODC and ONDC), a high enough revenue (10,000 units, a unit = 1 dollar or mile) was set to incentivize SAVs to serve as many demands as possible. The travel cost from one place to another is proportional to the route distance of the least-duration path, which depends on the time-varying traffic conditions. After ride matching, the designated SAV would move to pick up and drop off customers according to the assigned itinerary. To guarantee that the demand can be served exhaustedly, a long enough simulation horizon (60,000 steps) was used. In addition, background traffic randomly generated at the rate of one trip per second was introduced into the simulation network uniformly over time. The computing platform to conduct the simulation is set up as follows: CPU—Intel i7 8700; GPU—Nvidia 1660 Ti; OS—Windows 10 version 1909; SUMO 1.2.0; and Gurobi 8.1.1.
It is noted that a small-scale (in terms of optimization problem) test was presented in this paper to prove the concept (i.e., to demonstrate the proposed DC-SAM service). A major concern is the computational efficiency. It is well known that off-the-shelf optimization solvers are not able to address instances with roughly more than 10 vehicles for pooled TNC services with floating targets. In this study, the seat capacity was selected as 3 to be consistent with the setting of a small vehicle. Our trial and error tests showed that four vehicles with capacity of 3 seemed to reach the computational limitation that the Gurobi optimization solver could handle. In addition, the number of alternative PUDO locations would impact the computational time. In this study, each origin or destination of the request in the simulation study has up to 4 alternative locations, including itself. The computational efficiency problem may be solved by more efficient algorithms or more powerful high-performance computing (HPC), which is out of the scope of this paper and will be another important future research direction.
4.2. Determination of System Optimization Time Window
System optimization time window refers to the time interval when all the updated information about riding requests and SAV statuses would be collected for the service coordinator to perform the ride matching. It is considered as one of the most critical parameters that governs the tradeoff between SAM performance and computational efficiency. Sensitivity analyses on this parameter have been conducted to evaluate its impacts. As shown in Table 3
, if the time window is short (e.g., 1 s), the service coordinator can respond to the ride request instantly as long as there is any SAV available. This may result in higher overhead in computational time and sub-optimality in terms of system performance because there are less opportunities for SAVs to coordinate with each other for serving the customers. On the other hand, if the time window is too long (e.g., 500 s), many more customers and vehicles will be considered in the optimization which may lead to significant computational burden for the Gurobi Optimizer and unsatisfactory customer experience. In addition, due to the change in traffic dynamics, a longer time window might not guarantee better system performance.
It turns out that for the test scenarios (i.e., 140 SAM trips, 4 SAVs with 3 seats capacity per vehicle, and the given background traffic), the “best” system optimization time window is 120 s in terms of the majority of performance metrics listed in Table 3
, such as VMT, VHT, TDF, VEC, and CPU time (in second). For other parameters, e.g., CWT, WKT, and WKM, the values for the 120 s case are comparable to the others. Therefore, in the following simulation studies, the system optimization time window is set as 120 s.