Owning or sharing autonomous vehicles: comparing different ownership and usage scenarios

The impact of autonomous vehicles (AVs) on urban mobility systems is an increasingly discussed topic in recent years. There is currently some discussions about different ownership models and their consequences. Regarding autonomous vehicles (AVs), two ownership models are being considered for future transportation systems. These are: autonomous vehicles as a public service or individual owning ownership. The first ownership model is based on AVs operating within an on-demand (taxi) service while the second proposes private vehicle ownership combined with offering the AV to other users when not used by its owner and thereby partially financing the vehicle’s acquisition cost. In addition to the ownership model comes the possibility of sharing rides. The main difference when sharing a trip is that an individually-owned vehicle always prioritizes its owner. Based on an existing approach for assessing the potential of predefined meeting points in a ride-sharing service, we develop a method for assessing the sharing potential of those different variants. We consider the number and distance of shared trips, and thus, we evaluate the potentially saved vehicle kilometers. We analyze several ownership and sharing scenarios on a case study for New York and Paris. The results demonstrate that sharing AV trips has the potential of increasing the system-wide matching rate as well as saving up to 25% of the overall traveled distance.


Introduction
With the increasing urbanization rates, a swift growth in people demand for transportation is taking place nowadays.This increasing demand is associated with a set of challenges, such as limited oil supplies and growing levels of pollution and traffic congestion.These challenges have pushed research towards more sustainable systems of transportation [20].Autonomous mobility services and their potential impact on existing mobility systems represent one of those opportunities that can help in replying to this growing transportation demand while providing an enhanced traveling experience.According to ( [2,18]), fully autonomous vehicles (AVs) are expected to make traveling safer, more comfortable, more sustainable, and to reduce traveling costs.If all those assumptions are to become true, autonomous vehicles can dramatically change the urban form especially that they might be used as a shared transportation service.The potential deployment of autonomous vehicles going in hand with the increasing need for shared mobility services have attracted the attention of the operations research community.This increasing interest can also be observed after many large mobility operators (Tesla, Ford, Uber, Lyft and others) have declared their plans for deploying new autonomous mobility services.
Different ownership models and usage scenarios have been introduced by various actors. 1 These models include, among others, owning an AV, renting an AV for a one-way ride, using an on-demand AV service (also called robotaxi) or an autonomous public transport shuttle, and sharing an AV with other travelers during part of the trip ( [22]).We focus in this paper on individually-owned and on-demand AVs that can be shared by multiple travelers during their trips.The first ownership model is based on the idea that autonomous vehicles can be individuallyowned.Every user might have his own AV.Additionally, this model proposes that an individually-owned AV can serve other users during the time its owner does not need it.This might be the case when an AV owner is at work and the AV is not in use.Such an ownership model can help in partially financing AV acquisition cost.The second ownership model is to consider a fleet of on-demand AVs.In this model, AVs are invoked from their stations (depots) to satisfy mobility demands such that one single AV can serve multiple demands before getting back to the station.Unlike the first model where owners have the priority to be served by their AVs, all users have the same priority to be served by an AV in an on-demand service.In addition, an important aspect is that an AV, whether it is individually-owned or on-demand, can be shared by multiple users.Although it may increase depreciation and risk of damage and leads to longer trips for owners, the idea of ride-sharing, which aims to minimize the number of vacant seats in vehicles so that the number of required vehicles is reduced, comes with many benefits.These benefits include reducing travel cost and time, alleviating traffic congestion, conserving fuel and energy and reducing air pollution.Using autonomous vehicles in a ride-sharing system represents a promising opportunity in future transportation systems.
Extending the work on vehicle sharing by [21], the aim of this research is to study and compare the different ownership and usage scenarios for autonomous vehicles and assessing the sharing potential of those different variants by a case study for New York and Paris.This paper is organized as follows.In Section 2, we provide an overview of related literature.In Section 3, we describe both variants of the problem introduced earlier.The solution method we have developed is detailed in Section 4. In Section 5, we present the computational study we have conducted on the cities of New York and Paris and we discuss and analyze its results.Finally, in Section 6, the key findings are summarized and directions for future research are suggested.

Background
Recent studies on autonomous mobility have been directed towards three main research objectives.These are: assessing public opinions regarding AVs, studying the potential impacts of introducing such a new service on existing urban mobility systems, and developing new methods and approaches for planning them.In order to assess public opinions with regards to AVs, [8] observed the willingness to pay for partial or full automation through collecting and analyzing answers to a vehiclepurchase choice experiment focused on energy consumption and autonomous features.Another study, conducted by [3], surveyed respondents across Texas to understand their opinions about such a new technology.Their study showed that affordability and equipment failure are Texans' top two concerns regarding AVs.Furthermore, [13] concluded that service attributes including travel cost, travel time and waiting time may be critical determinants of the use and acceptance of shared AVs.Their results implied also that the adoption of shared AVs may differ across cohorts, whereby young individuals and individuals with multimodal travel patterns may be more likely to adopt shared AVs.
On the other hand, more research has focused on analyzing the impact of deploying AV-based services on existing transportation systems.For example, [5] simulated a city-wide replacement of private cars with a fleet of autonomous taxis in Berlin.Their simulation suggested that a fleet of 100000 vehicles will be enough to replace private cars in Berlin (more than 1.1 million private car trips) at a high service quality for customers.Considering that AVs can be used as a shared mobility service, [9] suggested that each shared AV can replace around 11 conventional vehicles, but adds up to 10% more travel distance than comparable non-shared AV trips resulting in overall beneficial emissions impacts.Moreover, [25] developed models to examine how much vehicle ownership reduction can be achieved once private conventional vehicles are replaced by AVs and the spatial distribution of unoccupied vehicle-miles-traveled (VMT) accompanied with the vehicle reduction.Their results showed that more than 18% of the households can reduce vehicles, while maintaining the current travel patterns.Furthermore, [17], simulated performance characteristics of shared AV fleets serving travelers across the Austin, Texas 6-county region where a set of charging stations with different charging times were considered.Their results suggested that reducing charge times does lower fleet response times (to trip requests), but increasing fleet size improves response times the most.Additionally, [19] used scenario analysis to identify future deployment paths of automated vehicles in the Netherlands.According to their scenarios, fully automated vehicles are expected to be commercially available between 2025 and 2045, and to penetrate the market rapidly after their introduction.On exploring the impact of shared AVs on urban parking demand, [24] showed, through an agent-based simulation approach, that 90% of parking demand for clients who adopt the system might be eliminated at low market penetration rate.In addition, [11] estimated bounds on the potential increases in travel in a fully automated vehicle environment due to an increase in mobility from the non-driving and senior populations and people with travel-restrictive medical conditions.Their results estimate 14% increase in annual vehicle-miles-traveled for the US population 19 and older.
Therefore, the study of the potential impacts of introducing AVs in urban mobility systems associated with assessing their sharing potential are at the heart of nowadays research regarding autonomous mobility.Although research on studying the impacts of deploying AVs has been growing in popularity in recent years, less amount of research on how to plan and operate their trips is yet available.This is mainly because most scientific advances for operating AVs have been done by AV manufacturers and service providers who do not always publicly unfold the details of their approaches and algorithms due to commercial sensitivity ( [20]).In addition, some studies suggested that methods and algorithms that operate conventional vehicles can still be applied to autonomous vehicles.However, an increasing effort is being directed recently towards building new methods for planning AV trips.For this purpose, [12] propose a taxonomy for classifying AV fleet management problems to inform future research on autonomous vehicle fleets.In their paper, they review the existing categories for classify scheduling and routing problems, refine some of them as they relate to the AV fleet problem and propose novel taxonomic categories for classifying AV fleet management problems.On planning new infrastructures to adapt and promote the deployment of AV technology, [7] presented a mathematical framework for the optimal design of AV zones in a general network.Their framework is based on, first, a mixed routing equilibrium model which captures different routing behaviors (within and outside AV zones), and mixed-integer bi-level programming model to optimize the deployment plan of AV zones.In their general framework for modeling shared autonomous vehicles, [16] propose a heuristic for dynamically constructing shared rides using autonomous vehicles.The proposed approach consists of a dispatcher that checks whether there are any AVs that are already located or en route to where a travel demand has appeared and then assigns the AV to carry the longest waiting traveler.Furthermore, other travelers are allowed to join the shared trip if they are traveling to the same, or a close, destination giving the priority to travelers already in the vehicle because they have been traveling.In addition, [14] introduce a theoretical framework for autonomous vehicles based on the model of a family (the provider of physical services as the "father", the strategic manager as the "mother", and the individual AVs as the "children").Their model allows vehicles to negotiate among them in a decentralized fashion and, at the same time, it allows the fleet manager to set fleet priorities and pre-allocate vehicles in locations of expected future demand.Moreover, [1] propose a general mathematical model for real-time high-capacity ride-sharing that, on the one hand, scales to large numbers of passengers and trips, and on the other hand, dynamically generates optimal routes with respect to online demand and vehicle locations.Their algorithm, which applies to fleets of autonomous vehicles, starts from a greedy assignment and improves it through a constrained optimization, quickly returning solutions of good quality and converging to the optimal assignment over time.Their approach is based on the idea of decoupling the problem by first computing feasible trips from a pairwise shareability graph and then assigning trips to available vehicles.
In this paper, we consider a simplified ride-sharing setting in which only one pickup and one drop-off is allowed during a shared trip.Thus, riders sharing the same trip will be all picked up at the same pick-up location and all dropped off at the same drop-off location.For this purpose, we define a set of fixed locations where pickups and drop-offs can take place, or in other words, a set of meeting points.The idea of using meeting points goes in hand with the original work, by [21], that we extend in this research.In their paper, the authors propose a two-phase algorithm that optimally matches drivers and riders in large-scale ride-sharing systems with meeting points where the aim is to investigate the potential benefits of introducing meeting points in such a ride-sharing system.Unlike the original research which considered commuter morning trips, we propose a heuristic approach that extends the proposed approach.We focus on studying the sharing potential of autonomous vehicles through comparing their different ownership models and usage scenarios on a full day time horizon where demands are known beforehand.The originality of this research is that it proposes an approximation approach that allows us to analyze a large number of ride-sharing scenarios for AVs where most of the available research on this domain uses simulation-based approaches (see [5,6,10,24]).While considering travel costs is not in the scope of this paper, we focus on studying the number of matched participants as well as the system-wide distance savings through a case study for New York and Paris.

Problem description
In this paper, we consider two ownership models for AVs; individually-owned and on-demand service.There are two main differences between these two ownership models.The difference is illustrated in Fig. 1 where each node represents a meeting point (MP), the origin or destination of an owner or a rider, or a depot.Owner's are denoted with o's and riders are denoted with r's.In the individually-owned case, AVs are based at their owners' home locations and the owners have a higher priority to be served by their own AVs.Additionally, owners can indicate how much extra time they can afford to accommodate a shared ride.On the other hand, all users have the same priority in the on-demand case and AVs are located at certain locations (depots) waiting for requests.Nonetheless, both cases have similar problem settings and will be modeled and solved by the same solution approach (Section 4).As mentioned in Section 2, we consider a full day planning horizon where transportation demands are known in advance.For example, an individually-owned AV brings its owner (o1) from his home to his work in the morning and brings him back home in the evening while offering rides to other potential riders (r1,r2 and r3) (Fig. 1a).Riders are picked up and dropped off at their home/destination locations or at feasible meeting points (MPs).We call this kind of trips one-way trips, where the origin and the destination of the trip are two different locations.One-way trips represent mainly, but not only, morning and evening commutes.Furthermore, the individually-owned AV can serve riders (r4, r5 and r6) while its owner (o1) is at work and must return to him before he finishes his work.We call this kind of trips, where AVs depart from and return to the same location, round trips.In the on-demand AV case (Fig. 1b), AVs are based at service centers (C) and waiting for incoming requests.AV#2, for example, departs from its center, serves riders (r4, r5 and r6), and once all riders are dropped off and no more scheduled trips to serve, it returns to the center.We can observe that an on-demand AV trip has similar characteristics to the round trip in the individually-owned AV case.In both cases, multiple (consecutive) shared trips may take place but only one pickup and one drop-off are allowed during each shared trip (In Fig. 1, riders r4 and r5, sharing the same trip, are picked up and dropped off at the same meeting point).Furthermore, since AVs are assumed to be electric ones, both individually-owned and on-demand AVs cannot be in service for more than a certain amount of time because they need to be recharged.Thus, an individually-owned AV is assumed to be recharged at its owner home location (during the night) and work location (during the day).Similarly, on-demand AVs are assumed to be recharged at their depots.The main difference is that when an individuallyowned AV is doing a round trip, it has a time window specified by its owner.Thus, if the owner is willing to allow his AV to serve other potential riders, the AV is only available while its owner does not need it and must return to him before he needs it again.These additional time restrictions are considered in the proposed model.For the sake of simplifying the problem, we assume that all AVs have the same capacity and that traveling occurs at a constant speed (i.e.driving speed for AVs and walking speed for riders are fixed).However, most of those assumptions can be relaxed so as to cover a more realistic settings.

Notation and parameters
In this problem, a set of trip announcements S is considered.Every announcement s ∈ S is characterized by: an origin o s , a destination d s , an earliest departure time e s and a latest arrival time l s .The set of announcements S is partitioned into two subsets; O ⊂ S set of trip announcements by the owners and R ⊂ S set of trip announcements by the riders.While on-demand AVs are located at different centers (depots) and ready to serve riders, owners specify when and where their owned AVs are available for sharing (for example, during a morning trip from home to work or a day trip while owner is at work).Thus, every owner i ∈ O specifies the maximum trip duration T i , which implies the extra time he accepts to accommodate a shared trip, and the number of available seats C i , which indicates the maximum number of riders his AV can accommodate.On the other hand, every rider j ∈ R specifies the maximum distance m j that he is willing to walk to and from a meeting point.Furthermore, we denote the origin and the destination of a trip announcement s ∈ O ∪ R with o s and d s .In addition, distances and travel times between every two locations are considered.Thus, we denote the distance from location i to location j with δ i,j and the travel time between them with t i,j .A set of meeting point locations M is given.A rider can be picked up at his origin or at one of his feasible pickup meeting points and dropped off at his destination or at one of his feasible drop-off meeting points.A feasible meeting point is a point which the rider can reach in an acceptable walking distance (i.e. less than the maximum walking distance that he specified).As such, we denote the set of feasible pickup meeting points for a rider j with M p j := k ∈ M|δ o j ,k ≤ m j and the set of feasible drop-off meeting points for rider j with M d j := {k ∈ M|δ k,d j ≤ m j }.Furthermore, we use the concept of meeting point arc introduced in [21].A meeting point arc a ∈ A denotes a combination of a pickup meeting point and a drop-off meeting point.As such, the set of feasible meeting point arcs for rider j is Thus, a rider j can be picked up at his origin o j or a meeting point in M p j and dropped off at his destination d j or a meeting point in M d j .Finally, the service time at each meeting point m ∈ M, which is the time needed for riders to get into and out the AV, is denoted by τ m .

Definition of a feasible match
A match is a combination of an owner i ∈ O, a set of riders J ⊂ R and a trajectory that indicates the route which the AV will follow during the trip which is represented by a meeting point arc a ∈ A. In order for a match (i, J, a) to be feasible, it must have the following properties: -Capacity feasible: A feasible match must satisfy the capacity constraint of the AV, or in other words, the number of riders that can participate in the trip must be less than or equal to the number of available seats specified by the AV owner i.Thus, if the owner i is not participating in the trip (round trip), then the number of available seats will be equal to the AV capacity: -Time feasible: A feasible match must satisfy the time-window constraints of its participants.A match is time-feasible if it respects, for all its participants, the earliest departure times from their origin locations and the latest arrival times at their destination locations and, for the owner, the maximum trip duration.In order to check time feasibility of a match (i, J, a), [21] suggested to construct an implied time window e k p , l k p at the pickup meeting point k for each participant p (either i or j ∈ J) in the match.Following their proposition, e k p represents the earliest departure time possible for participant p from the pickup meeting point k, such that: e k p = e p + t o p ,k , where e p is the earliest departure time of participant p and t o p ,k is the travel time between participant origin o p and the pickup meeting point k.In addition, l k p represents the latest departure time possible for participant p from the pickup meeting point k, such that: , where l p is the latest arrival time of participant p, t k,l is the travel time between pickup and drop-off meeting points (k, l), t l,d p is the travel time between the drop-off meeting point l and participant destination d p , and τ k and τ l represent the service time at meeting points k and l respectively.Thus, in a time feasible match, the intersection of the implied time windows has to be non-empty, which implies that: Where max e k i , max j∈J e k j is the earliest time, and min l k i , min j∈J l k j is the latest time, at which the shared ride can depart from meeting point k.In addition, a time feasible match should respect the maximum trip duration specified by the owner, thus: In other words, the sum of travel times between different locations (i.e.owner origin to pickup meeting point t o i ,k , pickup meeting point to drop-off meeting point t k,l , and drop-off meeting point to owner destination t l,d i ) and service times at meeting points (i.e.τ k and τ l ) must not exceed the maximum trip duration (T i ) that the owner can accept to accommodate the shared ride.

-Distance feasible:
Since only one pickup and one drop-off are allowed in a shared trip, then the meeting point arc a should be feasible to all riders J ⊂ R in a feasible match (i, J, a).Thus, the pickup and drop-off meeting points shaping arc a should be at feasible walking distances for all riders participating in the feasible match: Furthermore, a distance-feasible match must achieve a distance saving compared to the case of non-shared (individual) trips.Consider the example in Fig. 2 with one owner o 1 , two riders r 1 , r 2 , a pickup meeting point and a drop-off meeting point (numbers above arcs represent distances between locations).If each traveler will drive individually from his origin to his destination then the overall traveling distance will be 10+10+10 = 30.On the other hand, if a shared trip will take place (bold arrows) then the overall traveling distance will be 8 + 10 + 8 = 26.As such, the shared trip has the potential of reducing the overall traveling distance, and thus, the match has a positive distance saving.A match between owner i and riders in J ⊂ R on a meeting point arc a = (k, l) has an associated distance saving of is the travel distance of individual (non-shared) trips of participants (including owner and riders' trips), and (δ o i ,k + δ k,l + δ l,d i ) is the travel distance of the shared trip.Thus, the match is feasible if σ (i,J,a) > 0: As a result, a match is feasible when it respects capacity, time and distance constraints.With every feasible match, two values are associated; the number of participants and the distance saving.By solving this problem, we aim at finding the set of matches that maximizes the number of matched participants as we will see in the following section.

Matching problem
The matching problem is formulated as a maximum weight bipartite matching problem.A node is created for each owner i ∈ O and for each rider j ∈ R.An edge connecting node i and node j is added if there is a feasible match between owner i and rider j.Furthermore, nodes representing a set of riders in R are also created and an edge connecting owner i and a set of riders is added if a feasible match between them exists.Each edge e has two weights associated with it: the number of participants in the match v e , and a distance saving σ e .Let E represent the set of all edges in the bipartite graph and let the binary decision variable x e for edge e ∈ E indicate whether the edge is chosen in an optimal matching ( x e = 1 ) or not ( x e = 0 ).In addition, let E i and E j represent the set of edges in E associated with owner i and rider j.Thus, the matching problem with the objective of maximizing the number of matched participants (Z) can be formulated as the following integer program: (6) subject to The objective function ( 6) maximizes the number of matched participants.Constraints (7) and (8) assure that each owner and each rider is only included in at most one match in a final matching.

Solution approach
As it was defined earlier, a match is a combination of an owner, a set of riders and a meeting point arc where the shared ride can take place.As such, the problem is to find the set of those matches in which as many travelers (owners and riders) as possible are matched and participating in shared rides.In order to solve this problem, we propose a heuristic algorithm.The proposed approach is an extension of the two-phase algorithm introduced by [21].The two phases are: generating feasible matches and selecting the best among them through a matching problem.In the first phase, we look for feasible matches for every owner iteratively and we add them to the matching problem.Then, the matching problem aims at selecting the best matches such that each owner/rider is matched at most once in a final solution.Our approach aims to maximize the number of matched participants.It is important to mention that the main driver of our algorithm design is the fast execution times.This allows us to test and analyze various scenarios of the problem.
In the first phase, the aim is to find the set of feasible matches.For this purpose, the algorithm considers owners one by one and tries to build feasible matches with potential riders.If a feasible match is found, an edge, linking the matched participants (owner and riders), is added to the matching problem with two associated coefficients; the number of participants and the potential distance savings.On the other hand, the algorithm finds for every rider, according to the maximum walking distance that the rider accepts, the sets of feasible pickup and drop-off meeting points (Section 4.1).Furthermore, once an owner is considered, the algorithm checks whether his trip offer is a one-way trip or a round trip and generate his feasible matches accordingly (Sections 4.2, 4.3 respectively).We extend the original algorithm presented in [21], which only considers one-way trips, by allowing AVs to perform round trips.Thus, the proposed algorithm aims at generating feasible solutions for both one-way and round trips at short computational times.

Determine feasible meeting point arcs for a rider
In order to generate feasible matches, the algorithm defines the set of feasible meeting point arcs for every rider.In other words, the sets of meeting points where a rider can be picked up and dropped off need to be defined.For this purpose, we store the set of meeting points in a k-d tree data structure.k-d trees have the ability of performing n nearest neighbors search and fixed-radius near-neighbor search in logarithmic time ( [4]).Thus, we use the k-d tree to find, for each rider j, the meeting points that are accessible from his origin o j and destination d j within an acceptable walking distance (less than m j ).Once feasible meeting points for rider j are known, a set of feasible meeting point arcs is constructed by combining every possible pair of feasible pickup and drop-off meeting points.

Generate feasible matches for a one-way trip
If a one-way trip is considered (Fig. 3a), the algorithm iterates over the set of riders seeking to find feasible If the combination has a positive distance saving, it will be temporarily conserved while the other feasible meeting point arcs of the rider are checked.A match combining an owner, a rider and a meeting point arc that has the best distance saving will be added to the set of feasible matches.Afterwards, the algorithm will consider the next rider similarly until the whole set of riders is checked and all feasible single-rider matches are added (Fig. 4

left part).
Once all feasible single-rider matches are added, the algorithm will try to find feasible multi-rider matches and add those found to the matching problem (Fig. 4 right part).

Generate feasible matches for a round trip
If the considered offer is a round trip (Fig. 3b), the algorithm selects a set of artificial owners in order to construct a concatenation of one-way trips (See Fig. 5a).The idea is to choose one rider to be a temporal owner of the AV which will pick him up at his origin location and drop him off at his destination location.In this case, this selected rider will be considered as a new "artificial" owner of the AV and the algorithm will then try to match him with other potential riders.Once the first artificial owner is considered and matched, the algorithm will add other artificial owners as long as the AV can still return to its real owner (or equivalently to its depot in the on-demand case) at the specified latest arrival time.The choice of which rider to be selected as the next artificial owner is made in a greedy fashion (see Fig. 5b).The earliest departure time of the rider and the time that the AV needs to arrive at his origin location are considered.Thus, the rider that can be served the earliest is chosen.In this example, rider a1 is chosen as the next artificial owner because the AV can arrive to his origin location at 9:25 (Earliest departure from the depot at 9:00 + 25 mins traveling to a1 origin location) and his earliest departure time is 9:00.Thus, his trip can start at max(9:00,9:25) = 9:25 where a2 and a3 trips can start at 9:30 and 12:30 respectively.So, a1 is chosen because his trip can be started the earliest.The process of assigning artificial ownership to riders continues until there is only time for the AV to return to its original location (In the example, the AV must return to its origin o before 5 pm).This greedy choice is made as we want to approximate a dynamically operating ride-sharing system in which a vehicle is assigned to a first customer and then others are added as soon as their requests arrive.Once all round trips are transferred into sequences of one-way trips, they can be treated similarly (Section 4.2).Thus, the algorithm will look for all their feasible matches and add those found to the matching problem.

Algorithm
As mentioned above, the algorithm aims to look for the feasible matches for every single owner and then passing those feasible matches to the matching problem which will choose the best among them.The algorithm takes an instance as input (see Fig. 6).The instance is composed of three sets: set of owners O, set of riders R and a set of meeting points M. The algorithm starts by storing meeting points in the k-d tree so they can be rapidly retrieved later.In the next step, the algorithm will search the k-d tree in order to find the feasible pickup and drop-off meeting points, and thus the feasible meeting point arcs, for every rider.Once the feasible meeting point arcs of every rider are found, the algorithm considers owner trip announcements one by one and checks whether it is a one-way or round trip.If it is one-way trip, the algorithm finds all feasible single-rider matches, then two-riders matches, etc., until the available capacity is reached.If a feasible match is found, an edge is added to the matching problem with two associated coefficients; the number of participants and the potential distance savings.On the other hand, if the considered owner trip announcement corresponds to a round trip, the algorithm selects a set of riders as artificial owners.Thus, a sequence of artificial owner trips will be constructed as long as the original time window specified by the "real" owner can still be respected.Those constructed artificial owner trips are one-way, and thus, feasible single and multiple rider matches are computed in a similar manner (see Fig. 6).

Early checking for feasible matches
When the number of participants (owners and riders) is relatively large, it can become computationally prohibitive to find all their feasible matches.This huge computational effort is illustrated by the fact that the algorithm will have to check for every owner, all rider feasible meeting point arcs.Thus, reducing the number of meeting point arc feasibility checks has the potential of accelerating of the algorithm.For this purpose, [21] suggests that if we assume that the rider travels to the boundary of his walking range at vehicle speed and there is no feasible match under that assumption, then there is no feasible match when the rider is walking.Thus, there will be no need to check all his feasible meeting point arcs (see Fig. 7).Following this assumption, let t max j denote the time needed to travel distance d max j at vehicle speed, where d max j is the longest distance a rider j is willing to walk to and from a meeting point.From Fig. 7, it is obvious that there cannot be a feasible match between owner i and rider j if the trip time when rider j is picked up and dropped off at the boundary of his acceptable walking distance is longer than the maximum trip duration that the owner i can accept: Thus, only if this infeasibility check indicates that there may be a feasible match between owner i and rider j, the algorithm proceeds to examine the possible matches for each meeting point arc.As such, the number of meeting point arc feasibility checks can be reduced.

Results and discussion
In this section, the results of a computational study are reported.The aim of this computational study is to test the proposed solution approach and to assess the sharing potential of the different ownership and usage scenarios using datasets for the cities of New York and Paris.

Generating instances
For generating the required instances for New York City, Taxi and Limousine Commission (TLC) trip record datasets are used 2 .For Paris, we consider traveler daily trips introduced by [23] where a multi-agent simulation is used for estimating transport demands around the city.In both cases, trip records include fields capturing pickup and drop-off times and locations, trip distances, fares and other related fields.We use these trips to generate owner and rider trips according to different usage scenarios.
Since the set of meeting points is predefined and used for all instances (Section 5.1.3),trips are interpreted and processed in order to generate sets of owner and rider trip announcements for each city over a full-day time horizon.Therefore, we use a similar approach for generating 16 different streams of trips based on datasets obtained during different working days for both New York and Paris.
For generating one-way trip announcements, their origin and destination locations, earliest pickup and latest drop-off times have to be defined.Origin and destination locations are generated based on the original locations that are available for each traveler trip (i.e. based on original taxicab trips for NYC, and simulated traveler trips for Paris).Since original trip time records represent the actual departure and arrival times, we extend them by a 30 min time flexibility parameter in order to be matched in a shared trip ( [21]).We thus deduct 15 min from the original departure time and add 15 min to the original arrival time so that the difference between the latest arrival time Fig. 7 Early checking -infeasibility check of a match and the earliest departure time is equal to the sum of the actual trip duration and the time flexibility parameter.For owner trips, we assume that owners, who wish to participate in a shared ride, are not willing to extend their original trip time by more than 20 min.The capacity of the AVs, whether they are individually-owned or on-demand, is assumed to be the same.Thus, if AV owner is participating in the trip (one-way trip), then he has a capacity of 3 spare seats.Furthermore, if the owner is not participating in the trip (round trip), then we assume that the AV has 4 spare seats to accommodate riders.In addition, we assume that the maximum walking distance that riders are willing to walk to and from a meeting point is 0.5 kilometer (see Table 1).
For generating round trip announcements, we assume that not all owners, having a morning trip with an earliest departure time between 5 and 9 am, from their homes to their work locations, are willing to let their AV serve others while they are at work.For this purpose, we randomly select 25% of those morning trips and we accordingly generate their relative round trips.We thus consider that the origin, which is also the destination, of the generated round trip is the owner work location.We also assume that the earliest departure time for a round trip to be 15 min later than the arrival of the owner to his work location (for example, if the owner arrives to his work location at 8:30 am, then his AV will be available for service at 8:45 am).Furthermore, we assume that an AV should return to its owner before 4 pm because he needs it to get back to his home.As mentioned before, individually-owned AVs are assumed to be recharged at their owner home/work locations and that their round trips should not be longer than 6 hours because they need to be recharged.On the other hand, on-demand AVs are recharged at predefined service centers, where they are located, and should return to their centers at most after 6 hours in service so that they can be recharged.We assume that an on-demand AV needs 2 hours in order to be fully recharged before it gets back in service.Moreover, we assume that AVs circulate at a fixed speed (24 km/h) and that riders move at 4 ft/s walking speed ( [15]).The service time, which is the time needed for riders to get in or out the AV at a meeting point, is assumed to be 2 min.For calculating travel distances between different locations, the haversine formulation (which computes the great circle distance between two points) is used.
Finally, we generate, for each of the instances, three variants in which the owner-to-rider ratio is different (see Table 2).In the first variant we generate an equivalent number of owner and rider trip announcements where the number of riders increases to four times and ten times the number of owners in the second and third variant respectively.
The goal of generating those different variants is to see how an increasing demand could affect the different elements of the analysis and compare the results obtained by testing instances with different owner-to-rider ratios.In addition, a higher demand better reflects city-wide mobility where thousands of trips take place every day.Furthermore, we provide a set of scenarios by which each one of the instances is tested as we will see in the following section.

AV usage scenarios
As mentioned above, the main aim of this research work is to analyze the different ownership models and their different usage scenarios.We thus consider different scenarios for testing each instance.The idea is to start with a scenario in which only individually-owned AVs (IO AVs) are used to serve a set of riders.We then assume that a set of those owners (10% of them at each scenario) are not willing to use their own AV, or in other words, they are willing to be picked up by an AV as potential riders.As such, they are added to the set of riders.Moreover, we replace those owner trip announcements by a number of on-demand AVs (OD AVs) which are based at the predefined service centers.Therefore, 10% of the owner trip announcements are randomly selected, transferred into rider trip announcements, and replaced by a set of on-demand AVs.The process of generating scenarios continues until all owner trip announcements are replaced by on-demand ones and all travelers participate as riders (see Table 3 for an example).Furthermore, three different rates for replacing individually-owned AVs with on-demand ones are considered.Thus, we consider that each added on-demand AV replaces one, two or five individually-owned ones (1-to-1, 1-to-2 and 1-to-5 replacement rates).For example, in Table 3, 150 individually-owned AVs are replaced by the same number of on-demand AVs at each scenario (1-to-1 replacement rate).Relatively, the number of on-demand AVs replacing the 150 individually-owned ones will drop to 75 and 30 with 1-to-2 and 1-to-5 replacement rates (respectively).Regardless of the replacement rate used for generating the different scenarios, replaced owner trip announcements are all considered as riders.

Meeting points
In order to test the generated instances and their scenarios, a set of meeting points, where riders can be picked up and dropped off, is needed.We generate the required meeting points based on actual public transport stations in New York and Paris (Fig. 8a & c).For New York City, we use data records that are provided by the Metropolitan Transportation Authority MTA 3 .These records capture New York City transit subway and bus locations.Similarly, Paris railway station records are used (these records were obtained using the simulation approach provided in [23]).In order to have a minimal and well-distributed set of locations, we filter the available locations and we eliminate some of them such that a minimum distance of 500 meters between every pair of locations is guaranteed.Without filtering those locations, the number of feasible meeting point arcs for each rider will dramatically increase, and thus, generating feasible matches will be computationally prohibitive.In addition, this 500 meters distance is in-line with the maximum walking distance a rider can walk to get into a meeting point (see Table 1) [21].
The choice of using public transport stations as meeting points comes with two main benefits.First, they are well distributed around the city, and thus, cover the studied area especially that their locations are available.Second, those stations are accessible by different transportation modes (subway and bus).As such, considering them as meeting points opens the door for integrating the use of autonomous vehicles with other transportation modes in future research.

Depots
For the on-demand AVs case, we need to define a set of locations (depots) where the on-demand AVs can be located.For New York City, we fix four locations corresponding to actual taxi-service and car-service centers (one center in Manhattan ("Lower East Side Car Services"), two centers in Queens ("Liberty Taxi NYC" and "Athena Car Service") and one center in Brooklyn ("Eastern Car Service") (Fig. 8b).For Paris, we select four locations corresponding to public transit stations around the city ("CDG Etoile", "Gare Montparnasse", "Nation" and "Stalingrad", see Fig. 8d).In both cases, on-demand AVs are invoked from these centers to serve requests and get back to their centers once their trip is finished.

Performance
The algorithm for generating feasible matches is implemented in Java 1.8.0.For solving the matching problem, CPLEX 12.6 is used (CPLEX is an IBM software package, also called CPLEX optimizer, that is used for solving integer programming problems). 4Instances were tested on a quad-core i5-5300U machine with 8 GB of RAM.The base case instance, with 1-to-1 owner-to-rider ratio (Table 1), solves in less than 7 min while instances with 1to-4 and 1-to-10 owner-to-rider ratios solve in less than 25 and 90 min respectively.CPLEX solves the matching problem in a few seconds for different instance sizes.Most of the computational time is thus spent generating feasible matches for one-way and round trips.However, these relatively short running times suggest that our approach is suitable for approximating dynamic operations where instances with a much smaller set of trip announcements have to be solved at any one time.

Experiments
The solution approach that we have implemented provides a good basis because it allows us to test instances with different sizes, scenarios and replacement rates in relatively short computational times.We thus use the generated instances and the set of solutions (matches) provided by the algorithm to compute and evaluate a number of metrics in two case studies for New York and Paris.We use the following metrics in our analysis: the number of participants, the matching rate for riders, the Page 13 of 20 As introduced earlier in Section 3.3, every feasible match is associated with the number of travelers that are participating in it.The matching problem aims at maximizing the overall number of participants in the system.A participant is thus a traveler (owner or rider) who is participating in the system.Since an owner uses his own AV to travel, we always consider owners as participants even if they are not matched in a shared trip.On the other hand, a rider is considered as participant only if he is matched in a shared trip.
Results, obtained by averaging the 16 instances for each city with different owner-to-rider ratios, indicate that when the number of available on-demand AVs increases, the number of matched participants increases as well (results for NYC and Paris are presented in Figs. 9 & 10 respectively).This applies to the three owner-to-rider ratios when each on-demand AV is replacing one, two or five individually-owned AVs.We observe that when the number of riders becomes four or ten times the number of owners with 1-to-5 replacement rate, the number of participants decreases in scenarios with more than 80% of on-demand AVs (Figs. 9c & e & 10c & e).This is due to the large number of riders and the fewer number of AVs which is not sufficient for serving this increasing demand.
Another important metric is rider matching rate.This metric represents the percentage of riders that are matched in the system.Only riders are thus included.The goal of measuring this metric is to observe how the different scenarios and replacement rates could affect the number of riders that are successfully matched in a shared ride.
As for the number of matched participants, results indicate that as more on-demand AVs are replacing individually-owned ones, the rider matching rate increases.This is mainly because on-demand AVs have a higher flexibility in terms of time constraints (unlike the individually-owned where owner preferences have to be respected).An on-demand AV can thus provide service to a larger number of potential riders.We also observe that the convergence towards the 100% matching rate is faster  & 10b).When the number of riders becomes higher, the convergence becomes relatively slower (Fig. 9d for example).Furthermore, with 1-to-4 and 1-to-10 owner-to-rider ratios, the matching rate does not converge when five IO AVs are replaced by one OD AV.This is due to the lack of enough AVs to serve the increasing demand (Figs.9d & f & 10d & f ).If we take the 1-to-1 owner-to-rider ratio as an example (Fig. 9b), we observe that satisfying all rider requests is obtained with the three different replacement rates but in different scenarios.For satisfying NYC demand in this case, we need the percentage of ondemand AVs to be at least: 10% of the available AVs with 1-to-1 replacement rate, 20% with 1-to-2 replacement rate, or 50% with 1-to-5 replacement rate (Fig. 9b).The same observation can be made for Paris but with a slower convergence towards satisfying the full demand (20, 30 and 60% respectively, Fig. 10b).On the other hand, for the 1-to-4 owner-to-rider scenario (9d), satisfying rider requests can be achieved by having at least 30% OD AVs with 1-to-1 replacement rate or 60% OD AVs with 1-to-2 replacement rate but cannot be achieved with 1-to-5 replacement rate (similarly for 1-to-10 ratio, Fig. 9f).This observation can help in fixing the number of ondemand AVs needed to fully satisfy the demand in each one of the instances.This is illustrated by the number of used AVs at each of the scenarios (Fig. 11).Since the number of available AVs depends on the replacement rate used at each scenario, the presented graph correspond to 1-to-1 replacement rate (blue line with circled points).If we consider instances with 1-to-1 owner-to-rider ratio as an example (Figs.9b & 10b), in the first scenario (where around 1500 IO AVs are available), we still have about 20% of rider demands which are not served.In the second scenario, when 10% of the available IO AVs are replaced by a similar number of OD AVs (similarily with 20% for Paris), rider demands are totally satisfied and the number of used AVs starts to decrease.We thus observe that not all the added OD AVs are actually used, or in other words, fewer number of OD AVs is needed to satisfy all demands in this scenario.When more OD AVs are added in the later scenarios, the number of used AVs keep decreasing while the 100% matching rate is maintained.In the last scenario, where riders are only served by OD AVs, we observe that around 250 OD AVs (out of 1500 that are available for service) were used to satisfy all demands.A similar observation can be seen for instances with larger owner-to-rider scenarios.As such, in a fully on-demand scenario, around 600 and 900 OD AVs are needed to fully satisfy rider demands with 1-to-4 and 1-to-10 ownerto-rider ratios.However, the decreased number of used AVs while maintaining high matching rates means that an on-demand AV is serving more rider requests and doing longer trips than an individually-owned one.In order to compute the average number of participants that are served by an AV (i.e.Participant-per-Vehicle (PpV)), we divide the average number of participants by the average number of used As in each of the scenarios (i.e.

PpV = number-of-participants / number-of-used-AVs).
Results indicate that the average number of participants served by an AV gradually increases as more on-demand AVs becomes available and shared (While an individuallyowned AV is serving 2 participants in average in 0% on-demand AV scenario, an on-demand AV is serving up to 15 (17 for Paris) participants in average in 100% ondemand AV scenario) (Fig. 12a).This observation also goes in hand with the increasing matching rates presented earlier.
Similarly, we compute the average distance traveled by an AV per day (Distance-per-Vehicle (DpV )) by dividing the overall distance traveled by all AVs by the number of AVs circulating in the system.We call the overall distance traveled by all AVs by distance-with-sharing which is the actual distance covered by all AVs for accommodating the shared rides.Thus, DpV = distance-with-sharing / num-of-used-AVs.The DpV also increases when more on-demand AVs are added and shared (Fig. 12b).This increase is obtained, not just because an on-demand AV is serving more riders and thus traveling for longer distances to cover the increasing demand, but also because of the empty trips that an on-demand AV might have to do between two consecutive shared rides (an empty trip appears after an AV drops off one, or more, rider and heads to pick up the next one) or when departing/returning to its owner (or depot) location.Reducing the distance covered by those empty trips, which mainly appear in round trips for both IO and OD AVs, represents a challenge in such systems and an opportunity to enhance the service and maximize its benefits if it is treated efficiently.One way to reduce the effect of empty trips is to consider a more realistic ride-sharing settings where riders can be picked up and dropped off dynamically at any time during AV trip.
As a result, the increasing rider matching rate illustrates the potential benefit of having a fleet of on-demand AVs replacing individually-owned ones.In addition, replacing individually-owned AVs with on-demand ones has the potential of decreasing the overall number of AVs circulating in the system.However, the previous observations indicate that when the demand becomes higher, a fully on-demand AV system, especially with high replacement rates, might not be able to satisfy all rider requests.A minimum number of AVs circulating in the fleet thus need to be ensured.
One important metric of the analysis is the potential distance saving that might be obtained when ride-sharing takes place.For calculating the saving, we compare two distances: the actual distance covered by all AVs for accommodating the shared rides (distance-with-sharing, introduced earlier), and the overall distance if all participants perform individual trips with no sharing at all (called distance-with-no-sharing). The distance-with-no- sharing is actually the sum of origin-to-destination distances of all participants (owners and riders).As such, the distance saving is calculated as follows; distance-saving = 1 -(distance-with-sharing / distance-with-no-sharing).
Results illustrate the benefit of ride-sharing in terms of distance saving.We can observe that sharing AVs, whether they are individually-owned or on-demand, has the potential of saving approximately 22 and 25% of the overall traveling distance in New York and Paris respectively (see Fig. 13) when compared to a system in which no sharing takes place.This considerable distance saving rate can be observed in all scenarios and with the different replacement rates.Fagnant and Kockelman [9] suggest that a shared AV can replace around 11 conventional vehicles, but might add up to 10% travel distance compared to non-shared AV trips.This difference between our results and theirs is due to three main reasons.The main reason is that we use meeting points to match different participants, while in their paper, a shared AV should pass by rider origin and destination locations.Meeting points can thus lead to shorter detours and better distance savings.The second reason is related to trip patterns.While we consider short trips around city center (with average trip distance of 3.64 km), in [9] suburb-city trips are considered (with average trip distance of 8.74 km).Finally, our heuristic approach, in selecting the next artificial owner for AV round trips, leads to short relocation trips (i.e.traveling from one artificial owner to another), and thus, better distance savings.However, our results are consistent with the original study, by [21], where 27 to 29% distance savings were obtained.This small difference (between 22 and 25% savings in our case, and 27 to 29% in their case) is due to round trips, which require more relocation empty-AV trips, that do not exist in the original study.In addition, it was observed earlier that a minimum number of available AVs is needed to ensure the satisfaction of rider demands.Our results show that having a larger number of AVs in the fleet might not lead to a better distance saving ratio unless the use of available seats in each AV is maximized.In other words, a critical key for a successful ride-sharing system is to minimize the number of used AVs while maintaining the quality of the provided service.
Finally, we consider the average extra travel time for participants (owners and riders) which indicates the extra travel time a participant can have in his trip in order to be matched in a shared ride.This extra time is obtained by comparing the actual travel time of the participant in a shared ride with the travel time of a direct trip from his origin location to his destination location (no sharing takes place).
As for AV owners, results indicate that they might have approximately 3 min of additional travel time when matched in a shared ride compared to their non-shared trips.This additional time, which demonstrates the detour an AV should perform to transport potential riders, decreases as more on-demand AVs enter the system (Fig. 14, in 100% on-demand AV scenario, all owners participate as riders).Although sharing trips impose additional travel time to owner trips, they can still have reduced trip costs and they might benefit from reserved lanes for vehicles with multiple travelers.On the other hand, our results indicate that the average extra travel time for the rider decreases when the number of ondemand AVs increases (Fig. 14).This is due to the flexibility that on-demand AVs provide where the possibility of picking up and dropping off a rider at meeting points that are relatively close to his origin and destination locations becomes more probable.Thus, in a sharable on-demand service, a rider will be matched to a closer meeting point, and thus, the extra time needed to travel from his origin to his destination will be decreased, or

Conclusion
In this study, a heuristic approach for studying and comparing the different ownership models for autonomous vehicles has been introduced.The proposed approach consists of two phases: an identification phase for generating the set of feasible matches, and an optimization phase, for selecting the best among them.The algorithm was tested with different scenarios and replacement rates using instances generated based on New York City taxicab datasets and Paris simulated trip records.
Results of the analysis indicate that sharing AVs has the potential of increasing the number of participants and the matching rate for riders as well as the number of participants that can be served by an AV.Although shared AVs might have to circulate for longer distances, sharing rides can save up to 25% of the overall traveling distance which has a considerable impact on traffic in big cities such as New York and Paris.In addition, our results suggest that a system, in which on-demand AV service is partially or fully used and shared, has a better performance than a system in which only individually-owned AVs are used.The advantages of the shared on-demand AV service are illustrated in higher rider matching rates, fewer number of AVs needed to satisfy the demand, better distance saving rates and shorter travel times.In addition, this study suggest that fleet sizing, the efficient planning of AV trips, and the use of meeting points are important factors in a successful ride-sharing system in which autonomous vehicles operate.
Since we build our analysis on a set of assumptions that simplify the problem, the door is always open for considering different and more realistic settings.As such, we point out some future research directions: (1) In this paper we considered a static ride-sharing setting in which travel demands are known in advance and only one pickup and one drop off are allowed.Thus, an interesting research direction would be to consider more realistic ride-sharing settings in which travelers (owners and riders) are matched on-the-fly, (2) since autonomous vehicles will be electric ones, a promising research direction would be to consider recharging operations when building shared rides, and (3) as we use the haversine formulation for calculating the great circle distance, it might be interesting to consider more realistic approaches for calculating travel distances between different locations (e.g.road network distance).We believe that this study will help in better understanding the potential deployment of autonomous vehicles with their different ownership models, and thus, promote more research towards studying this emerging technology.

Endnotes
1 For example, Tesla and Ford for the individuallyowned AVs, and Lyft and Uber for the on-demand ones 2 The taxicab trip records were collected and provided to the NYC

Fig. 1
Fig. 1 Different ownership models.a Individually-owned AVs b On-demand AVs

Fig. 3
Fig. 3 Generating feasible matches.a One-way trip match b Round trip match

Fig. 8
Fig. 8 Generating meeting points and AV depots.a NYC -Public transport stations b NYC -Depots c Paris -Public transport stations d Paris -Depots

Fig. 11
Fig. 11 Number of used AVs

Table 1
Base case instance characteristics

Table 3
Base case instance with different usage scenarios and 1-to-1 replacement rate Taxi and Limousine Commission (TLC) by technology providers authorized under the Taxicab & Livery Passenger Enhancement Programs (TPEP/LPEP).Datasets were obtained from TLC website: https://www1.nyc.gov/site/tlc/about/tlc-trip-record-data.page 3 Subway and bus station locations at New York City are made available by the Metropolitan Transportation Authority (MTA) for development and research purposes.Data records are provided at MTA website: http://web.mta.info/developers/developer-data-terms.html#data 4For more details on CPLEX: https://www.ibm.com/analytics/cplex-optimizer