Joint relocation and pricing in electric car-sharing systems

In this paper we study the integrated planning problem of determining car-sharing prices between zones of the operating area and routing employees (operators) to relocate cars in preparation for future uncertain demand. We present a novel two-stage integer stochastic programming model for this problem together with a heuristic algorithm, based on Adaptive Large Neighborhood Search (ALNS), to obtain solutions to realistically sized instances. We test the ALNS heuristic on a set of instances generated based on data from a real car-sharing organization and show that it outperforms a commercial solver.


Introduction
Car-sharing has experienced significant growth in recent years and is expected to further increase in popularity (Schiller et al., 2017).Carsharing systems are typically divided into station-based and free-floating.In station-based systems, cars must be picked up from and returned to one of the available service stations.In free-floating systems, cars can be returned to any common parking space within the operating area.Both systems can be configured for either one-way rentals, where cars can returned to a station/location different from the pick-up location, or two-way rentals, where cars must be returned where they were picked up.
One-way free-floating systems have gained popularity due to the higher level of flexibility for the users.However, such configuration makes the system vulnerable to geographical and temporal mismatches between supply and demand.As a prime form of response, the carsharing organization (CSO) normally relocates cars to areas where demand is high and away from areas where demand is low (Boldrini et al., 2017).These rebalancing activities are performed by dedicated staff, hence the name operator-based rebalancing.In the situation when the fleet consists of electric cars -which has become very common in recent years (Cheng et al., 2019) -an even more important task for the employees is to ensure that cars with depleted batteries are driven to charging stations.
Most CSOs today use pricing strategies that consist of a fixed perminute fee independent of time of the day, origin and destination of the trip, or other factors.However, in many industries revenue management practices help better utilize customers' differences in their willingness to pay for a given service, and through that increase profits, e.g., Klein et al. (2020).In car-sharing systems, this could translate e.g., into time-or zone-dependent fees.In addition, such pricing strategies may become instrumental in reducing the need for operator-based relocations.For example, a CSO could set a low, or even negative, price for trips originating in a zone where there is already an abundance of cars and terminating to a zone where the demand exceeds supply, or to a charging station if the battery level of the car is low.Synergies could arise from jointly optimizing pricing and relocation decisions.
Therefore, in this paper we consider the operational planning problem faced by a CSO of jointly setting car-sharing prices and deciding operator-based relocations to face future (uncertain) demand and maximize (expected) profits.Particularly, the pricing strategy we consider consists of setting origin-and destination-specific prices in order to favor (prevent) (un)favorable movements of cars.To account for uncertainty in customer preferences with respect to the mode of transport, we model this problem as a stochastic program and denote it as the Stochastic Electric Vehicle Relocation and Pricing Problem (SE-VRePP).The main contributions of this paper can be summarized as follows: (1) we propose a novel two-stage stochastic integer programming model for the SE-VRePP which addresses pricing decisions as well as the relocation activities, including detailed routing and scheduling of the operators' (employees') tasks; (2) we develop an Adaptive Large Neighborhood Search (ALNS) heuristic for solving realistically-sized instances; (3) we test the ALNS heuristic on a set of instances generated based on data from Vybil, which is a real CSO operating in Oslo, Norway; and (4) we analyze the effect of jointly planning pricing and relocation decisions https://doi.org/10.1016/j.ejor.2023.12.001Received 11 January 2023; Accepted 1 December 2023 through simulations offering managerial insights.As further explained in Section 2, the literature on joint pricing and relocation decisions is sparse and this study extends it in a number of ways.
The outline of the remainder of this paper is as follows.Section 2 presents a review of the relevant literature, while Section 3 gives a detailed description of the SE-VRePP and formulates it as a two-stage stochastic programming model.Section 4 outlines the heuristic solution algorithm.Finally, the computational study is presented in Section 5, before we draw some concluding remarks in Section 6.

Summary of the available literature
Operator-based rebalancing of cars is one of the main challenges for CSOs.To address this challenge, the scientific literature has grown substantially since the onset of car-sharing services, providing methods for various configurations of the system.Examples are methods that focus on addressing rental demand uncertainty using a variety of methods including prediction, (Hellem et al., 2021;Weikl & Bogenberger, 2013), machine learning, and data driven optimization or stochastic programming (Brandstätter et al., 2017;Fan, 2013;Huo et al., 2020;Li et al., 2019;Santoso et al., 2005).Particular attention has also been paid to the growing adoption of electric fleets, see e.g., Boyacı et al. (2015Boyacı et al. ( , 2017)), Bruglieri et al. (2014), Folkestad et al. (2019), Hellem et al. (2021), Xu and Meng (2019).The surveys in Golalikhani et al. (2021), Illgen and Höck (2019), Wu and Xu (2022) provide thorough analyses of the available models and methods.
Operator-based rebalancing is, however, inherently inefficient and expensive in the large scale, especially if performed while the system in being used most (e.g., during day hours).For this reason, pricingbased mechanisms to balance demand and supply at the geographical and temporal level have been proposed.The central concept of such method is to make more attractive certain movements of cars that are, for various reasons, considered beneficial by the CSO.
The research literature on pricing method is also growing considerably.A classification of the literature is proposed by Pantuso (2022), who divide the proposed pricing strategies in individual and collective.Individual pricing strategies require an interaction between the CSO and the individual user by means of which the trip details (including price) are agreed upon.As an example, the CSO may offer a specific user a reward in exchange for returning the car to a more favorable position.Further examples of individual pricing strategies can be found, e.g., in Wagner et al. (2015), Waserhole andJost (2016), Di Febbraro et al. (2018), Stokkink and Geroliminis (2021), Liu et al. (2021), Wu et al. (2021), Wang et al. (2021) and Wang and Ma (2019).Collective pricing strategies are instead targeted to the entire user base and aim to influence the rental demand by means of prices.As an example, the CSO may decrease the price of rentals to/from selected zones.Further examples of collective pricing strategies can be found, e.g., in Jorge et al. (2015), Hansen and Pantuso (2018), Kamatani et al. (2019), Xu et al. (2018), Xie et al. (2019), Ren et al. (2019), Lu et al. (2021), Kikuchi and Miwa (2021), Pantuso (2020), Li et al. (2022) and Pantuso (2022).It should be noted however, that the classification is not meant to be precise as some methods could be classified equally well in both categories.
From the analysis of the research literature, it emerges that both pricing and relocation decisions have received considerable attention in the research literature, and method are available for various configurations of the car-sharing service.Nevertheless, the gap that emerges from the literature, is that pricing and relocation decisions have mainly been considered as separate entities.We argue instead that since they may be used to ease the balance between demand and supply, they should be considered in the same decision process, and that the combination of the two can reinforce the ability of the CSO to prevent imbalances.Contributions in this direction, can be found in Xu et al. (2018), Li et al. (2022) and Pantuso (2022).Xu et al. (2018) formulate the joint pricing and relocation problem as a non-linear mixed-integer programming problem in order to account for demand elasticity.We show that the problem can be formulated using a linear mixed-integer two-stage stochastic programming problem by accounting directly for uncertainty in individual customers preferences.Li et al. (2022) present a simulation-optimization framework to determine both the prices between car-sharing stations and the relocations to perform.However, the optimization model does not explicitly determine the activities of the operations, which are instead taken care of by the simulation framework.In this paper, we extend the recipe of Pantuso (2022), which model the joint problem of deciding car-sharing prices and relocations by a two-stage stochastic program to account for the uncertainty in customer's preferences in terms of transport mode.However, in contrast to our work, rebalancing decisions are modeled at a rather high level of abstraction.Particularly, they model the number of relocations to perform between zones without addressing how such movements should be performed in practice by operators (and even if these are feasible given the available staff).We fill this gap by adding to pricing decisions a more detailed model of operators activities.In addition, we ensure that the expected number of cars with low battery levels relocated to charging stations (either by employees or by customers) exceeds a given threshold.This allows us to adjust prices also in such a way to incentivize recharging activities made by customers.

Problem description and mathematical model
We formulate the SE-VRePP as a two-stage stochastic integer program where prices and relocations are decided in the first decision stage and rentals are decided in the second decision stage.We start by describing the problem and introducing the mathematical notation in Section 3.1 before presenting the full mathematical model in Section 3.2.

Problem description and notation
We assume the CSO operates a homogeneous set  of electric vehicles in a business area which is suitably partitioned in a set  of zones.A subset   ⊆  of the zones includes the zones containing charging stations.The number of available charging spots in zone  ∈   is given by    .Observe that the zones containing charging stations can be used both for normal parking as well as for charging cars.
In order to maximize expected profits for a given target period (e.g., two hours in the morning or afternoon), some time before the beginning of the target period, the CSO makes decisions regarding the prices applicable during the target period and how to relocate cars within the business area in preparation for the target period.
At the time decisions are made, each car  initially located in zone () ∈ .A subset of cars   ⊂  contains the cars in need of charging.We assume that, in order to ensure continuity of the service, at least a fraction   of the cars in need of charging must be brought to a charging station, either by operators or as a result of rentals.
In order to perform relocations and recharging activities, we assume that the CSO employs a homogeneous set  of operators with operator  located in zone () at the time decisions are made.We assume operator are possibly initially occupied in relocation tasks assigned to them during previous planning phases.The earliest start time employee  is available for performing a task is given by    .Each operator has a set  of abstract tasks used to keep track of the sequence of car moves to perform.The set of possible car-moves that can be performed by operators for all cars is given by .We identify the origin and the destination of car-move  by () and ().An abstract task  ∈  becomes concrete once it is assigned to a specific carmove  ∈ .We also define the subset    of car-moves available for each car  (observe, e.g., that for cars in need of charging    only includes moves to charging stations), and the subset    for all carmoves with destination zone .   ⊆    contains the set of car-moves with destination at charging zone  (also referred to as charging moves).
It should be noted that cars in need of charging can only be moved to a charging zone (a zone with at least one charging station).This move can be done by either an operator or a customer.Cars not in need of charging can be moved to all zones, including charging zones.However, cars not in need of charging will not occupy a charging station slot if moved to a charging zone.Furthermore, we assume that a car is labeled 'in need of charging' if its battery level is below a certain threshold.At this point, if the car is to be moved, it must be moved to a charging zone (a zone with at least one charging station), and further be put to charging (either by an employee or a customer).This means that a car in need of charging is still available for a customer to rent, but the customer must drive it to a charging station within a charging zone (and the customer will be informed about it).For this to work, we assume a car in need of charging always has enough battery capacity to reach any available charging station in the operating area.Since cars may be busy at the time of planning (e.g., due to ongoing relocations) we let the first time point when a car is available for a car-move  be    .Similar to Hellem et al. (2021) and others, we assume that the operators can travel between car moves by using folding bicycles that can fit into the trunk of the cars or by using public transport (whichever is fastest).Therefore, we let    be the time necessary to complete carmove .This parameter includes the time it takes to get from the origin to the destination zone of the car-move, in addition to the approximated time it takes to find a parking spot or initiate charging.The time it takes to travel between zones  and  is given by   .Let also   be the cost per time unity of driving a car.The salary for the given set of employees is assumed fixed and therefore not a part of the model.We let time  1 represent the time when the target period starts.This entails that all relocation activities must be completed before  1 .We let binary variable   take the value 1 if car  is made available to customers in zone  at the beginning of the target period, 0 otherwise, as a result of the operator-based relocations.Furthermore, binary variable   takes the value 1 if operator  performs car-move  as their task number , 0 otherwise.We also let non-negative variable   represent the time when operator  starts performing task .
In addition to relocation activities, by adjusting rental prices between the different zones of the operating area, the CSO can make certain cars and trips more (or less) attractive to customers.Particularly, similarly to Pantuso (2020Pantuso ( , 2022)), we assume that the pricing mechanism is made of a per-minute fee independent of the origin and destination of the trip, and a pick-up/drop-off fee which instead depends on the origin and destination zones of the trip.We assume the CSO can adopt a set  of pick-up/drop-off fee levels, with   being the dollar value of fee .Consequently, we define binary variable   to take value 1 if level  is chosen between zone  and , 0 otherwise.
Once pricing and relocation decisions have been made, during the target period customers interact with the car-sharing service.We let  be the set of all potential car-sharing customers.Particularly, this set includes all the customers requiring transportation within the operating area, independently of the transportation mode.We define subsets   and   containing the customers traveling from zone , and from zone  to zone , respectively.
Rental demand is, nevertheless, uncertain at the time of planning.In fact, customers react to pricing decisions and choose their preferred mode of transport in a way that is partially unknown to the decision maker.Particularly, we assume each customer is characterized by unique preferences, captured by a well-specified choice model (Bierlaire & Sharif Azadeh, 2016).This entails that the random term of the choice model is a fully specified random variable.In line with Paneque et al. (2021), Pantuso (2020Pantuso ( , 2022)), we assume that each customer chooses the transport mode that maximizes their utility.Given a set  = {, …} of transport services (which includes car-sharing), the utility received by customer  when using transport service  to move from its origin () to its destination () is given by  ) is the driving time between () and ().For other transport services ,  (),(), is a known parameter.The random variable ξ , with ξ ∶= ( ξ ) ∈,∈ , captures the portion of the customer's preferences unknown to the CSO.Different specifications of a probability distribution for ξ lead to different choice models, see e.g., Train (2009).We let  be a set of realizations (scenarios) of ξ, with   being the probability of scenario , and   the realization of ξ under scenario , that is   ∶= (  ) ∈,∈ .
Given a scenario , the random element of the choice model   materializes, and the preferences of each customer with respect to the transport mode are fully known for that scenario.For each scenario we initialize a set of customer requests, (  ).The set (  ) contains a request for each customer  for which there exists at least one fee level  in  for which the customer would prefer car-sharing over other transport alternative.That is, there exists at least one fee level for which the customer finds their highest utility in using car-sharing.(Observe, thus, that the customers which would never prefer carsharing regardless of the fee, are not in the set).More formally, there exists one request for each customer  for which Most car-sharing services operate with a First-Come-First-Served mechanism (Wang & Liao, 2021).For this reason we let set   (  ) = { ∈ (  ) ∶ () = (), () < ()} ⊆ (  ) contain the requests that have precedence over request , i.e., we simply assume that the index of the customer indicates the arrival time at the vehicle.Finally, we let   ⊆  be the subset of fees that are less than the highest fee level acceptable for request , () and   be the profit of satisfying request  with fee level  (i.e., the sum of the per-minute fee of the trip and the pick-up and drop-off fees).
During the target period (second decision stage) cars are rented by customers.We let binary variable   take the value 1 if car  satisfies request  with the fee level  in scenario , 0 otherwise.Observe that   are second-stage decision variables and are defined for each scenario .
All the notation is summarized in Appendix A.

Model
In this section, we present the mathematical model for the SE-VRePP.
The objective function (1a) represents the total expected profit for the CSO.The first term represents the (deterministic) costs born to perform operator-based relocations, while the second term represents the expected revenue for the rentals occurred during the target period.
The constraints that handle the logic of the first decision stage are as follows.Constraints (1b) ensure that exactly one fee is assigned between each pair of zones.Constraints (1c)-(1f) handle the logic concerning the availability of cars in each zone.Constraints (1c) state that a car in need of charging is not available for rentals if any employee has moved it to a charging station.Constraints (1d) ensure that if a car is relocated to a given zone, it becomes available for rentals in that zone during the target period.Constraints (1e) force a car to be available in its original zone if it is not relocated and similarly unavailable in its original zone if it is moved.Finally, Constraints (1f) make sure that a car is available for rental in at most one zone.
Constraints ( 1g)-(1j) handle the logic concerning the relocation of cars.Constraints (1g) ensure that the tasks assigned to the employees are performed in the given order, that is task  is performed before task  + 1. Constraints (1h) state that any employee task can consist of at most one car-move.Constraints (1i) ensure that each car is relocated at most once.Finally, Constraint (1j) ensures that the expected number of cars in need of charging that are moved to charging stations, either by employees or customers, is higher than the defined threshold.Observe that the number of cars moved by customers to charging stations is influenced by the prices set to and from the charging stations, as it will be more evident in the second-stage constraints.Furthermore, note that this constraint ensures that the threshold is exceeded only on expectation.It is therefore possible that, in some scenarios, there result fewer cars plugged in than desired.However, in the long term, over many repetitions, the Law of Large Numbers ensures that the number of cars plugged in coincides with the expectation.It should be noted that the parameter   can be changed over the course of a day, i.e., from one model run to another.This means for example that if the CSO knows that they will need many cars in the near future, they can increase   and vice versa.In this way, our approach can easily be adapted to the case for when we aim to have a given number of cars available.As an example, suppose there are 30 cars in the fleet out of which six cars are in need of charging, and we aim to have at least 27 cars (i.e., minimum 90% of the fleet should be sufficiently charged).In this case we can set   = 0.5, which will make sure that at least three out of the six cars in need of charging will be moved to a charging station, and we end up with the desired number of available cars of 27 (on average).
Constraints ( 1k)-(1n) handle the temporal aspects of the relocation tasks.Constraints (1k) state that a new task cannot start until the previous task has been completed.Here   is a sufficiently large constant.Note here that the parameter  (),( 1 ) is the travel time (either by folding bikes or public transport, whichever is fastest) between the destination zone of car-move  to the origin zone of car-move  1 .Hence, the constraints ensure that if an employee performs car-move  as it task number , it cannot perform any car-move  1 as it next task  + 1 before the employee has finished car-move  (second term on the lhs) plus the time to travel between the two car-moves (third term on the lhs).Constraints (1l) make sure that the first task of each employee starts after the earliest start time for the employee adjusted with the travel time from the employee's origin to the origin of the car-move.Constraints (1m) ensure that the start time of each task for each employee is after the earliest start time for the specific car-move.Finally, Constraints (1n) make sure that the last task for each employee is completed before the beginning of the target period.
Constraints (1o)-(1y) handle the logic of the second decision stage concerning the assignment of cars to customer requests.Observe that these constraints have to hold almost surely and thus for each scenario.
Constraints (1o) ensure that in none of the scenarios considered the capacities of the charging zones are exceeded.
Constraints (1p) make sure that, for each scenario, each request is satisfied at most by one car at some fee level.Constraints (1q) ensure that each car satisfies at most one request at some fee level.
Constraints (1r) state that a given car can satisfy a request  1 only if it is available in the zone of the request and it is not used by a customer arriving earlier, i.e., a customer with a lower index.Constraints (1s) state that a request  1 at a given fee level  1 must be satisfied by car  if fee level  1 is chosen for that request and the car is available in the origin zone, unless the car has been used to satisfy a request  2 with higher priority or the request  1 has been satisfied by another car  1 .
Constraints (1t) state that request can be satisfied at a given fee level  only if the fee level between its origin and destination has been chosen in the first stage.
Observe that the model assumes that, in the target period, each car satisfies at most one request.In practice, it is possible that the same car is used more than once during the target period, e.g., for several short trips.Therefore, the model proposed provides a pessimistic estimate of actual profits during the target period.

Solution algorithm
The SE-VRePP is an extension of the car-sharing relocation studied by Hellem et al. (2021), where it was shown that a heuristic was needed to solve the problem.Furthermore, the problem is to be solved in a setting where relatively short solution times (i.e., around 10 min) are required to work in a real life setting.For this reason, we propose a heuristic solution algorithm.Particularly, we develop an Adaptive Large Neighborhood Search (ALNS) that addresses pricing decisions, integrated with two different local search algorithms that address pricing and relocation decisions, respectively.An overview of the algorithm is given in Fig. 1.
The algorithm starts by providing an initial solution using a construction heuristic.The initial solution is continuously improved based on different destroy and repair operators that act on the pricing decisions only, following the principles of ALNS (Ropke & Pisinger, 2006).Following, two local search heuristics apply smaller changes to the pricing and relocation decisions, respectively.The motivation for this choice is that we saw in the preliminary testing with the commercial MIP solver (Gurobi) that changes in the pricing decisions had a much larger impact on the objective value than changes in the relocation decisions.Hence, we decided to use a ''heavy machinery'' (i.e., the ALNS) for the pricing, while only using a ''light machinery'' (i.e., local search) for the relocation part.This process continues until a termination condition is met.The final element of the algorithm is the perturbation process following a principle based on Lourenço et al. (2003).This aims for diversifying the search even further in a somewhat similar manner as in Li et al. (2016) where they (i) both run their ALNS algorithm with multiple initial solutions, and (ii) use two destroy operators combined if the best solution has not improved in a number of iterations.In our algorithm, the perturbation is performed only when the solution has not improved for a number of iterations, and it works in a similar manner as a random destroy operator, although destroying a larger part of the pricing solution.
The different elements of the algorithm are described in detail in the following sections.

Solution representation and heuristic objective function
A solution  consists of both a relocation solution,   , and a pricing solution,   (the  and  variables of the model presented in Section 3.2, respectively).The relocation solution,   , consists of an ordered set of tasks (car-moves) to be performed by each employee.The pricing solution,   , is an || × || matrix where entry (, ) represents the fees between zones  and .
The calculation of the value of a heuristic solution is based on objective function (1a).As the representation of the model is different in the heuristic model than in the mathematical formulation, we use a different notation to formulate the heuristic objective function.Let    denote the ordered list of car-moves to be performed by employee  in the relocation solution, and  denote a car-move in this list.Further, recall that the per-minute cost of performing a car-move is   , and that the time to complete car-move  is denoted as    .The heuristic evaluation of the relocation solution can then be written as (2) Let    denote the assigned fee  between zones  and  in the pricing solution.Further recall that (  ) is the set of requests  for a given realization of   in scenario , and that   is the set of fees  sufficiently low to satisfy request  ∈ (  ) for a given realization of   in scenario .Each request  has an origin zone () and a destination zone ().For a given pricing solution    , we create a subset of (  ) with all potential requests  ∈ (  ) with origins () and destinations () which could be satisfied by the fee  =   (),() .Mathematically, this subset, denoted as   (  ), is The set   (  ) is ordered by customer priority, so a request in the set has precedence over all subsequent requests.To determine whether a request  ∈   (  ) is allocated a vehicle in scenario , we must consider the following three requirements: There is a vehicle in the request origin zone, (); If the vehicle is in need of charging, the destination zone, (), must have a charging station with available capacity; The vehicle has not previously been allocated to serve another request with precedence over the current request.The heuristic handles this by iterating over the ordered set of requests   (  ) for each scenario  while checking the three requirements, resulting in the set of satisfied requests for each realization of   for all scenarios ,   (  ).We can therefore express the heuristic evaluation of the pricing solution as Here  is the set of scenarios and  ,  (), (𝑑) is the profit of satisfying request  with fee level  =   (),() , as described in Section 3.1.Combining and maximizing the expressions in Eqs. ( 2) and (3), we get the heuristic objective function defined as   =   +   .

Constructing the initial solution
The construction heuristic starts with an empty solution,  ∅ , and modifies it until a feasible solution is obtained.In the relocation part of the empty solution,   ∅ , none of the employees have any tasks to perform.In the pricing part of the empty solution,   ∅ , the fee assigned for all pairs of zones is the lowest fee.
The only constraint that might make an empty solution infeasible is Constraint (1j), which requires a certain share of the cars with low battery to be plugged in within the target period.To satisfy this constraint, either employees need to relocate the cars to charging stations or customers need to drop off cars to charging stations.To find a feasible solution, charging-moves are added to the task-list of the employees   , provided there is space left.This procedure of adding charging-moves is repeated until the solution satisfies Constraint (1j).
To illustrate this, consider a case with six cars in need of charging.Assume Constraints (1j) demand that at least 50% of the cars in need of charging are to be put to charging.Furthermore, assume that in every scenario, only one customer wants to drop off the car in need of charging at a charging zone.In this case, two cars still need to be moved to charging stations.To meet this requirement, these cars must be relocated by employees.The construction heuristic then iterates over all car-moves moving a car in need of charging to a charging zone, unless the car is the one moved by a customer.Car moves are then randomly assigned to employees provided that their set of tasks respects time limit constraints.

Adaptive large neighborhood search
An outline of the Adaptive Large Neighborhood Search (ALNS) is shown in Algorithm 1.A set of operators are used in the ALNS to explore the neighborhood of a pricing solution.These are divided into two categories, namely destroy and repair operators.The destroy operator breaks down a pricing solution, bringing the solution closer to an empty solution.The repair operator takes the destroyed pricing solution and rebuilds it to a complete solution.

Destroy operators
The destroy operators break down the pricing solution by removing the assigned fees for a predefined number of zone pairs, .The ALNS algorithm has three different destroy operators to choose from.
The random removal operator randomly chooses  pairs of zones and removes their assigned fees.Random removal helps diversify the search space and therefore decreases the chance of getting stuck in a local optimum.
The worst removal operator removes the  zone pairs that contribute the least to the objective value.In combination with a repair operator, this operator helps replace the worst fees with potentially better ones.To help diversify the search, a determinism parameter,   ≥ 1, is included.The list, , of zone pairs is sorted in non-decreasing order of contribution to the objective value (the zone pair at the top of the ranking is the one with the fee that contributes the least to the objective value).The zone pair to be removed from the solution and  is found in  at index  =  (  ) * ||, where  ∈ [0, 1) is a uniformly random number.Consequently, a low value of   increases the degree of randomness, and vice versa.This process is repeated  times.
The related removal operator removes  zone pair fees that are similar based on certain criteria.Shaw (1998) first introduced related removal with the intention of removing similar parts of a solution so that the reconstruction and maintenance of feasibility would be easier.This was also used in the original ALNS by Ropke and Pisinger (2006).We adapt the related removal operator to fit the pricing solution of the SE-VRePP.In order to compare different tuples of zone pairs and fees,  = ((, ), ), a relatedness measure ( 1 ,  2 ) is used.This measure examines the travel distance between both the origin,   ( 1 ,  2 ) and destination   ( 1 ,  2 ) of the tuples  1 and  2 .In addition, the relatedness considers the difference in fees for  1 and  2 .Let  1 and  2 be the fees of the zone pairs of  1 and  2 , respectively.The complete relatedness measure between  1 and  2 is then given by where   ,   and   are weights for the origin zone distance, destination zone distance and difference in fees, respectively.First, a tuple  1 with its zone pair is randomly selected and added to a list of removed zone pairs,   .Next, a random zone pair from   is used to compare to the other zone pairs that are not yet included in   .The relatedness measure is calculated and sorted in ascending order in a new list   .The lower the relatedness ( 1 ,  2 ) is, where  2 is a tuple with a zone pair not in   , the more similar the two pairs are.To allow for some randomness when selecting zone pair from   to remove and add to   , a determinism parameter   ≥ 1 is included.This works in the same manner as for the worst removal operator.The process of choosing zone pairs from   , calculating relatedness with other zone pairs, sorting, and finally selecting the zone pair to remove is repeated  times.

Repair operators
The repair operators take an incomplete pricing solution as input and returns a complete one where all zone pairs have an assigned fee.The repair operators go through the  zone pairs with missing fees and assign these a new fee.The assignment of fees is done according to one out of three different repair operators.
The random insertion operator goes through the set of  zone pairs with missing fees, and randomly assigns it a new fee  from the set of fees .This operator helps diversify the search and can help mitigate the risk of getting stuck in a local optimum.
The greedy insertion operator greedily chooses the fee that increases the objective value the most for each of the  destroyed zone pairs.The order of reassigning new fees to these zone pairs is random.This operator is an efficient way of finding potentially improving fees for the destroyed zone pairs.
The random greedy insertion operator includes some degree of randomness to the greedy insertion operator described above.Similar to worst and related removal, there is a determinism parameter   ≥ 1.For each destroyed zone pair, the random greedy operator evaluates the possible fees, and inserts the fee and the heuristic objective value for using that fee into a list  . .The list is sorted in descending order, so the fee with the highest objective value is at the first index.The fee to be assigned to the zone pair is then chosen in the same manner as for the worst and related removal, where a value of   close to one increases the randomness, and a high value of   increases the chance of choosing the fee with the highest objective value.This process is repeated for each of the  destroyed zone pairs.This operator combines the increased diversification from random insertion with the increased possibilities of choosing fees that positively affect the objective value from the greedy insertion operator.

Choosing destroy and repair operators
Let   and   be the set of all destroy operators and repair operators, respectively, and let   =   ∪   .A pair containing one destroy operator,  ∈   , and one repair operator,  ∈   , is chosen in each iteration of the ALNS.The selection is based on the roulette wheel selection principle where the destroy and repair operators are drawn from a weighted probability distribution of all possible destroy and repair operators.Each pair of destroy and repair operators is associated with a weight,   , where  ∈   , and operators with a good performance in the past get a higher chance of being selected.
Running the ALNS is an iterative process divided into segments, i.e., a batch of iterations.During a segment, data regarding performance for each operator is collected.When a segment is over, we update the operator weights based on these data.The purpose of a segment is to update the weights at regular intervals, after the performance of the destroy and repair operators have been evaluated.This process defines the adaptive part of the ALNS.
At initialization, all weights are assigned a value of 1, making the probability of choosing an operator equal for all operators.During a segment, the chosen operators are assigned a reward, , based on their performance.The rewards are accumulated over the iterations in a segment, resulting in an overall segment evaluation denoted as .An operator can receive different rewards based on whether an operator contributes to a new global best solution, a new local best solution or accepts a non-improving local solution, as shown in Table 1.
At the end of a segment, the operators' weights are updated according to the following equation: , where   is the accumulated reward for operator , and   is the number of times operator  is used in the most recent segment. is a parameter between zero and one, used to control how large an impact the evaluation of an operator in the most recent segment has on the operator's weight.If  is closer to one, the weights are highly determined by the associated operators' success in the most recent segment.However, if  is closer to zero, the weights remain rather stable, only adapting slightly based on the evaluation from the most recent segment.

Acceptance and stopping criterion
When a new solution is constructed by the destroy and repair operators, it is evaluated to see whether it is accepted as the current new solution.We use the simulated annealing acceptance criterion, which is the most commonly used acceptance criterion within ALNS (Santini et al., 2018).We extend this acceptance criterion with the addition of a tabu list to keep track of already explored solutions, in order not to accept any previously evaluated solutions.
The ALNS algorithm stops after a predefined maximum number of iterations.

Local search algorithms
We extend the ALNS with local search heuristics with the aim of finding better solutions in the close neighborhood of the current solution.We include two different local search components, i.e., one to improve the pricing solution,   , and one to improve the relocation solution,   .The inputs to each of the local searches are the solution to be explored and a strategy, either being best improving or first improving.With a best improving search, the entire neighborhood defined by the given Local Search Operators (LSOs) is evaluated, while the first improving search explores the given neighborhood until a better neighbor is found, after which the solution is updated.Independently of the LSO applied, this process is repeated until a stopping criterion is met.

Local search for the pricing solution
We use a single LSO for the pricing solution denoted the price move operator.Recall that the pricing solution consists of a fee between all zone pairs.With the price move operator a solution is said to be a neighboring solution if all fees except one remain the same.Thereby, for a certain solution, one finds the neighbors by altering exactly one of the fees.The price move operator represents the neighborhood as a list of zone pairs.The list is constructed in a random order to broaden the search.The operator iterates over the list, testing different fees for each zone pair.With a first improving search strategy, the iteration stops when an improving solution is found.With a best improving search, the search would span || 2 ⋅ || zone pair fees, returning the best found solution.

Table 2
The test instance types used in the computational study.For each type of test instance, three different versions are generated.

Local search for the operator-based relocation
We propose three LSOs in this search.The add move and the remove move operators investigate whether it is profitable to add or remove a car-move from one of the employees' task lists, respectively.The evaluation is performed by calculating the objective values of the new solutions obtained.The inter swap operator investigates the effect of swapping car-moves present in the solution between employees.This will not have effects on the expected revenues but may reduce the relocation cost and time for each employee, and hence impact the objective value.

Complexity reduction
In order to increase the efficiency of the heuristic search, size reduction techniques and certain computational simplifications have been utilized.

Customers
As discussed in 3.2, the utility a transportation mode yields for a potential customer is composed of a deterministic and a stochastic term.This entails that a potential customer might have different preferences in different scenarios.This may result in a customer preferring carsharing with given price levels in some scenarios, while preferring other means of transportation in others.To reduce the search space, we attempt to separate the customers into two categories: those considered relevant customers and those considered irrelevant customers.A potential customer is considered relevant if he/she prefers the car-sharing option in at least   ⋅ 100% of the scenarios, and irrelevant if not.Only the relevant customers are considered in the search.As an example, suppose   = 0.7 and there are 25 scenarios (which are the values we use in our tests).In this case, only the customers that have carsharing as their preferred mode of transportation in at least 0.7 ⋅ 25 = 17.5 (i.e., 18) of the scenarios will be included.

ALNS search space
To improve the performance of the ALNS, the destroy and repair operators are only changing the prices of zone pairs that are found relevant.A zone pair is considered relevant if it fulfills three conditions: (1) There is at least one car present in the zone pair's origin zone.This might be due to the car being there in the first place or that an employee has relocated a car to this zone.(2) There is at least one relevant customer in the zone pair's origin zone.This has the effect of finding a zone where there is demand for cars.(3) Among the relevant customers, at least one has the zone pair's destination zone as its desired destination.By only evaluating the relevant zone pairs, we avoid evaluating changes in zone pairs that do not have an impact on the objective value.It should be noted that this concept of relevant zone pairs is considered also when the initial solution is constructed.

Local search space
The local search for pricing solutions uses the same search space as defined for the ALNS by only investigating what we define as relevant U. Eilertsen et al.

Table 3
Comparison of the ALNS and Gurobi.Three versions of each test instance type are generated.Each test instance is solved ten times with the ALNS for a maximum of 600 s each time.Gurobi is likewise used to solve the full stochastic program with a 600 s time limit.Average objective values, runtimes and gaps are reported.The gap is based on the distance to the best upper bound found by Gurobi.
Test instance type Gurobi (600 s) ALNS Heuristic (600 s) Objective value Gap (%) Time (s) Objective value Gap (%) Time (s)  zone pairs.The local search for relocations has extended this definition to include car-moves that are considered relevant when using the add move LSO.For each zone, we calculate a cars-to-customers ratio.This ratio is calculated by including only relevant customers in the zone, and all cars originating or currently being in the zone as a consequence of relocation.If a given zone has a cars-to-customers ratio exceeding  −− , all car-moves with the given zone as destination zone are excluded from the relevant car-moves.This reduction in search space makes the algorithm only consider moving cars to areas which do not already have a high density of cars compared to customers.
To restrict the search space even further, the car-moves are filtered based on the time it takes to perform them.If the relocation time of a car-move exceeds  − ⋅  1 the car-move is considered irrelevant.The only exception is if the car to be relocated is in need of charging.This is done to eliminate very time-consuming car-moves which are unlikely to be part of the optimal solution.
A final effort to reduce runtime is defined through the LSOs themselves.Each LSO has a time limit of   seconds, avoiding a best improving search from being a bottleneck in larger instances of the problem.Furthermore, the local search has an overall time limit of   seconds.To avoid repeatedly investigating the same part of the search space for   seconds, the search space is randomly ordered at the beginning of each local search.

Computational study
This section presents the computational study.The solution algorithm was implemented in Python 3.9.6 while we used Gurobi 9.5.0 as the solver of the two-stage stochastic program.In the following, Section 5.1 describes the generation of the test instances, before we test the performance of the proposed heuristic in Section 5.2.Finally, we test the effect of including pricing decisions in Section 5.3.

Data and test instances
We generate a number of test instances based on data from Vybil, a CSO operating in Oslo, Norway.Particularly, we divide the operating area into 113 zones of size 800 × 800 or 400 × 400 meters as shown in Fig. 2. Each test instance is denoted by a code X-Y-Z, where X is the number of zones, Y is the number of cars, and Z is the number of employees.Table 2 summarizes the instances we generate and the respective number of zones, cars, employees, customers, and scenarios.The test instance types are divided into categories based on their sizes.

Table 6
The number of customers served (Requests Satisfied) and the average profit they generate (Profit per Request) using uniform and adaptable pricing strategies.The results are average values from running the ALNS heuristic ten times on three versions of each test instance type, with a time limit of 600 s per run.

Instance type
Uniform For each type of test instance, three different random instances are generated.
The number of charging zones is dependent on the number of zones in the test instance.As Vybil offers 35 parking lots, out of which nine are equipped with charging stations,1 we apply a ratio of charging zones per zone of 25%.We assume that each charging station has a capacity of three cars.Furthermore, the number of cars used by Vybil in need of charging is typically between 10% and 15% of their fleet.Thus, in what follows we assume that 15% of the cars require charging by the end of the target period.The size of the set of customers, ||, is arbitrarily set to ten times the number of zones in the instance.We use Google Maps API Distance Matrix, 2 to generate travel times for the various transport means (   ) and relocation times (   ).For a given instance, the initial position of cars and employees and the origin and destination of the customers are randomly generated using the technique of Pantuso (2020Pantuso ( , 2022)), which assigns to each zone a probability depending on the distance from the center.The instances are generated in such a way that the zones closer to the center are more probable.
Employees are defined by their origin location and the earliest time at which they can start performing relocations.The start time is drawn from a weighted distribution ranging from 0 to 15 (minutes), where values closer to 0 are more likely to be drawn.A car is defined by its origin zone and whether or not it is in need of charging.Cars in need of charging are uniformly drawn among the set of all cars.The set of possible car-moves that are generated for a car ,   , includes car-moves to all zones to which car  can be relocated.If a car  requires charging,  ∈   , only car-moves to charging zones are allowed.We assume we plan one hour in advance of the target period, thus we set  1 = 60 minutes, and we assume that each employee can perform at most || = 5 car moves during the 60 minutes.The cost of relocation activities is set to NOK (Norwegian Kroner) 0.43 per minute, based on the typical energy consumption of the electric cars used and Norwegian electricity prices.
We assume that the city offers public transportation (PT) and bicycle (B) as alternatives to car-sharing, that is  = {,   , }.We use choice model ( 5), introduced by Modesti and Sciomachen (1998) and used, e.g., by Hansen and Pantuso (2018), Pantuso (2020Pantuso ( , 2022) ) as a proxy for the behavioral model of the customers.It must be noted, however, that since the model is not validated by data, it does not allow us to draw sensible conclusions related to how people react to prices and incentives.Its purpose is solely that of testing the model and the method introduced.(5) The model expresses the (dis)utility of customer  traveling between their origin and destination, say  and , with a given transport mean , as a function of price   , walking time     required e.g., to commute or to reach transit stations, waiting time     , and travel time    .Function   () ∶  → {0, 1} is the indicator function   () = 1 if  ∈ {}, 0 otherwise.The  parameters reflect the sensitivity of the customer with respect to the different attributes and their values are provided Table 11 in Appendix A. Particularly, we assume all customers have the same sensitivity to all parameters except price.To model different price sensitivities we set two different values of    , say high and low (also provided in Table 11), and assign each customer a price sensitivity level with equal probability.We assume the ξ random variables are independent and follow a Gumbel distribution, thus obtaining a Logit choice model.Particularly, for the Gumbel distribution we use the standard deviation of the deterministic part of the customers utility (  ) across all  and .We use 25 scenarios given by iid samples from the underlying Gumbel distribution.
Finally, we set a NOK 6 per-minute fee for car-sharing and we define five different pick-up/drop-off fees, namely  = {−40, −20, 0, 20, 40} NOK.Observe that negative fees represent a bonus for the user.Bicycles are assumed to be free of charge and we assume a public transport ticket costs NOK 38 between all pairs of relevant zones, as is the case in Oslo.

Computational results
We performed a parameter tuning of the ALNS heuristic on a separate set of test instances, following the procedure by Ropke and Pisinger (2006).The parameters to tune, their initial values, their It should be noted that the performance of the ALNS was quite robust with respect to its parameter values.We also assessed the value of adaptivity in the ALNS, and it emerged that it yields an average objective value improvement of 2.4%, which is higher that what was found in the meta-analysis by Turkeš et al. (2021).We also tested the value of including the two local search algorithms on the pricing part of the problem (i.e., on top of the ALNS).This showed that including the local search gave an average improvement of 6.4%.
In the following we compare the performance of our heuristic with the commercial solver.We use a time limit of 600 seconds to test the algorithm on real-life-like settings.The average results over the three versions of each instance type are presented in Table 3.To account for the randomness of the algorithm, the objective values reported for the heuristic are averages over ten runs of each of the three versions of the instance types.The gaps are measured as the distance in the objective values in percentage to the best upper bounds found by the commercial solver, Gurobi.Note that these gaps are pessimistic as they represent maximum distances to the optimal solutions.
We observe from Table 3 that the two solution methods have achieved the same optimal solutions for the small instances, with the ALNS being faster.For the remaining instances, the ALNS is superior to Gurobi in all but the instances of type 15−12−2, where there is a minor difference in the gaps of 0.24%.The runtimes indicate that the ALNS heuristic finds the best-known solutions more efficiently than Gurobi.This supports the applicability of the ALNS heuristic as opposed to Gurobi in a real-life situation where decisions must be made frequently.The gaps to the upper bounds are somewhat large for the larger test instances, most likely due to poor upper bounds, but still smaller than those of the solutions found by Gurobi.
In Table 4 we compare the performance of Gurobi and the ALNS with a time limit of one hour (3600 s).It should be emphasized that a running time of one hour is significantly longer than what can be accepted in a real-life setting (as discussed above), which is considered to be around ten minutes.We can observe that in the long run Gurobi delivers better solutions than the ALNS on most instances.Nevertheless, Gurobi fails to deliver a solution on the largest instances, which shows that a heuristic is needed (especially since we in practice need solutions within at around ten minutes).

Effects from pricing decisions and simulation over a longer planning period
In this section, we report on the effect of including pricing decisions.We start by assessing the effect of adjustable prices.Particularly, we compare the results obtained when solving the problem with and without the possibility to set zone-specific pick-up and drop-off fees.In the latter case we simply set the fee to 0 on all origin-destination pair, so that the only price paid by the customers is the per minute fee, as is common in most car-sharing services, including our case company.
Our tests indicate that, on the instances presented in Table 2, the profit from including pricing decisions increases by 19.5% on average.
Pricing decisions have an impact also on the relocation decisions.The results in Table 5 illustrate that, when prices can adapt to the origin and destination zone, the number of relocations increases on average.Particularly, for instances larger than 10 − 9 − 2, the average number of relocations performed nearly triples when introducing pricing decisions, going from 2.49 to 6.17.These results can be explained with the fact that pricing decisions allow exploiting the potential customers' willingness to pay.In fact, in Table 6, showing the number of customers served and their average profits, it can be observed that the average profit per request satisfied is significantly higher when adapting prices.As a consequence, a higher number of zones become attractive destinations for operator-based relocations.On the contrary, keeping prices fixed on the entire business area exposes to the risk of underselling the service in certain zones.
In a real-life setting, the pricing and relocation problem would be solved periodically, e.g., every hour in preparation for the following hour.The long-term effects of adjusting prices during the day can therefore be properly assessed only in a simulation framework.Hence, we developed a rolling horizon simulation framework, which attempts to replicate a real-life situation where the CSO makes frequent decisions concerning prices and operator-based relocations.
We periodically solve the SE-VRePP with our heuristic as follows.First, pricing and relocation decisions are made one hour ahead of the target period.Following, all operator-based relocations are performed during the first hour, thus before the beginning of the target period.After the relocations are performed, we enter the second stage (the target period) of the problem.A random scenario among all 25 possible scenarios is selected to be rolled out, and cars are allocated to customers.After this, we update the state of the system (i.e., for cars and employees) and move one hour ahead in time and do the same over again, until we have reached the end of the simulation period.Following this procedure, we simulate each test instance ten times for ten hours representing a work day from 7 a.m. to 5 p.m.The same procedure is adopted assuming no pricing decision are made, i.e., static pricing (only relocations).Table 7 summarizes the results of these simulations.Note that each line in the table represents the average values over three instances of the given instance type.
As shown in Table 7, we observe a significant improvement in objective values for all test instances when optimizing pricing decisions (adaptable prices) compared to having uniform prices.The average improvement over all test instances is 16.6%.An interesting aspect to consider is how the joint optimization of prices and relocations affects the need for employees to perform charging-moves.We notice that the numbers of customers satisfied do not significantly differ for the two pricing strategies, i.e., on average 120.7 customers satisfied with a uniform pricing strategy versus 118.2 with optimized prices.On the other hand, the average profit per request is significantly higher with optimized zone prices, i.e., 71.6 vs. 58.3NOK/request.However, we have to stress that the behavioral model utilized is only a proxy for a validated model.Therefore, we are not able to provide a more thorough assessment of customer's choices.
Finally, from Table 7 it also emerges that the added value of adaptable prices decreases with the size of the fleet.This signals that a sufficiently large fleet is able to cover enough demand to partially compensate a uniform pricing strategy.

Summary and concluding remarks
We have in this paper studied the Stochastic Electric Vehicle Relocation and Pricing Problem (SE-VRePP), which integrates operator-based relocation decisions and pricing decisions in car-sharing systems when faced with uncertain future demand/customer behavior.We modeled the SE-VRePP as a two-stage stochastic programming model.Since this model could only be solved by a commercial solver for very small problem instances, we proposed a new heuristic solution algorithm, which uses an Adaptive Large Neighborhood Search (ALNS) heuristic combined with local search for the pricing part of the problem and another local search for the operator-based relocations.
We performed a computational study on test instances generated using realistic data from our case company, Vybil, which is a carsharing organization (CSO) in Oslo, Norway.The tests showed that our heuristic found the same optimal solutions as the commercial solver for small instances and significantly better solutions for the larger and more realistic ones.Furthermore, simulation results linked optimized prices to substantial profit increases.Nevertheless, these results were obtained with a non-validated model of customer behavior, therefore no general conclusions can be drawn in this sense.
The research presented in this paper leaves room for further improvements.Particularly, in practice, customers choose not only based on pricing decisions but also based on the distance to the nearest shared car.This distance, in turn, depends on or can be influenced by relocation decisions.Extensions of the model presented could be developed to model more precisely the interaction between decisions and customers preferences.Furthermore, pricing and relocation decisions are in practice made periodically during the day as a result of the updated status of the system.A multistage extension of the model presented would serve better to capture this dynamics.Finally, our ALNS algorithm is relatively complex as it includes many components.It probably also has room for other improvements in order to provide even better solutions.Hence, there is a value in simplifying and improving our heuristic, something we leave for future research.

Appendix A. Summary of notation
See Tables 8-10.

Fig. 1 .
Fig. 1.Flowchart presenting the different elements of the heuristic.

Fig. 2 .
Fig. 2. The operating area set to Oslo, divided into a grid of 113 zones of sizes 800 × 800 m or 400 × 400 m, defined by the green lines.

Table 1
Rewards for destroy and repair operators.>   (  ) The new solution is a new global best.    ( ′ ) >   (  ) The new solution is a new local best, but not a new global best.    ( ′ ) <   (  ), Accepted The new solution is non-improving, but is accepted.

Table 4
Comparison of the ALNS heuristic and the commercial solver Gurobi.Three versions of each test instance type are generated.Each test instance is run ten times with the ALNS heuristic for a maximum of 3600 s.The results from Gurobi after a maximum of 3600 s are registered as a benchmark.Average objective values, runtimes and gaps are reported.The gap is based on the distance to the best upper bound found by Gurobi.
(-)in Objective Value indicates no feasible solution found.(-) in Gap (%) indicates no feasible upper bound found.Averages are found replacing (-) with 0.

Table 5
Number of operator-based relocations performed with and without adaptable prices.The results are average values from running the ALNS heuristic ten times on three versions of each test instance type, with a time limit of 600 s per run.

Table 7
Evaluation of how pricing decisions affect the overall profit during a work day.The accumulated objective values over the ten hours in the work day are displayed in the columns Objective Value.The column ''Increase'' shows the average increase in profit from having adaptable prices.The average runtimes the ALNS heuristic spent finding the best known solution for each hour are displayed in the columns Time (s).

Table 8
Sets used in the model.Set of requests for a given realization of   in scenario    (  ) Set of requests with destination in a charging zone for a given realization of   in scenario     (  ) Set of requests with destination in charging zone  for a given realization of   in scenario    (  ) Set of requests that has precedence over request  in scenario    (  ) Set of requests going from zone  to  in scenario    Set of combined pick-up and drop-off fee levels that are less than or equal to the highest fee accepted for request

Table 9
Parameters used in the model.  1 if fee level  is used between zones  and , 0 otherwise.  1 if employee  performs car-move  as her task number , 0 otherwise.  1 if vehicle  satisfies request  with the fee level  in scenario , 0 otherwise.
1 if vehicle  is available to customers in zone  at the beginning of the second stage, at time  1 , 0 otherwise.tuning intervals and their final values are summarized in Appendix C.

Table 11
Predefined parameters and set sizes common to all test instances.