One-Way Carsharing Solving the Relocation Problem Angela Di Febbraro, Nicola Sacco, and Mahnam Saeednia Barth and Todd (9), Kek et al. (10), Kek et al. (11), and Fan et al. (12), have considered the management of carsharing. The traditional carsharing system is used only for round-trips (i.e., a journey to a destination and return), which limits the number of potential users. One-way carsharing does not require users to return their vehicles to their point of origin in the system. Operators offer different degrees of flexibility to their customers. In some cases, users return the vehicles to a specified station, while in others they can leave the car whenever and wherever they want. One-way carsharing does create the need, however, to redistribute vehicles to the right stations to meet user demand. Otherwise, there would either be a concentration or a shortage of vehicles at popular destinations and origins, and the system would not be able to fully satisfy the demand, which would lead to a reduction in customers. In previous studies on flexible destinations in carsharing, two main approaches to relocation were taken: user-based and operator-based relocation algorithms. In these systems, the number of vehicles in each station should be periodically checked according to the lower and upper thresholds to identify the need to move vehicles among stations. In operator-based relocation techniques, staff members of the carsharing company relocate the vehicles, whereas, in user-based relocation methods, this task shifts to the customers. Thus far, several relocation techniques have been proposed in the literature. In a static relocation approach, Barth and Todd relocated vehicles on the basis of immediate needs at a particular station. A minimum threshold was used before a relocation event was generated for a particular station, and the station with an excess of vehicles maintained a minimum threshold before it could give up vehicles in a relocation event (9). Later, Barth and Todd studied the relocation prediction with a supposition of knowledge of user destinations (13). In a following study, Barth et al. proposed two user-based relocation methods, which successfully reduced the required number of relocations. These methods were trip splitting (i.e., users drive separate vehicles when they travel from a station with an oversupply of vehicles to one with a shortage), and trip joining (i.e., users share a ride in a single vehicle when they want to travel from a station with a shortage of vehicles to one with an oversupply) (14). In an operator-based study, Kek et al. presented a methodology for a flexible time and destination system. Two relocation techniques were used, namely, shortest time (i.e., vehicles were moved in the shortest possible time), and inventory balancing (i.e., a station with a shortage of vehicles was filled with vehicles from a station with an oversupply) (10). In another study, an algorithmic approach was proposed in which the algorithm returned a simple probabilistic policy to distribute cars from each node according to a fixed probability distribution. An attempt was made to try and find the right balance between relocation of a car and the wait for a customer to appear and take care of it instead. An operation research model was developed to maximize the carsharing scheme’s long-term average revenue (15). In user-based
Carsharing services allow users to benefit from the advantages of a private car without the costs of owning one. One-way systems provide users with a higher level of service than traditional carsharing systems in terms of flexibility because users do not need to return to the station of origin. Moreover, the added option to leave the vehicle at any free parking area, which is not necessarily a station, increases the flexibility offered by the one-way system. Introduction of such improvements to the carsharing system, however, leads to a vehicle relocation problem, which should be addressed carefully to avoid concentration of vehicles in certain areas. This paper reports on a study of this issue with the use of discrete event systems (DESs), which allowed an easy representation of the complex dynamics of the carsharing system. A user-based methodology was proposed on the basis of an optimal relocation policy in a rolling horizon framework. This methodology not only offers greater flexibility to users, it also maximizes operator benefits by reducing the number of required staff to relocate vehicles among the stations and determines the minimum number of vehicles needed to satisfy system demand. The DES model was applied to a case study to evaluate the proposed approach. The results showed a significant decrease in the rejection rate from the worst scenario (no relocation) to the best (relocation of all vehicles by their users). The paper concludes with suggestions for additional research and improvements to this study.
Demand-responsive transport modes are an efficient alternative to conventional bus and rail services in which the demand is diffused spatially, temporally, or both (1). They also appear to be a suitable solution to fill the gap between the extreme comfort and flexibility of private cars and the reduced costs and impacts of public transportation. They may be able to encourage a modal shift from private cars to transportation alternatives with less environmental impact. Of these modes, carsharing systems, which involve a few cars shared among many users, yield three main advantages: cost sharing, earth sharing, and road sharing (2). Carsharing systems have grown considerably in North America during the past decade and have flourished within metropolitan regions across the United States and Canada. The result has been a new transportation landscape, which offers urban residents an alternative to automobile-based mobility without car ownership (3). A number of studies have addressed carsharing with respect to its feasibility, operation, and safety aspects (4–8). Other studies, such as DIME, University of Genoa, Via Montallegro 1, 16145 Genoa, Italy. Corresponding author: N. Sacco,
[email protected]. Transportation Research Record: Journal of the Transportation Research Board, No. 2319, Transportation Research Board of the National Academies, Washington, D.C., 2012, pp. 113–120. DOI: 10.3141/2319-13 113
114
Transportation Research Record 2319
methods, the user loses privacy and accrues minor cost savings in transportation. In operator-based methods, a burden is imposed on the operator to employ extra staff and incur added transportation costs. In the present study, a carsharing simulator was developed, with the use of an innovative, user-based technique to relocate vehicles across stations. The aim was to minimize the rejection ratio of reservations in any period through the attempt to have enough vehicles in each zone to satisfy demand. Here, the vehicles were relocated by users that ended their trips at a destination close to the zone with a shortage of vehicles. For this purpose, the system was modeled as a discrete event system (DES), and a relocation method was proposed on the basis of a linear integer programming problem. The choice of the DES framework was driven by the need to model the complex macrodynamics of carsharing in a stochastic environment (i.e., the interaction between the trip demand and the vehicle supply) without the need to take into account the microchanges that arose from the vehicle kinematics. A similar methodology was used recently in a study of the European City Alternative Transport System to develop and evaluate a new system with a single type of vehicle for individual use or collective transport (16). In the present study, several additional assumptions were made to develop a simulation as close as possible to the real world. Here it was assumed that the reservations were spread throughout the day, according to a Poisson distribution, and the times between two subsequent reservation requests were modeled as exponential stochastic variables, with the ratio given by the origin–destination matrix elements. It also was assumed that travelers did not pick up vehicles at specified locations but in a restricted subarea, referred to here as a “zone,” and the interval in which they could pick up their vehicles was limited. They were to drop off the vehicles at either their own specified zone or at a zone proposed by the system. Parking areas within either zone were not specified. One vehicle was assigned to each request, and vehicles could not be shared to meet different demands at a time. There was a given probability that any reservation could be canceled or modified (e.g., either time or vehicle, or both) by the user. This paper is organized as follows. First, the system dynamics of the carsharing problem and the relative discrete event modeling are described. Various events that might occur in the system are described in this section. Then the relocation method is presented, followed by a discussion of simulation results. DES Basics DES may be defined as a system in which the events eh, h = 1, . . . , H, which informally can be considered to be instantaneous, cause a transition from one state xk to another state xk+1 of the system. In addition, the states can assume nonnumerical or logic values (17). The set of all the admissible events, namely, the space of events, is referred to here as E, whereas the set of all the possible system states, namely, the space of states, is referred to here as X. The system dynamics is given by the state equation x k +1 = δ ( x k , ek )
k = 0, 1, . . .
(1)
where k = counter as h, or generic element of set (as in k = {accept, not accept}), which provides the (k + 1)th state, xk+1, as a function of the kth occurred event, ek ∈ E, and the kth state, xk. In such an equation, the generic state function δ(•) may be expressed as a flowchart, as a computer program, or as a mathematical equation.
In a DES, the time variable, indicated as τ, depends on the event occurrence, and is updated when, and only when, an event occurs. In this framework, the sequences of the couples (xk, τk), in which τk is the time instant at which the event ek occurs, indicate the state trajectories. With respect to modeling capabilities, the DES allows easy representation of the macrochanges that occur in a system (e.g., the beginning and the end of an operation) while it neglects the microchanges that occur continuously, and thus makes it possible to model large systems. In addition, the DES makes it possible to explicitly represent synchronization (i.e., two or more conditions must be met so that an event can occur) and parallelism (i.e., two or more separate system subdynamics can evolve without interactions for a certain period of time). With reference to carsharing systems, examples of such dynamics may be the realization of all the conditions that allow a vehicle reservation, and the independent behavior of the various vehicles. Usually, the DES is too complex to study analytically and often is simulated with computer programs (18). In this study, a simulator was developed on the basis of the flowcharts that constituted the state function δ(•), as described in the following section. System Dynamics Carsharing systems constitute a transportation mode in which a limited number of cars are shared among a large number of users, who may book a vehicle for a specific time interval. In the traditional system, users pick up and release the vehicle at the same (a priori, defined) place. In the one-way system, users may release the vehicle at a location other than the one where their trip originated. The latter system was the one considered in this study and was represented by a DES model, which took into account, via simulation, the major dynamics of the whole system, and provided a performance evaluation. Both traditional and one-way carsharing services are characterized by a set of events that modify the state of each vehicle [e.g., increase or decrease in number of reservations, vehicle position, vehicle motion state (in use or parked)]. In one-way carsharing systems, users are required to declare their trip destination (usually in a relatively small area, referred to here as a “covered area”) so that the system manager can forecast the positions of vehicles in the near future and then be able to optimize the vehicle distribution in the covered area. It is well known that the most difficult problem within the one-way framework is to maintain a suitable distribution of vehicles within the covered area and thus to avoid either the concentration of a great number of vehicles in an area with scarce demand or a lack of vehicles in areas with high demand. Within this framework, traditional carsharing can be considered a particular case of one-way carsharing, in which the trip destination coincides with its origin. Formulation of Discrete Event Model Consider a carsharing system in which a fleet gathers nv vehicles parked anywhere in the covered area; it is a situation typical of one-way carsharing. The event space E gathers the following events: 1. eres = vehicle booking, 2. emod = booking modification, 3. ecanc = booking cancelation, 4. epick = vehicle pickup, and 5. edrop = vehicle drop-off. The state space, X, consists of the set of all possible values of the vector
Di Febbraro, Sacco, and Saeednia
T
(2)
where each generic term, xj,k, represents the state of the jth vehicle, j = 1, . . . , nv, after the occurrence of the kth event, and consists of the vector sj,k xi,k ∈ , sj,k ∈ {parked, on trip} hj,k
h j,k = 0, 1, 2, . . .
Vehicle Reservation Event The vehicle reservation event, eres, consists of the booking of a car in a specific zone for travel that can be accomplished if and only if at least one vehicle is available in that zone. Within this framework, a
parked 0 ecanc edrop emod
parked 1
on trip 0
epick
eres
eres
ecanc
edrop emod
parked 2 eres
eres
ecanc
emod
on trip 1
epick
...
epick
k+1
e b e T bj,k −1 T j,k −1 T j,k +1 T j,k +1
k T bj,k T ej,k
T
k−1
k+1
k
e b b e T bj,k −1 T j,k −1 T j,k +1 T j,k T j,k +1
T ej,k
T
FIGURE 2 Schedule constraint for jth vehicle [(k + 1)th is inadmissible when it overlaps reservations already scheduled].
free vehicle is one that satisfies the so-called “scheduling constraint,” which is defined as a reservation for the time interval [τ b, τ e] is admissible for the jth vehicle, if it does not overlap the previously scheduled ones, as depicted in Figure 2. As soon as a vehicle is booked, its presence in the area is guaranteed at the beginning of the trip. Thus further events are avoided that might make the reservation infeasible. Let τk,res be the occurring time of the kth reservation. The carsharing user may either book a specific vehicle j, j = 1, . . . , nv, for the time interval [τ bj,k, τ ej,k], from the origin zone oj,k (or, more specifically, from a generic point inside the origin zone), to the destination zone dj,k (or, more specifically, to a generic point inside the destination zone). Alternatively, the user might ask the carsharing system manager to provide the nearest available vehicle for use during the same time interval. In the first case, the manager simply verifies whether or not the desired vehicle can be booked, given the scheduling constraints. In the second case, the manager looks for the nearest available vehicle that fulfills the above constraint. In both cases, the manager gives the user the information needed to reach the nearest available vehicle. With respect to the system state, the occurrence of such an event implies the scheduling of the pickup event, epick. Because there is a given probability that the user will cancel or modify the event after the reservation is processed, a cancelation event, ecanc, or a modification event, emod, may be scheduled. Such dynamics are illustrated in Figure 2: any state reached after a reservation event acknowledges vehicle pickup, modification, cancelation, and a further reservation event. A flowchart, which represents the conditions and the dynamics of the reservation event, is depicted in Figure 3a. As mentioned earlier, reservation events were characterized by a set of parameters defined on the basis of real-world data, such as the following: 1. Occurrence times, 2. Zones of origin and destinations of trip, and 3. Elapsed time between reservation and vehicle pickup.
ecanc
edrop emod
k−1
(3)
where the first element of the vector, sj,k, indicates whether the jth vehicle is traveling or is parked, whereas the second element indicates the number of trips already scheduled for it. Any possible event that changes the vehicle state for the generic vehicle j, j = 1, . . . , to the number of vehicles (nv), is represented in the automaton of Figure 1, where it is also possible to see that not all events are feasible in any state. Ideally, infinite states might be reached for each vehicle j, j = 1, . . . , nv (which correspond to an infinite number of scheduled trips). In practice, however, these events are limited. Normally, reservations are made within a limited amount of time in advance. In the model presented here, the number of reservations was directly associated with the vehicles, instead of the zones of the covered area, an important association to consider given that a fleet of vehicles might include various classes (e.g., vehicles for users with disabilities, electric vehicles with particular dimensions).
eres
Valid
. . . x nv,k
x 2,k
Not Valid
x = x1,k
115
Then let ...
emod
FIGURE 1 Automaton of states and events that characterize generic jth vehicle dynamics.
OD = od i, j i, j =1,...,nz
(4)
be the origin–destination matrix of the considered area (divided into nz zones), which is assumed to be constant over a given period τ. Each element of such a matrix represents the number of
116
Transportation Research Record 2319
A new request for booking the j th vehicle in the time interval [T bj,k , T ej,k ] arrives in the zone z at T bk
Is a particular vehicle specified?
The CS system manager looks for the nearest vehicle in z that can be reserved, then communicates it to the user
no
A request occurs in Tk modifying the h th booking of the j th vehicle by changing the vehicle (kind 1), the reservation interval [T bj,h , T ej,h] (kind 2), or both (kind 3)
yes no
Is the time constraint fulfilled?
no
yes
Are there any?
The reservation is not accepted
yes
A new reservation event is scheduled
The reservation is accepted, and pickup event in T bj,k is scheduled A new reservation and, with given probabilities, the cancellation or modification events are scheduled
(a)
Does the reservation fulfill the time constraint? The pickup event of the h th reservation of the j th vehicle is removed from the SEL
yes
The modification is not accepted
no The modification is accepted
(b)
(c) ∧
In T ej,k – T the CS system manager evaluates the best destination for the vehicle j. If it is different from the one formerly chosen, it proposes the new one to the user
Does the user accept to drop-off in a different zone?
The j th vehicle is picked up in T bj,k
yes
The drop-off event and the destination zone of the user are updated
no The reallocation and the drop off events are scheduled in ∧ e e T j,k – T and T j,k , respectively
The j th vehicle is dropped off at the chosen destination, and the relevant statistics are updated
(d)
(e)
The drop off event and the destination zone of the user are not updated
(f)
FIGURE 3 Flowcharts of events in considered system.
users, who each period τ request a vehicle for a trip from i to j. Then the quantity nz
T ( i ) = ∑ od i, j
∀i = 1, . . . , nz
(5)
j =1
represents the mean number of bookings during a period τ that occurs in the origin zone i toward any destination. The reservation events are assumed to be a Poissonian process [i.e., the time elapsed between two subsequent reservation events is represented by means of an exponential stochastic variable with rate λ = T(i)]. Then the destination j of the trips originated in the zone i is characterized by the probabilities pi ( j ) =
od i, j T (i )
∀i = 1, . . . , nz; j = 1, . . . , nz
(6)
The elapsed time between the reservation and vehicle pickup was modeled with a stochastic variable distributed uniformly between 0 and 1 h to represent the complete uncertainty of such a parameter and the fact that one-way carsharing users do not in general book trips far in advance.
Reservation Cancelation and Modification To increase the level of carsharing service, users are allowed to modify their bookings. To schedule a cancelation event, ecanc, simply involves the removal of a specific reservation event. No change is made to any other system parameter, but the state of the vehicle is modified as depicted in Figure 1. The modification event, emod, which occurs in τk with a request to modify the hth reservation, changes the scheduled pickup time τ bj,k,
Di Febbraro, Sacco, and Saeednia e the drop-off time τ j,k , the pickup zone (which requires a new vehicle search), or all of the above. Evidently, these modifications are possible only if the scheduling constraint is met in the new configuration. As shown in Figure 1, if a request is not made to change a vehicle, the modification event does not change the system state, because it does not add or remove any reservation. The cancellation and modification events are shown in Figure 3, b and c, respectively.
Vehicle Pickup The pickup of the jth vehicle event, epick, is the event that occurs at τ bj,k to change the state of the jth vehicle from parked to en route. At the occurrence of such an event, the system schedules the jth vehicle e release in τ j,k in a zone specified by the user as the destination. Then the position of the vehicle is updated, which depends on the declared destination and trip duration (Figure 3d).
117
The main components to be determined in this relocation algorithm are first the optimal locations where vehicles should be dropped off to satisfy future demand (Phase I) and, second, the amount of the fare discount to be offered to those users that agree to change their destinations, which depends on the distance between the user-chosen and operator-proposed stations (Phase II). In the present study, only the optimization problem relevant to Phase I was considered. With respect to Phase I, the relocation problem is how to minimize the rejection ratio of reservations in any period through the attempt to have in place sufficient vehicles in each zone to satisfy the demand. Because different zones have different demand rates at different instants, a good schedule provides cars in locations wherever demand is the highest at any given time. In other words, the aim of the relocation is to have exactly T(i) vehicles, i = 1, . . . , nv, in all the zones, during a specified period. Let xi,v, ∀i, ∀v, be the variable that indicates the position of each vehicle: in particular, xi,v = 1 if the vehicle v is in i. With this definition, the optimization problem may be stated as nz
nv
i =1
v =1
min ∑ T ( i ) − ∑ xi,v Vehicle Drop-Off The drop-off event, edrop, represents the drop-off of the vehicle in the user-determined destination zone within the covered area. In this system, the user may leave the vehicle in any available parking space. The management of such an event is easy because it is not necessary to accomplish any condition for the event to occur. From a system dynamics point of view, this event simply causes a transition of the element sj,k of the state xj,k from en route to parked, with no modification of the number of scheduled reservations (Figure 3e).
Relocation The last event to be considered is the relocation event, which improves carsharing through a computation of the best positions in which users “should” drop off vehicles in the covered area. Optimal positions for return are determined for each vehicle, and a fixed time interval is set in which to drop the vehicle off. This information is transmitted to users, together with the offer of a fare discount for returning the vehicle to the proposed destination. Obviously, each user decides whether or not to accept the proposal. The optimization problem of such an event is explained in the next section and is depicted in Figure 3e. Such an event occurs within a given amount of time, τ, which has to be suitably tuned before any drop-off event. Therefore, the whole procedure results in a rolling horizon optimization, in which a new optimal solution is computed at any drop-off occurrence. In fact, as soon as a drop-off event occurs, only the variable will be fixed that corresponds to the vehicle to be dropped off soon after the solution search; the others can be changed during the next optimization run.
subject to nz
∑x
i, v
=1
∀v
i =1
xi ,v = 1
∀v ∈ V ~
xi,v ∈{0, 1}
∀i , ∀v
(7)
where the absolute value in the objective function tries to avoid the presence of a different number of vehicles from T(i) in i. The first constraint states that each vehicle is in one, and only one, zone at any time, whereas the second constraint excludes vehicles that cannot be relocated, gathered in the set V∼, by the assignment of some vehicles – permanently to specific zones i . To solve this nonlinear problem, it may be reformulated as a linear integer programming problem through the modification of the cost function and the addition of some new constraints. Then, if the number of variables is small enough (some hundreds), the problem can be solved by means of a classical branch and bound approach. As Figure 3f shows, users can decide whether or not to agree to drop off the vehicle at the location suggested by the system. If their choices are modeled as discrete choices, the relevant probabilities can be computed by means of a binomial logit model. The utility may be written as U k = Vk + ε k , k = {accept, not accept}
(8)
where εk is a Gumbel stochastic variable with zero mean and variance πθ2/6, and
Optimal Relocation
Vnot accept = β not accept
In the proposed user-based relocation algorithm, users are given an incentive, in the form of a discount, if they agree to park the car they used in the location proposed by the system rather than leave it at their chosen location.
Vaccept = β d d + β s s
(9)
in which the systematic utilities are d (the distance between the “wished for” and “proposed” parking zones) and s (the applied
118
Transportation Research Record 2319
discount), with the relevant weighting coefficients β. With these definitions, the probabilities are p [ accept ] =
e e
Vaccept
Vaccept
+e
Vnot accept
p [ not accept ] = 1 − p [ accept ]
(10)
The logit framework appears suitable to use to model user choices, but the parameters θ and βi are difficult to estimate because specific data are lacking. In addition, the discount s may be a further variable to optimize through the definition of a more complex framework. In the case study described in the next section, the various scenarios were assumed to have fixed acceptance probabilities so that the potential of the proposed optimization procedure could be assessed without the need to tune the logit model.
Case Study To evaluate the model and the efficacy of the relocation procedure, the carsharing model and optimization procedure were tested in the traffic-restricted zone of Turin, Italy, in which only public vehicles, carsharing vehicles, and those of the local residents were allowed to enter and circulate. A traditional carsharing service has been active in Turin since July 2011, with 117 vehicles, 89 dedicated parking areas (Figure 4), and about 2,800 users (19). Given some assumptions about demand, the case study aimed to estimate the performances that might be achieved through the introduction of a one-way service. For this purpose, only the restricted area highlighted in Figure 4 was considered, which covered an area of about 3.5 km2. This area is characterized by mixed use, and is divided into nine main subzones. The sizes of these zones range from 0.125 km2 (Zone 6) to 0.5 km2 (Zone 2),
FIGURE 4 Map of Turin with parking areas dedicated to carsharing and traffic-restricted zone.
Di Febbraro, Sacco, and Saeednia
119
TABLE 1 Origin–Destination Matrices of Traffic-Restricted Zone, Turin, Italy (Nonzero Elements) Morning Peak Hour
Afternoon Peak Hour
Rest of Day
Pair
Mean Reservations per Hour
Pair
Mean Reservations per Hour
Pair
Mean Reservations per Hour
7, 4 8, 4 10, 4 7, 5 8, 5 10, 5 10, 6 — — — — — — —
0.125 1.125 0.375 0.5 0.5 0.25 0.125 — — — — — — —
4, 4 5, 4 4, 5 7, 6 8, 6 6, 7 8, 7 9, 7 6, 8 7, 8 9, 8 7, 9 8, 9 7, 10
0.375 0.5 0.625 0.875 0.5 0.375 0.875 1.125 0.75 0.75 0.125 1.125 1.125 0.625
4, 7 5, 7 6, 7 7, 7 4, 8 5, 8 6, 8 8, 8 4, 10 5, 10 6, 10 — — —
0.25 0.25 0.375 0.125 0.5 0.25 0.75 0.125 0.25 0.125 0.125 — — —
Note: — = not applicable; no existing relations between pairs in relevant time period.
and they are dispersed throughout the city in areas in which many people work (Zones 2 and 5), historical sectors (Zones 1 and 2), residential areas (Zones 3, 4, 7 and 8), an academic site (Zone 6), and a shopping district (Zone 9). It was assumed that the 10th zone, which surrounded the highlighted area in Figure 4, included all external demand, and that vehicles also could be left in the carsharing parking area indicated in Figure 4. Under the above assumptions, trips from the external zone to the traffic-restricted zone, and vice versa, were considered separate trips. With respect to the assumed mobility demand, the “morning,” “whole day,” and “evening” demand matrices are reported in Table 1. They were estimated on the basis of actual demand and were expressed as hourly demand rates. The morning and evening demand matrices mostly consisted of commuting trips, whereas trips to and from other zones were spread throughout the day. The simulation parameters are reported in Table 2. To obtain results, 15 scenarios were tested. They differed according to the probability that users would agree to the relocation proposal and involved various numbers of vehicles that served the system. Table 3 shows the results of the simulation runs, which were done with the DES model. As shown, five vehicles were not enough to meet existing demand. Between 20% and 30% of the reservations were rejected for all sce-
TABLE 2 Parameters of Simulation Parameter
Value
Simulated period Percentage of modifications Percentage of cancellations Time between relocation and drop-off events Trip duration (mean, SD)
30 days 10% 5% τ = 10 min 1 h, 20 min
Note: SD = standard deviation.
narios. Once the number of available vehicles was increased by five, the rejection rate decreased significantly. Also, the rejection figure showed a decreasing trend as the acceptance probability of the relocation increased. With 15 vehicles, reservations declined by a small percentage, which showed that this number of vehicles was not optimal in terms of benefit to the operator. It was possible to obtain almost the same rejection percentage with “no relocation,” with 10 vehicles, and 75% relocation acceptance. All of the relocations were made by users of the system. The results had their basis in hypothetical acceptance rates. The next step would be to define the discounts that led to the above-assumed rates.
Conclusions In this study, a user-based carsharing relocation methodology was tested in which customers had the choice either to drop off a car at their desired location or to agree to drop it off in a place proposed by the system manager. With a DES model and a relocation process that had its basis in the solution of a linear integer programming problem, it was shown that the number of vehicles needed to run the system efficiently, as
TABLE 3 Percentages of Reservation Rejections for Various System Configurations Relocation Acceptance Probability (%) Number of Vehicles 5 10 15
No Relocation
25%
50%
75%
100%
28.5 7.58 1.18
27.85 6.8 .69
23.78 3.2 .3
26.5 1.6
