ThesisManuscript/6_conclusion.tex

\chapter*{Conclusion}
\addcontentsline{toc}{chapter}{Conclusion}
\chaptermark{Conclusion}
 
The objective of this thesis was to increase the utilization rate of a carsharing service by modifying its fleet distribution in a city during the night.
The operator, \emph{Free2Move}, wanted a methodology that could be used in any of its own services, i.e. a methodology that should not be dependent on the specificity of a particular service.
The operator can modify the placement of the vehicles thanks to specialized staff called \emph{jockeys} that are hired to relocate the cars during the night, to avoid the city's traffic during the day.
We proposed of a two-step methodology meeting this objective~\cite{martin_prediction_2021,martin_optimisation_2022}.

This methodology includes an \emph{Integer Linear Programming} model to be optimized such that decisions for the relocation of misplaced cars in the city could be automated.
It decides which is the best placement of cars for the next morning and how jockeys should move between each relocation so that they spent the least time not doing a relocation.
This optimization model relies on the prediction of the car utilization the next day depending on its location and other exogenous parameters.
Three approaches evaluate the methodology to show both its performance and its limitations.

\paragraph{Methodology Performance and Limitations.}
The first approach evaluated both the performance of the daily utility prediction by the regression models and evaluated the gains that could be expected by the \emph{Integer Linear Programming} (\emph{ILP}) optimization model.
The evaluation of the daily utility prediction model shown that in the case of \emph{Madrid} the models have an acceptable prediction error while in the case of \emph{Paris} and \emph{Washington} the lack of trip data hindered the models and led to a higher error.
The best regression models found during this experiments have then been used for the evaluation of the \emph{ILP} model.
The evaluation of the solutions found by the \emph{ILP} solver against the historical service utilization shown that the relocation model actually improves the service utilization in the three case studies.
The daily profit was higher for the three services when the solution of the \emph{ILP} model is used than in the historical case.

These case studies revealed a limitation on this methodology.
The prediction of the utility is dependent on the overall activity in the service, i.e. the prediction of the daily car utility is easier when the activity in the service is higher.
The difference of activity between \emph{Madrid} and \emph{Paris} is correlated with the difference between the error rate in the utility prediction.
This limitation prevents \textquote{small} services from using the methodology.

The second approach evaluated how the methodology would modify the utilization rate of the service on the long term.
It used a simulation model to emulate the behavior of a carsharing service's fleet.
Depending on the vehicle's location those vehicles would be more or less used by the customers, allowing to evaluate the usage of a relocation strategy.
Three experiments have been made with the simulation model.
Overall these experiments allowed to draw several conclusions on how the methodology would perform on the long term.
First the methodology can be used for services with a usage high enough to support the cost of relocations.
In the case of \emph{Paris} the relocations are often not profitable to make because of the low utilization of the service.
This shows that in the method, limiting the optimization to the trips made by jockeys between relocations misleads the whole relocation strategy.
In that case the \emph{ILP} solver returns a solution that includes cars that should be moved from the point of view of the solver.
But in reality the additional cost of relocating the car that is not included in the \emph{ILP} formulation would make the relocation unprofitable and unnecessary.
This highlighted the need to take into account the whole path of each jockey when minimizing the costs associated with the relocations.
Additionally, the experiments shown that customer-based relocation are always an effective alternative to operator-based relocations.
However this conclusion is due to the simulation being imperfect: the simulated car does not need maintenance nor refuel/recharge that make staff completely optional when it is not in reality.

The third approach evaluated a simplified version of the methodology, but directly in the real carsharing service of \emph{Madrid} with the help of \emph{Free2Move}.
The objective was to assess if a simplified methodology could be implemented and used in a production environment to automate the placement of fully recharged electric cars. 
This consisted in an \textquote{A/B Testing}, with February 2022 and April 2022 as periods A and March 2022 as period B.
The service worked as usual during the periods A and during the period B the \emph{Free2Move}'s team used the simplified methodology proposed in this manuscript.
The results of this A/B Testing shown a limited effect of the simplified methodology on the service.
A first limitation had been shown before the A/B Testing itself as the methodology had to be simplified: it did not support the recharging of electric vehicles.
The methodology did not include the recharge of electric vehicles because of the lack of information about the state of charge of electric vehicles in the trip dataset when the methodology was designed.
The A/B Testing also highlighted that the solutions' performance is dependent on the execution of the solution by the operational team.
Indeed, the staff might have preferences that should be taken into account by the \emph{ILP} model or it might return solutions that are feasible but not accepted by the staff, e.g. let enough room for jockeys to \textquote{improvise} if a car cannot be placed in an area because no parking lot is found.

% \paragraph{Approach Limitations.}
% Overall, the proposed methodology shown promising results during the experiments, but several limitations have been also exposed.
% First, the sparsity of the carsharing trips data, because of a low usage, highlighted the need to have sufficient data in order to train the utility prediction models.
% Indeed, in both \emph{Paris} and \emph{Washington} the high error rates when the utility has to be predicted is mostly due to the sparsity in the trip data as well as the high variability is carsharing usage in those cities.
% The variability in the demand is also due to \textquote{exceptional} events such as road closure, public transport strikes or large cultural events that influence the demand for carsharing.
% However the records of such data were not available for the training of the utility prediction model.
% Second, the \emph{Integer Linear Programming} optimization model of the two-step methodology only provides the places where cars should be removed or added as well as the trips jockeys needs to do between two relocations.
% However, it does not give the complete and optimal path a jockey has to take to both relocate cars and move between each relocation.
% In Chapter~\ref{ch:simulation}, the test of this methodology required an additional step to take the bits of jockey trips and assemble them, through a greedy algorithm, to create the path each jockey has to take in order to relocate the cars.
% The use of a greedy algorithm does not provide an assurance that all the paths are minimizing the time spent by all jockeys doing the whole relocation process.

\paragraph{Perspectives.}
The perspectives to improve the method falls into two categories: the utility prediction and the optimization model.
In the first category, the precision of the utility prediction could be enhanced by using additional data on external factors like \textquote{exceptional} events, e.g. road closure, public transport strikes, or large cultural events that influence the demand for carsharing.
Additionally, if the services were more used and the staff could relocate the cars during the day, the utility could be predicted on an hourly basis.
During the thesis, a tentative to predict the car usage on an hourly basis have been made for a service named \emph{Multicity} located in Berlin.
This approach modeled the city as a graph, where each cell is a node inside the graph and each trip is an arc between nodes.
By creating a graph for each hour of the dataset, the resulting ensemble of graphs is ordered to create a dynamic graph, i.e. a graph with nodes and/or arcs changing as time passes.
The objective was to model the usage as a dynamic graph to then predict the arcs of the future graph, i.e. the \emph{link prediction in dynamic graph} problem.
By predicting the arcs, the number of trips between each cell could be predicted on an hourly basis.
However the low usage of the service in \emph{Berlin} made sparse graphs whose arcs could not be predicted accurately.
Since the usage in \emph{Madrid} is higher, this approach could be explored.
Using the simulation with a higher count of vehicles could also artificially increase the number of trips and provide denser dynamic graphs to test this approach.

In the second category, multiple practical improvements for \emph{Free2Move} could be made if required by the operator.
The optimization model is flexible enough to allow the integration of new information or new constraints based on future needs.
For example, the model could introduce the charge of electric vehicles such that on top of relocating misplaced cars, the jockey could also recharge and optimally put back in service the recharged cars.
Additionally, the methodology could take into account heterogenous fleet, i.e. fleet with different types of vehicles.
Indeed, different types of vehicles can have a different usage pattern, e.g. sedans used for commute trips and utility vehicles that are used to move large furniture.
It could also be used by the optimization model so that types of cars can be separated and be subjected to different constraints, e.g. not putting more than 10 sedans and not more than 5 utility vehicles in a single cell.
For both the recharging and heterogenous fleet improvements made on the optimization model, this would increase the prediction of the utility since the usage of a vehicle is linked to the state of charge and type of vehicle.
Moreover, the optimization should avoid relocating cars only by taking into account half of the path made by the jockeys during the relocation of the fleet.
As seen in the experiments, this leads to unprofitable relocation trip being made.
Instead of optimizing the fleet placement only by taking into account half of the jockey path, the optimization should be done on both the locations where cars should be taken and dropped off and the paths each jockey travels to make the relocations.

% Under the hypothesis that corresponding data can be gathered for the training of the utility prediction model, two practical improvements to the methodology can be done in a short-term future.
% The lack of information about the state of charge for electric vehicles in the provided trip datasets has hindered the utility prediction models: this information is a determining factor in the customer usage as low battery is deterrent for customers.
% A first modification of the model would consist in putting the battery's state of charge of electric vehicles in the utility prediction models as a feature.
% Then, the \emph{Integer Linear Programming} optimization model could introduce the recharge of electric vehicles such that on top of relocating misplaced cars, the jockey could also recharge and optimally put back in service the recharged cars.
% Second, the methodology is not capable of taking into account several types of vehicles that can have a usage pattern different too, e.g. sedans used for commute trips and utility vehicles that are used to move large furniture.
% The introduction of different types of vehicles in the utility prediction model would increase its precision.
% It could also be used by the optimization model so that types of cars can be separated and be subjected to different constraints, e.g. not putting more than 10 sedans and not more than 5 utility vehicles in a single cell.

\begin{figure}[!b]
    \centering
        \makebox[\textwidth][c]{\includegraphics[width=0.70\textwidth]{figure/ch6_vrp.jpg}}
        \caption[VRP Example]{Instance of the \emph{Vehicle Routing Problem} for a logistic company: \emph{three trucks} have to deliver goods from \emph{a central depot} to \emph{all shops}. The sum of distance traveled by all trucks have to be minimized.}
        \label{fig:ch6_vrp}
\end{figure}

\paragraph{Vehicle Routing for the Car Relocations.}
For the optimization of both the car placement and the jockey route, techniques from the \emph{Vehicle Routing Problem} field can be used at least to minimize all the route traveled by the jockeys.
The \emph{Vehicle Routing Problem} (\emph{VRP}) is a generalization of the \emph{Traveling Salesman Problem} (\emph{TSP}).
In the \emph{TSP} a \emph{single} agent has to minimize its trip while visiting each point, but in the \emph{VRP} this problem is generalized to any number of agents such that the sum of the distances traveled by each agent is minimized while all the points must be visited by at least one agent.
An example of \emph{VRP} is shown in Figure~\ref{fig:ch6_vrp}, in this case a logistic company has to deliver goods to several shops in a city and has three trucks to do it.
Since all shops have to be served by the logistic company, it could seek to minimize the distance that all the trucks have to travel to minimize the fuel required for the deliveries.

In the case of carsharing services, the application of the \emph{VRP} to the relocation problem is not straightforward. 
In particular, if a jockey is an agent and a place to visit is either a location with a car to remove or a location with a car to place, each jockey has to respect an order to visit each location.
If the complete route of a jockey makes him visit one location where to pick a car and then two locations where a car is expected, then it means the jockey will be able to place only one car in the first location but not in the second.
The order of places visited by each jockey matters.
One solution would to consider the \emph{Pickup \& Delivery Problem} which is a particular case of \emph{VRP}: additional constraints are added such that when an agent visit a location this agent is constrained to visit another location directly after.
Those constraints could be created directly from the optimal relocations computed in the second step of the proposed methodology.
This would represent an optimized alternative to the greedy jockey route creation detailed in Chapter~\ref{ch:simulation}.

However this solution would not leverage the fact that it is not mandatory to relocate a car in a carsharing service if it is not profitable to do so.
One could seek to model a \emph{VRP} with the ability to optimize \emph{jointly} which cars should be removed from their locations, which unoccupied locations should receive a car and the complete route of all jockeys.

% or want to optimize the route of jockeys to relocate those cars. In the latter case, there also exist a more specialized field about the \textit{Vehicle Routng Problem}~\cite{goel_vehicle_2017}, which is about finding the shortest path for a vehicle that should pass through given locations.


\toignore{
Ccl:
Reprendre chapitre par chapitre (Résumé des épisodes précédent)
Il faut rester assez haut niveau pour la conclusion.
Puis faire une conclusion générale sur l'ensemble du travail.

Expliquer les limitation des approches qui sont étudiées.
Limitation net: system à modéliser est trop complexe (travaux sur route, eveM divers dans la ville à prendre en compte)
=> Données limités par le nombre de voiture dans la flotte, si pas assez de voiture ou usage low alors pas assez de stats (données trop parcimonieuses)
=> Devra pouvoir généraliser sur plusieurs villes, mais généraliser sur les ville sdemand d'avoir des donées très précises pour caractériser les villes.
Quel similarité du point de vue du carsharing ?
Eu la chance d'avoir 3x 1an de données d'autopartage, mais éventaille de situation fait que ces données ne sont pas suffisantes pour prédire les situations compliquées.
On devrait faire une prédiction à grain un peu plus fin ? Prendre en compte des données plus riches (type google avec les déplacements journaliers).

- Parler de granularité
- Modélisation

Parler de ville connectées pour avoir plus de données ? (Quel impact environmental ?)

Futur work:
Faire un lien avec les trucs qui n'ont pas fonctionné ? (Dynamic graph ?)
Etant donné un placement jockey, dans quel ordre les jockeys devraient faire les déplacements ?
Puis faire un lien avec vehicle routing probleme.
}