\chapter{Background and State-of-the-Art} \label{ch:background} In the scientific literature, articles on the subject of carsharing have been published, with objectives ranging from determining the reasons why customers use the service, to determining what the economical or environmental impacts are. Since the aim of the current thesis is to optimize the usage of any free-floating carsharing service, the relevant state-of-the-art has been divided into four categories. The first category of articles presented address how it is possible to model a city and a carsharing service occupying it, depending on whether this service is station-based or free-floating. Moreover an additional focus is made on the approaches trying to model customer's usage patterns. The second category is dedicated to works dealing with the improvement of existing carsharing services. Before presenting any article specific to carsharing, a short explanation is made about integer linear programming that is used in those works, i.e. one of the techniques from the mathematical optimization field. Then methods about the improvement of carsharing services are presented. First, the methods leaning towards a user-based approach are presented as those leverage customer incentives as a way to improve the service. Then, the operator-based relocation methods are detailed, in this case the operator can act directly on the service to improve the fleet position. In the third category is presented the state-of-the-art for both the urban mobility simulation and the carsharing simulation, with the aim of evaluating the relevance of a given methodology. Two approaches are presented: one based on events to change the simulator internal state and another one based on agents acting within the simulator according to their needs. Finally, in the last part of this chapter the state-of-the art of the models used to do regression is presented, since they are used in Chapter~\ref{ch:method} to predict the utilization of cars in the service. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % SECTION - SECTION - SECTION - SECTION - SECTION - SECTION - SECTION - SECTION - SECTION - SECTION - SECTION % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % \toignore{ % \section{Urban Mobility} % In order to understand the scientific literature about urban mobility and its intersection with shared vehicles-based mobility, this section is split into two subsections. In Section~\ref{sec:bg_vehicle_sharing_concept}, three close but different service types of shared-vehicle are presented. After all, carsharing is not the only service proposing users to rent vehicles by the minute and exploring the works in the surrounding field has interest \info{Elisa: il faut que tu fasses attention à rester informatif et pas "littéraire". Si tu mélanges des points de vue personnels avec des infos scientifiques, tu vas doubler le volume de ton manuscrit}. And then in Section~\ref{sec:bg_city_modeling}, the modeling of urban trips done by people in a city is presented depending on the type of vehicle sharing service studied. Indeed, being able to correctly model the city and its trips allows to use other abstract methodologies like graphs or regression models. % \info{A mon avis, tes chapeaux de section sont trop longs et ce que tu dis est répété apres...} % \subsection{Vehicle Sharing Concept}\label{sec:bg_vehicle_sharing_concept} % When moving from one point to another within a metropolis area, the most common transportation means are: private car or bike, public transportation such as buses or subways, taxis or even foot. Between the mass-transport systems represented by the public transportation services and private owned vehicles, several types of vehicle sharing services exist. From shared bikes to autonomous mobility on demand through carsharing, every system has its constraints and its dedicated methodologies. %to either study them or improve them. % \subsubsection{Bikesharing}\label{sec:bg_bikesharing} % A bikesharing service is a transportation mean with bikes freely available against monetary payment, usually in predefined stations. The users ride the rented bike and once their trip is finished, they lock the bike on a dock in order to let other users have the possibility to rent the shared bike. Since numerous bikesharing services uses predefined stations within the city, the issue of demand and supply of bikes in each predefined station arise. Indeed if a person comes to rent a bike but find that none is available or if a person desires to end her bike trip but find no dock where to secure the rented bike, then the \emph{customer demand} is not met. % This issue is often associated with the re-balancing needed to be done by the service operator to keep each bike station with enough bikes to serve customers and enough free docks to let other customers park their rented bikes. %Thus the focus of several works is made on this rebalancing issue. % For example, the authors of~\cite{chen_dynamic_2016} propose to regroup stations of the service into clusters of same-behaving \info{Elisa: tu es sûr de ton mot là?} stations. Then, the authors propose to predict the probability of an over-demand for bikes or under-supply of free docks \info{Elisa:c'est la même chose ? Peut-etre ne pas dire les deux ?}. This study provides the knowledge that the bike demand is influenced by time and weather features, including the temperature, as well as other less frequent occurrences of traffic or social events. This is further acknowledged by the authors of~\cite{tomaras_modeling_2018} who propose to consider the large city events that affect the distribution of bikes in the stations around the city. This exogenous information will also be important in our carsharing problem. Finally, the authors of~\cite{hulot_towards_2018} anticipate the over-demand/under-supply by training regression methods to predict the number of trips to be demanded in every station as well as the number of bikes to be returned. This allows them to detect whether a station needs bikes to be added or removed by the staff. \info{Elisa: j'ai fait des petites coupes parfois pour simplifier tes phrases, je te laisse regarder dans l'historique...} % By early detecting possible over-demand for bikes, the previously presented works suggest a first relocation strategy. However, knowledge about how many bikes should precisely be taken from which station to be delivered to stations in need of bikes could further improve the strategy. The authors of~\cite{raviv_static_2013} present a method to directly create the route for two vehicle services to re-balance the bikes. They consider that the bike relocation is done exclusively when the service is the least busy, e.g., during the night. In the same way, the authors of~\cite{ghosh_dynamic_2017} and~\cite{ghosh_improving_2019} adopt an optimization formulation in order to address the imbalance number of bikes in stations and create the routes for the staff vehicles. Compared to~\cite{raviv_static_2013} the authors add the support for relocation of bikes during the normal activity hours by globally anticipating the demand, with a probabilistic model of the demand. % Even with the addition of a finer relocation process, e.g. by adding the areas from which bikes should be taken to which area they should be dropped off, the methodologies cannot be directly applied to the free-floating carsharing problem faced in this thesis. Indeed the assumption about the relocation capacity is different between bikesharing and carsharing, in the former case a truck can relocate dozens of bikes all at once while in the latter case one staff member needs to go from cars to relocate to other cars to relocate, with often the need for an additional sweeper car to take care of staff members. % \info{Elisa: sinon c'est pas mal. Peut-etre que si tu reparles de ces refs plus tard tu remplacer cette section par une version plus courte et moins structurée dans l'intro...} % \subsubsection{Autonomous Vehicles} % \towrite{Those papers should be used:\cite{vosooghi_critical_2017,horl_dynamic_2019,volz_relocation_2022,marczuk_autonomous_2015}} % We focus on a subpart of the autonomous vehicles research filed dedicated to the study of automated mobility-on-demand, abbreviated as AMoD. This kind of service, yet hypothetical, can be viewed as carsharing services with some tweaks. In a standard carsharing service the vehicles are not autonomous and cannot relocated themselves if needed, and in addition users of the service have to drive the car themselves too. However the global usage and its costs remains within the same boundaries when compared against taxis and busses whether the cars are operated by humans or autonomously. Indeed as shown by~\cite{bosch_cost_2017}, the cost of autonomous shared vehicles is lower than the cost of non-autonomous taxis while being more expensive than autonomous buses in a urban setting. % The research in autonomous vehicles is vast, but a focus can be made on a subset of this field revolving around the study of automated mobility-on-demand, abbreviated as AMoD. As described in~\cite{bosch_cost_2017,horl_fleet_2019,horl_dynamic_2019}, this kind of service would offer to each customer a taxi-like service but without the need to have a human taxi driver, who has a big influence on the final price paid by the customer. The aim would be to propose an alternative to the private owned vehicle for (sub)urban trips, with the expected effects of reducing the global cost a person needs to pay of their transports and of reducing the space occupied due to park unused vehicles. % In the paper~\cite{horl_fleet_2019} the work presented by its authors revolves around the automated mobility-on-demand % } \section{Carsharing Service Modeling}\label{sec:bg_city_modeling} Optimizing the usage of a carsharing service requires to first model the service, both its spatial dimension and its usage by the customers. In this section both are presented, with a first insight on the frequent models encountered in the carsharing literature to spatially represent the service and its vehicles. Then the focus is made on several studies about customer usage patterns and about the external factors influencing them. \subsection{City Modeling} Each vehicle sharing service generates data about customer usage. On top of data required on a practical point of view, such as driver licenses, payment information or personal information, the service will register the trips made by the users. This trip data often consists in having at least the spatiotemporal point of the trip's start and the spatiotemporal point of the trip's end. Those points are made of a GPS coordinate and a timestamp. In the current section, the focus will be made on how to make an abstraction of the GPS coordinates to model the trips. The aim is to be able to use additional methods on top of this model for either the prediction of car usage or their relocation. It should be noted that the choice of the model to use is not trivial, mainly because the algorithms used to improve the carsharing service are going to be constrained by the chosen model. \paragraph{Graphs.} Station-based vehicles sharing services can be straightforward to model compared to their free-floating counterparts. Indeed, the backbone of the service is the set of stations where all the vehicles are allowed to park. Thus, it is possible to directly use the set of stations instead of the city as the basis of the model. In most articles relying on stations, such as~\cite{zimmermann_profiling_2015}, they are modeled as a graph : the stations are represented by a node in the graph and each possible trip between the stations are modeled by the links between the nodes. An application of this model is presented in the Figure~\ref{fig:ch1_singapore}, where the article~\cite{xu_new_2007} study the carsharing service located in Singapore as an example. The stations represented in Figure~\ref{fig:ch1_singapore_station} are modeled with a graph shown in Figure~\ref{fig:ch1_singapore_graph}. Even if in this case it is a bike-sharing service, the modeling principle is the same for carsharing services. \begin{figure}[!ht] \centering \begin{subfigure}[t]{0.44\linewidth} \includegraphics[width=1\textwidth]{figure/ch1_singapore.jpeg} \caption{carsharing service's stations location in Singapore from~\cite{xu_new_2007}.} \label{fig:ch1_singapore_station} \end{subfigure} % \begin{subfigure}[t]{0.54\linewidth} \includegraphics[width=1\textwidth]{figure/ch1_singapore_graph.jpg} \caption{Representation of the possible graph corresponding to the stations in Singapore, with only some trips represented.} \label{fig:ch1_singapore_graph} \end{subfigure} \caption{Example of model to represent a station-based carsharing service located in Singapore. On the left is the map of Singapore with the location of each station. On the right is graph to model the stations of the service with a subset of possible trips (arcs) from one station (vertex) to another.} \label{fig:ch1_singapore} \end{figure} However it is not possible to directly use graphs as a model for free-floating carsharing services. Indeed since the cars are able to park in any parking lot, while it would be theoretically possible to assign a node for each parking lot in the city, this is impracticable. A trip between each parking lot would be modeled as a link between the corresponding nodes. Many issues arise with this kind of graph, first it would be necessary to know the exact number of parking lots in the city and their location. Then, because the number of parking lot in a city is huge and fewer trips are made in comparison, this would lead to a large but sparse graph, i.e a high number of nodes but few arcs overall. Finally no abstraction would be done at all, two parking lot side by side would be considered as two separate nodes in the model even if they are in reality equivalent because of their proximity. \paragraph{Districts.} Since the use of graphs is not directly possible for free-floating carsharing services, another model is needed to represent the city and its service. It is possible to divide the city where the service is implemented into administrative districts. For example a service in Paris could use the \textquote{arrondissement}, such as shown in Figure~\ref{fig:ch1_paris_arrondissement}. The articles~\cite{febbraro_one_2012, schmoller_empirical_2015} are an example of how the cities were divided in districts in order to create a model of the area where a free-floating carsharing service is operating. The aim is to entirely cover the area with districts, without overlapping them. Then, for example it would be possible to take all the districts and all the trips between them and to create a graph to represent the carsharing service. In this model, a district would be represented with a node and a trip between two districts would be a link between the corresponding two nodes. This type of model helps to understand and visualize how the city was divided since it is usually based on real districts. However, this type of division does not guarantee a pertinent representation of the service usage. First because larger districts could hide finer hot spots of demands or trips made, preventing the usage of finer relocation strategies. Second because it would not represent correctly the maximum distance a user is capable of traveling before reaching a car to rent it. Indeed in the study of~\cite{seign_prescriptions_2013}, a user is willing to walk up to 500 meters to rent a car from a carsharing service and if none is available within this distance, then they might simply not rent a car at all. Thus in order to satisfy the users, the operator of a carsharing service will need to add the management of the distribution of the cars inside the districts, which can add more steps in the methodological approach. \begin{figure}[!ht] \centering \includegraphics[width=0.8\textwidth]{figure/ch1_paris_arrondissement.jpeg} \caption[Paris arrondissements]{Paris \textquote{arrondissements} can be used to model the surface serviced by a free-floating carsharing operator (Credits: ThePromenader).} \label{fig:ch1_paris_arrondissement} \end{figure} \paragraph{Grids.} Another possible means to model the trips of a vehicle sharing service is to divide the city into small areas with regular shapes. The objective is to make a grid where each cell represents the maximum distance a user wants to travel before reaching a car. This technique is used by the authors of~\cite{weikl_relocation_2012} as a first step for their objective of introducing a two-step algorithm to have optimal positions of the car fleet and a relocation strategy. In order to represent the maximum distance the users are willing to travel, a circle would be the best shape to use. However it is not possible to have a grid made of circles : this would either introduce overlap between circles or introduce blank areas between other circles. To pave the city with shapes regular enough to create a grid while staying as close to the shape of a circle, it is then possible to use hexagons. Indeed with hexagons it is possible to make grids and keep a good representation of the user's willingness to walk to a car. While an obvious alternative to hexagon would be squares, their utilization to make grids hinder the representativeness of the cell's neighbors as concluded by the authors of~\cite{schmoller_empirical_2015}. However, using a grid standardizes the city districts and erases the differences a further analysis could need like district information. For example, it could be interesting to know if most of the trips are done between a residential district and a district with many offices. With cells it would add an overhead to mark each created cells as belonging to a certain type of district. Furthermore, one of the main issues with the usage of a grid is to determine which radius to use for the hexagon. With smaller the cells, the representation of the demand is finer but this implies to create more cells to cover the area serviced by the operator. This makes the scaling of additional methods for the relocation difficult for a high number of cells. It also might increase the probability of splitting a hot spot of departure or arrival of trips between two hexagons. This \textquote{border effect} in which the demand from the same source is split between several cells might reduce the accuracy of the representation in the grid of this source of demand within the city. \paragraph{Artificial districts with grids.} A third possibility to divide the city resides in the combination of both previous approaches. The article~\cite{weikl_practice_2015} use this approach and first divides the city into artificial districts and then divides each artificial districts into cells. But, contrary to administrative districts as presented before, the authors of~\cite{weikl_practice_2015} chooses to create districts out of the data, by creating virtual carsharing stations. They are created by finding where they should be placed to cover the city and the utilization of the carsharing service. Hence, each artificial district should act as the area of influence of this virtual carsharing station, such that every part of the service area is assigned to the closest virtual station and thus included in the artificial district. This creates a homogeneous and uniform district cover of the city. The Figure~\ref{fig:ch1_cells_district} shows this technique applied to Munich, where there are more districts in the city center than in the suburbs because of the density of the carsharing demand. \begin{figure}[!ht] \centering \includegraphics[width=0.8\textwidth]{figure/ch1_cells_district.jpeg} \caption[City modeling by \cite{weikl_practice_2015}]{Example from \cite{weikl_practice_2015} of Munich being divided in districts and then in cells. Some cells are not represented since they may consist only of a park or another area where no car can be picked or dropped.} \label{fig:ch1_cells_district} \end{figure} This approach allows to create a division which tries to reduce the length of relocation trips done by the operator since the property of each district is to reduce the imbalance of ongoing and outgoing vehicles. However the pertinence of creating districts with the sole basis of the imbalance between the number of cars to enter and to leave the district is questionable. Indeed if the idea is to reduce the relocation distance made, then this reduction could have been directly incorporated into the optimization problem proposed by the authors by adding a relocation cost in their objective function, by taking into account only the grid and not the district. Thus the created district would be unnecessary. \paragraph{Conclusion.} Among these three types of city modeling often used in carsharing improvement works, the first one can only be used if the service is a station-based one. The second and third propositions can be used in the context of the current thesis, i.e for a free-floating carsharing service, but the added value of creating districts in the case of the third proposition remains unclear. Thus the choice of modeling the cities for the current thesis is to use a hexagonal grid. \subsection{User Behavior Modeling} \label{sec:user_behavior} Not only should the serviced area be modeled, but the user's usage patterns and other external features have to be modeled too. Indeed, it makes possible to model carsharing services and their trips more accurately. Thus articles from the literature that studies the user's usage patterns and other external features are the focus of this part. \paragraph{Spatial Observations.} If the serviced area of a city is modeled with a grid of squares or hexagons, one of the main parameters of the grid is the size of each cell. It will impact the representation of how the cars are regrouped in the reality, for example a big cell might hide the fact that numerous cars are concentrated in the same spot and deprive the neighboring areas of cars for customers. Thus some works have been made to assess the maximum distance a carsharing user is willing to travel in order to take a vehicle. For example, the authors of~\cite{costain_synopsis_2012} have studied the users of the service named \textit{AutoShare}, a station-based carsharing service in Toronto. The authors found that increasing the number of stations, and thus the coverage of the service, was more beneficial than a plain addition of cars. They have estimated that 65\% of the trips were made by people living closer than 1 km from any station. Furthermore as stated before, the authors of~\cite{seign_prescriptions_2013} expects users to walk a maximum distance of 500m before reaching a car. Thus even if the exact distance a customer is willing to walk towards a car in order to take it is difficult to obtain, 500 meters is a reasonable distance to base models for a carsharing service. \paragraph{Usage Patterns.} Usage made of the service by the users is one of the key components to understand the users' behavior. In~\cite{becker_comparing_2017}, the authors surveyed the usage patterns of car-sharing members. Three types populations of the Swiss city Basel are studied: members of a free-floating carsharing service opened less than one year before the survey, members of an already well-established station-based carsharing service and people not member of any car-sharing service. With this survey, the authors discover that most of the trips made by station-based carsharing members were for either leisure or shopping or large goods transport such as furniture. However in this survey, free-floating carsharing members used the service less for leisure and more for commute trips or for airport transfers. Moreover in this survey the authors discovered that free-floating services were more spontaneously used than their station-based counterparts: a majority of members of station-based planned their trip at least a day in advance while free-floating members usually planned their trip less than one hour in advance. Finally, an additional difference between station-based carsharing users and free-floating carsharing users is noticed: if a car is not available for the trip the majority of the station-based group either postpone or cancel their trip while the majority of the free-floating group use public transport instead of the carsharing service. Overall, this study shows a large difference in usage patterns between station-based and free-floating members, arising the need to differentiate both types of carsharing when trying to model them. \paragraph{Exogenous Influences.} The usage of carsharing is also dependent on factors external to the service itself, such as traffic, weather conditions or city topology. As presented before, in~\cite{becker_modeling_2017} the authors note that users of station-based carsharing service rely more on public transportation than users of free-floating carsharing services. Indeed in their analysis, a higher concentration of public transport stations correlates with a higher usage of a station-based carsharing service for an area. However the same correlation is not present for free-floating carsharing services. Instead, the authors found that free-floating customers use this kind of service in order to make trips that would be difficult with only public transportation. Moreover, even if it is not clear whether weather can be a determining factor in the utilization rate of a free-floating carsharing service as stated by the authors of~\cite{schmoller_empirical_2015}, they investigated the role of sudden change of weather during the day and notably sudden rain. According to this work, the presence of precipitation in the early evening from 5 p.m. to 8 p.m. when there was no precipitation at all during the morning or early afternoon would have a small (6\%) but significant impact on the number of reservations compared to a day without any precipitation at all. Thus both papers show an impact of external factors such as stations of the public transport system and the weather, to a small extent, making the modeling of those features interesting for the modeling of user behavior. \paragraph{Temporal Analyses.} In order to temporally model carsharing data, it is necessary to know the users temporal habits, on a daily and weekly scale. The authors of~\cite{ampudia_electric_2020} conducted a study on both free-floating carsharing services \textit{Car2Go} and \textit{Emov} in Madrid. The results of this study show that the use case for this type of service is different depending on the day of the week. During the weekdays, from Monday to Friday included, one of the main usage is related to commuting to and from work. Three peaks are observed during these days, a first one at 8 a.m., a second one around 1 p.m. and a last one around 8 p.m. It is worth noting that the authors of~\cite{ampudia_electric_2020} indicate that the second peak, at 1 p.m., is observable only for the carsharing service in Madrid and not for other services in other cities. Finally, a different use is made of the service at weekends, during these days the usage is stable with small peaks of usage at around 1 p.m. and 8 p.m., leading to the conclusion that a more leisure-oriented usage is made of these carsharing services. For the services located in Munich and Berlin studied in~\cite{schmoller_empirical_2015}, the authors note that the days around Christmas see a decreased usage of the service and the New Year's Eve day has a significant drop in reservations too. Furthermore in this work, the authors observe a lower average utilization during the summer period, between June and September, and they assume members to travel more by bike or on foot to explain this lower usage. On a weekly basis, both Munich and Berlin services are more used on Fridays and Saturdays than the rest of the week. Finally, the authors check in detail the service usage during the day, depending on the day to be a weekday or a weekend. They observe that during the weekdays, there are two peaks of usage one the morning between 8 a.m. and 10 a.m. and one the evening between 5 p.m. and 8p.m. Then during the days of the weekend, the usage rate is constant throughout the day with a slight peak between 7 p.m. and 8 p.m. Both articles show that the need to take into account a temporal dimension on multiple scales is necessary. Indeed since the usage rate can be different because of holiday days, because of the day of the week or even during the day, several features need to be made in order to model the variations of carsharing usage. \begin{figure}[!ht] \centering \includegraphics[width=0.8\textwidth]{figure/ch1_communauto_area.jpg} \caption[Comunnauto Montreal Service]{This map from the study~\cite{wielinski_exploring_2019} shows that the \textit{Communauto} carsharing service is a combination of a station-based part and a free-floating part. Customers can use both depending on their usage, station-based cars being reserved for longer reservations and free-floating one for shorter trips. The colored areas on the map designate the areas serviced by the free-floating part of the service (\textit{FFcs}). Different colors denote the spatial extensions added as the service expended. The dots are stations of the other part of the service (\textit{SBcc}). Metro lines have been added by the authors since they are used in their data analysis.} \label{fig:ch1_communauto_area} \end{figure} \paragraph{Activity Analysis.} The utilization of a carsharing service is dependent of the customer usage consistency. The presence of regular users, i.e. people who often use the service, means that a non-negligible part of the demand can be estimated. Indeed the aim is to know whether carsharing trips can be modeled or not, i.e. the trips are not mainly random trips. If one service wants to answer this question, the study~\cite{wielinski_exploring_2019} helps to understand the habits of carsharing customers. This study has been done on the \textit{Communauto} carsharing service in Montreal, with trip and customer data from 2010 to 2018 knowing that the carsharing serviced area has evolved during this period has shown in Figure~\ref{fig:ch1_communauto_area}. The authors have segmented the customers into four categories according to the usage frequency of the customer. The four categories that have been created are: Low Frequence (LF), Medium Frequency (MF), High Frequency (HF) and Ultra Frequency (UF). The limit between each category is computed as the number of active day on a period of 90 days for each customer, with an active day being a day where the customer has made at least one trip. Then the limit between LF and MF has been fixed by the authors to 4 days of activity on 90 days, the limit between MF and HF as 10 days of activity and the limit between HF and UF as 26 days of activity. For example, the meaning of the Ultra Frequency group of customers is that each customer in this group uses the service around at least once per three days on average. This segmentation helps to differentiate the usage patterns between different types of customers. For example, the authors found that HF and UF categories are more likely to make chained trips, i.e. one trip after another with a time break between both trips, and more likely to make symmetric trips, i.e. chained trips with the start of the first trip corresponding to the end of the second trip. Furthermore the distribution of time difference between two consecutive symmetric trips shows a spike for all categories at around 1.5h between two trips that are explained as leisure trips by the authors. But the UF category has an additional spike in the distribution around 8.5h corresponding to time spent at work between two trips, as explained by the authors. This work in particular shows that the study of the customer regularity leads to confirm the possibility of modeling the customer demand since it is not only random trips. \paragraph{Conclusion.} On top of the spatial modeling of the carsharing service, the usage patterns of the customer has to be modeled too in order to grasp the information available in the customer trips. Thus external features influencing the usage of the service has to be taken into account such as the availability of the public transport system and the weather in the city. Moreover, additional temporal features are needed if the customer demand has to be predicted, such as the day of the week or the hour of the day. The several articles presented also show that station-based and free-floating carsharing services cannot be modeled identically as customer usage patterns are different. % \subsection{Trip Prediction} % \toadd{ % Ici il faut faire une passe sur l'état de l'art en ce qui concerne la prédiction de liens dans des graphes dynamiques. Il n'est pas nécessaire de rentrer trop dans le détail. Cependant il est important d'indiquer qu'on a essayé de faire de modéliser notre service avec un graph dynamique pour utiliser des méthodes de l'état de l'art. Bien que notre modèle de graph soit théoriquement possible, dans les faits cette modélisation n'était pas viable car une très grande partie du graph était juste constitué de vide et les méthode existantes pour la prédiction de lien sont principalement basées sur la topologie du graph ce qui n'est pas compatible avec notre problème en pratique. % } %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % SECTION - SECTION - SECTION - SECTION - SECTION - SECTION - SECTION - SECTION - SECTION - SECTION - SECTION % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \section{Shared-Vehicle Service Improvements} \label{sec:share_vehicle_service_improvements} Carsharing services can be improved, for example to increase its usage or make the system profitable for the operator, by numerous means such as offering specific discounts, extending the area serviced by the system, augmenting the fleet offer with different types of vehicles for different types of usages and so on. Most of the experimental settings to test those possibilities require to have a direct control on the service, to make the changes in the real service and observe them for reporting. That is why the focus of the thesis about the improvement of shared-vehicle services has been made on the strategies that can be evaluated from past recorded data without the need to intervene on the real service, like strategies about optimizing the cars' placement in the city. The main contribution of this thesis is based on the resolution of combinatorial problems, notably by finding the best distribution of cars in the city according to a criterion. Thus in this section, we first present the mathematical prerequisites needed to understand the formulations often used in the works about the optimal placement of vehicles in the city. Then in a second part will be explained several works from the literature that study how operators of vehicles-sharing serviced can induce changes on the behavior of their users. The aim is to encourage certain types of behaviors to make the vehicle distribution more balanced without the direct intervention of the operator's staff. Finally, other articles not intervening on the user's behavior but directly on the vehicle distribution through the usage of the operator's staff, with a focus on doing that effectively, are going to be presented. \subsection{Mathematical Optimization} Mathematical optimization is a formal approach used for the resolution of practical problems. For example, the \textit{Knapsack Problem} or the \textit{Traveling Salesman Problem} can be modeled using mathematical optimization. If those problems are small enough, they can be solved by specialized algorithms called \textit{solvers} such as \textit{Gurobi} or \textit{SCIP}\footnote{\textit{SCIP} is the abbreviation of the solver called \textit{Solving Constraint Integer Programming}.}. \paragraph{General Approach.} In the general approach, a model of mathematical optimization is made of three main parts: the set of decision variables, the set of constraints on the decision variables, the objective function. The objective of the model is to describe the solution that should be found and returned by the solver. First, the set of decision variables are the unknown variables which the values are needed for the resolution of the problem. In the general approach of the mathematical optimization, the value of each decision variables is real ($\in \mathbb{R}$). For example, if a company needs to make concrete (made of water, sand, cement, aggregates and admixtures), the decision variable would be the proportions of each ingredient to pour in the mix to make concrete, knowing that two different ingredients could be used for the same purpose, e.g. two different admixtures. Then a set of constraints in the model can be declared to restrain the domain of the values for each decision variable. Following the example, constraints could be added to create intervals of proportions for each ingredient to make sure that the concrete obtained can be safely used for the construction of buildings. Finally, the objective function is the function that should be either maximized or minimized in order to find the \textit{best} solution, i.e. the best values for each decision variable. For the same example, one possible objective function could be the minimization of the ingredient costs. To sum up with a mock-up problem, in the following example Equation~(\ref{eq:ch1_ga_4}) and Equation~(\ref{eq:ch1_ga_5}) are defining two decision variables $x$ and $y$ that should be strictly positive, i.e. zero is not a valid value for $x$ and $y$. The value of those decisions variables are constrained to a subset of values such that they respect the inequality defined by the constraints in Equation~(\ref{eq:ch1_ga_2}) and Equation~(\ref{eq:ch1_ga_3}). Finally Equation~(\ref{eq:ch1_ga_1}) is the objective function, stating that the value of $x$ and $y$ is searched in order to maximize the value of this function. In this example, the maximum value of the objective function would be $10.33$ with the values $x=3.93$ and $y=3.2$. As a practical representation of this example, the 2D space of solutions is shown in Figure~\ref{fig:ch1_ilp}. One can note that four areas are distinguishable. The first half-plane in blue is the space excluded by the domain definition of $x$ in Equation~(\ref{eq:ch1_ga_4}). The second half-plane in green is the space excluded by the domain definition of $y$ in Equation~(\ref{eq:ch1_ga_5}). Then the two additional Equation~(\ref{eq:ch1_ga_2}) and Equation~(\ref{eq:ch1_ga_3}) are respectively excluding the cyan and magenta half-plane. The resulting space of solutions is in the center of the figure and the blue point represents the value of $x$ and $y$ such that they maximize the objective function while staying within the bounds of each decision variable's domain of definition. \begin{align} \underset{x, y}{argmax} \quad & x + 2 y \label{eq:ch1_ga_1}\\ s.t. \quad & x + 5 y < 20 \label{eq:ch1_ga_2}\\ & 3 x + y < 15 \label{eq:ch1_ga_3}\\ & x \in \mathbb{R}^{+}_{*} \label{eq:ch1_ga_4}\\ & y \in \mathbb{R}^{+}_{*} \label{eq:ch1_ga_5} \end{align} \begin{figure}[!ht] \centering \includegraphics[width=0.8\textwidth]{figure/ch1_ilp.jpg} \caption[ILP Example]{Graphical representation in 2D of the optimization model stated by Equations~(\ref{eq:ch1_ga_1}) to~(\ref{eq:ch1_ga_5}). Each colored half-plane represents a part of the 2D space with invalid tuples $(x, y)$. The blue point is the optimal solution if $x$ and $y$ are in $\mathbb{R}$. The gray and red points are the set of point representing possible solutions if $x$ and $y$ are restricted to be integers, with the red point being the optimal solution in this case.} \label{fig:ch1_ilp} \end{figure} The previous example was a mathematical optimization formulation with a unique best solution. However if the formulation were to be ill-defined, the problem could be either unbounded or over-constrained and no best solution could be found. In the former case, the maximization of the value of a decision variable without any upper bound is not possible since the value of the unbounded variable would tend towards $+\infty$ which is not a valid value. And in the latter case, one model could have a decision variable with no value satisfying all constraints of the formulation. Furthermore, it should be noted that minimizing a function is the same as maximizing the opposite function, like shown in Equation~(\ref{eq:ch1_equivalence}), without the need to change other parameters of the mathematical model. \begin{equation} \label{eq:ch1_equivalence} \underset{x \in \mathbb{R}}{\mathit{min}} \;\; f(x) \quad = \quad \underset{x \in \mathbb{R}}{\mathit{max}} \;\; -\!f(x) \end{equation} \paragraph{Linear Programming.} It can be noted that the solution space drawn in Figure~(\ref{fig:ch1_ilp}) is convex. Indeed this example is a \textit{Linear Programming} (LP) formulation, a subtype of \textit{Mathematical optimization} formulations. Like in mathematical optimization, the aim is still to either minimize or maximize an objective function while choosing the values of decision variables. However unlike in the general setting of mathematical optimization, LP disallows the usage of nonlinear constraints and nonlinear objective function. Indeed, all constraints and the objective function should be a linear combination of the decisions variables. \textit{Linear Programming} models have a major advantage since they can be reduced to convex optimization problems~\cite{boyd_convex_2004} with a solution that can be found with polynomial-time algorithms~\cite{nesterov_interior_1994}. Thus, they can be used for practical problems unlike most formulations for NP-Hard problems in the more general mathematical optimization field~\cite{murty_complete_1987}. \paragraph{Decision Variable Types.} Some problems require the decision variables to be inside a different set than $\mathbb{R}$. In the case of the \textit{Knapsack Problem}, one could want to restrict each object to be put as a whole without being split; indeed putting half a computer would make no sense. Subtypes of mathematical optimization are thus defined such as the \textit{Integer Programming} which all decision variables are constrained to be inside $\mathbb{N}$, the \textit{Mixed-Integer Programming} which has some decision variables being integers and other being real and the \textit{Binary Integer Programming} restricting all decision variable to be either zero or one. If the previous example from Equations~(\ref{eq:ch1_ga_1}) to~(\ref{eq:ch1_ga_5}) is used, it can be cast into a \textit{Integer Linear Programming} model by replacing $\mathbb{R}^{+}_{*}$ as $\mathbb{N}$ in Equations~(\ref{eq:ch1_ga_4}) and~(\ref{eq:ch1_ga_5}) and keeping the linear constraints and function objective. In Figure~\ref{fig:ch1_ilp} the half-plane is kept as is since the constraints have not changed. However instead of having all the 2D space being of set of possible solutions, only the points in gray and the best solution in red is the set of possible solutions. Thus the maximum value of the objective function is now $9$ with $x=3$ and $y=3$. \paragraph{Conclusion.} The mathematical optimization and especially the variant called \textit{Integer Linear Programming} are tools that can be used to search for an optimal solution according to an objective function. In the case of carsharing, an operator could use this approach if the operator wants to find the best distribution of cars inside a city depending on a given criterion. \subsection{User-Based Relocations} Trips made by the customers move the vehicles around the city and change the distribution of the fleet in the city over time. However the global utilization of the cars by customers is imbalanced: for example commuting customers might take the car only for their morning trip or for their evening trip and thus drop the car in an area where the car will be left unused. The consequence is that the fleet distribution in the city becomes imbalanced as well. In the scientific literature, many works seek to influence the users of the service in order to reduce the imbalance of the fleet. This type of relocation approach is called \textit{user-based relocations}. For example, services could either set different prices depending on the start and/or end point of the trip or give price cuts for cars that have been unused for too long. In the article~\cite{febbraro_one_2012}, the authors design a user-based relocation approach by first modeling a one-way carsharing service with a Discrete Event-based Simulation and then by creating an Integer Linear Programming model to take into account the relocation process. In this work, the authors decided to only act on the end location of a customer trip, i.e., they make the user change the station where to end his trip by offering to drop off the car at another close station right after finishing the trip. The practical study is made to simulate a one-way carsharing service in the city center of Turin for thirty days and with each day split into three periods to estimate the demand for such a service. Since the probability that a customer will accept a different end location of his trip is a parameter of the simulation, the authors have studied different values of this parameter with different fleet size to observe the impact of those two parameters on the number of trip served by the service. The authors are capable of demonstrating that the rate of reservations refused by the service is lowered by raising the relocation acceptance and the fleet size. This allows them to approximate which fleet size would roughly optimize the rate of accepted reservations against the cost to run the service. However this methodology has a limitation for its applicability to a real carsharing service. Indeed the probability that a customer is willing to accept to modify the location of the end of his trip is directly made by the authors and not linked to any study on how much it would actually cost to have the given probability of acceptance. The article~\cite{brendel_decision_2017} proposes a methodology to design pricing areas to involve the user in the relocation process through incentives. The aim is to counterweight the natural disequilibrium of the system ; in normal carsharing sharing services, the cars can be freely picked in areas with a high demand and dropped within an area with a low demand without repercussion for the customer. The main idea is that the customer should be rewarded by the operator if he chooses to take or park the car in an area rather than another. Thus the authors choose to implement different pricing areas within the studied city, by studying the demand in the city and creating three areas with different pricing: a low-demand area, a medium-demand area and a high-demand area. Customers taking cars in low-demand areas are given a high reward while customers putting cars in low-demand areas face a high penalty. Like for low-demand areas, in the case of medium areas a small reward is given to customers renting cars while a small penalty is given if a car is dropped off there. In high-demand areas, no reward or penalty is given. The aim is to both encourage customers to take cars from low-demand areas to high-demand areas while keeping the incentive rewards and penalty balanced so the operator's costs are not too much affected. This methodology is tested by the authors on a carsharing service during a month and a half (Feb. 2017 and Mar. 2017), with a reference period of the month and a half just before (Jan. 2017 and Feb. 2017), with pricing areas as shown in Figure~\ref{fig:ch1_user_brendel}. The authors show that their methodology is capable of reducing the need for operator-made relocations by 15\% while increasing the overall number of trips by 11\%. In particular, the medium-area sees an important decrease in pick-up and drop-off of cars (resp. -11\% and -13\%) while the high-demand area sees an important increase in both pick-up and drop-off of cars (resp. +13\% and +15\%). However the main limitation of this approach is the customer willingness to make relocations and not to abuse from this reward/penalty system. Indeed in the past years, the service named \textit{Multicity} in Berlin had made the decision to reward its customers for plugging-in the electric cars of the service for recharge. However the operational team from Multicity discovered that several customers were having a non-standard usage of the cars as they were taking cars only to recharge them and not to make normal trips, and thus messing with the distribution of cars in the city since the already recharged cars were put next to the recharge hubs. \begin{figure}[!ht] \centering \includegraphics[width=0.8\textwidth]{figure/ch1_user_brendel.jpeg} \caption[Pricing Area Example]{Map from~\cite{brendel_decision_2017} of the pricing areas in the city studied by the authors. Three areas are defined by clustering the squares of a grid by taking into account the number of rentals departing the squares. Then the operator smooths the areas in order to make the areas fit geographical constraints and to make the pricing areas more understandable for customers. \textit{Area 1} is the high-demand area, \textit{Area 2} is the medium-demand area and \textit{Area 3} is the low-demand area.} \label{fig:ch1_user_brendel} \end{figure} A third approach made by the authors of~\cite{schiffer_polynomial_2021} is a methodology to compute how many trips could be served by a service if all the customers were willing to modify their trip to facilitate picking up of cars for the customers after them. This is similar to creating an upper-bound on the performance of the carsharing service if only the customer behavior could be modified. Knowing all the future true trips made by the customers, the main idea is to modify with slight changes all customers trips so that as many as possible requests are served by the cars. To do this, the authors define a sequence of trips as the sequence in which each trip following another should begin at a distance less than $\delta$ meters of the end of the previous trip and should begin after the end of the previous trip, with the objective to serve all trips of the chain with the same car. In this work, the authors allow themselves to modify the trip so that only one of its characteristic is modified, i.e either the spatial point of departure or arrival or the time of departure or arrival. These sequences of trips are generated from all the customer trips through the use of an Integer Linear Programming model in which an additional hypothesis is made: customers do not refuse the modifications made to their trip. To avoid using a generic solver and to reduce the time needed to find a solution, the authors propose a graph-based reformulation with a custom solver to find its solution. In order to validate their methodology, the trips from the service \textit{Car2Go} in Vancouver are used to generate different scenarios by sampling. The aim is to assess the performance of the reformulation depending on the number of customer requests and the number of cars. With their experiments, the authors show that their proposed graph-based reformulation improves as much the revenue of the service as the first \textit{ILP} formulation, but the solution found with less time by the proposed reformulation than the first \textit{ILP} counterpart. However, this model works when all the parameters are known in advance and most notably the customer trips. Thus is not usable to study which rate should be applied for a real carsharing service. Indeed it can only provide the upper-bound to expect if the service relies only on relocations made by modifying users' behavior. This method can be useful for a service, thanks to the possibility of using this methodology in a simulator, as this creates only the upper-bound that can be expected if a user-based relocation method is adopted without any additional intervention of the carsharing operator. Moreover if one is interested in knowing a more global upper-bound on the performance of the service, such as a combination of user-based and operator-base relocations, this method does not give such an upper-bound. \paragraph{Conclusion.} The methods presented here have the advantage of leveraging the user as a source for rebalancing the carsharing service. However while some works address one blocking point individually, such as defining areas to apply rewards or price penalties, or by studying how many more trips could be served if the customers were more or less forced to modify their trip, none provides a methodology directly applicable for a carsharing operator. Indeed, the incentives' amount to give to customers has to be studied with more precision and how to apply them in the general case of a carsharing service too, with the aim to have incentives appealing enough for normal customers to follow them and not too generous to remove abuses by malicious customers. On a more operational point of view such works could be integrated only in the long-term into the \textit{Free2Move} services since the operator has not, yet, the capabilities to offer precise incentives to customers based on their trips. \subsection{Operator-Based Relocation} Instead of making the user perform the relocations to rebalance the fleet of vehicles inside the city, the operator can directly act on the fleet. Indeed by hiring a dedicated team, the operator can assign each team member to the relocation of misplaced cars. The main advantage of this kind of approach is the guarantee that when a car is in need of relocation, then a staff member will relocate it, whereas in user-based relocations the operator can only hope for the cars to be moved to a better position. Furthermore an operator-based relocation can combine maintenance trips and recharge trips for electric vehicles too discharged to be taken by customers. In this part, three types of works are going to be presented. The first one concern the study of bikesharing services as studied in~\cite{chen_dynamic_2016}, \cite{tomaras_modeling_2018}, \cite{hulot_towards_2018}, \cite{raviv_static_2013}, \cite{ghosh_dynamic_2017} and \cite{ghosh_improving_2019}. The second one is about the station-based carsharing serviced as presented in~\cite{guo_vehicle_2020}, \cite{boyaci_integrated_2017} and \cite{zakaria_car_2014}. Lastly free-floating carsharing works of \cite{weikl_practice_2015} and \cite{folkestad_optimal_2020} are going to be shown. % \toignore{ % The ability to efficiently relocate cars is often heavily associated with the optimized usage of the operator's resources. Indeed, a vehicle sharing operator often hires only small team of workers to relocate the misplaced vehicles : if the operator is able to perfectly forecast the customer demand, a poor vehicle relocation management leads to a poor performance overall. Thus, there is the need to develop algorithms effectively telling which worker need to relocate a designated car to a specific location. This kind of relocation strategy done by the operator can be called \emph{operator-based relocations} and is presented in first. % } \paragraph{Relocations for Bikesharing.} Extensive research has been done for operator-based relocations in the context of bike-sharing. Like a carsharing service, a bike-sharing service is a transportation mean with vehicles, in this case bikes, freely available against monetary payment, usually in predefined stations. The users ride the rented bike and once their trip is finished, they lock the bike on a dock in order to let other users have the possibility to rent the shared bike. Since numerous bike-sharing services uses predefined stations within the city, the issue of demand and supply of bikes in each predefined station arise. Indeed if a person comes to rent a bike but find that none is available or if a person desires to end her bike trip but find no dock where to secure the rented bike, then the \emph{customer demand} is not met. The issue of demand and supply of bikes in a station is often associated with the rebalancing needed to be done by the service operator to keep each bike station with enough bikes to serve customers and enough free docks to let other customers park their rented bikes. For example, the authors of~\cite{chen_dynamic_2016} propose to regroup stations of the service into clusters so stations with the same behavior are regrouped into the same cluster. Then, the authors propose to predict the probability of an over-demand for bikes or under-supply of free docks, i.e whether there will not be enough bikes in a station or too many bikes in the station. This study provides the knowledge that the bike demand is influenced by time and weather features, including the temperature, as well as other less frequent occurrences of traffic or social events. This is further acknowledged by the authors of~\cite{tomaras_modeling_2018} who propose to consider the large city events that affect the distribution of bikes in the stations around the city. This exogenous information will also be important for a carsharing problem. Finally, the authors of~\cite{hulot_towards_2018} anticipate the over-demand/undersupply by training regression methods to predict the number of trips to be demanded in every station as well as the number of bikes to be returned. This allows them to detect whether a station needs bikes to be added or removed by the staff. By early detecting possible over-demand for bikes, the previously presented works suggest a first relocation strategy. However, knowledge about how many bikes should precisely be taken from which station to be delivered to stations in need of bikes could further improve the strategy. The authors of~\cite{raviv_static_2013} present a method to directly create the route for two vehicle services to rebalance the bikes. They consider that the bike relocation is done exclusively when the service is the least busy, e.g., during the night. In the same way, the authors of~\cite{ghosh_dynamic_2017} and~\cite{ghosh_improving_2019} adopt an optimization formulation in order to address the imbalance in the number of bikes in stations and create the routes for the staff vehicles. Compared to~\cite{raviv_static_2013} the authors add the support for relocation of bikes during the normal activity hours by globally anticipating the demand, with a probabilistic model of the demand. Even with the addition of a finer relocation process, e.g. by adding the areas from which bikes should be taken to which area they should be dropped off, the methodologies cannot be directly applied to the free-floating carsharing problem faced in this thesis. Indeed the assumption about the relocation capacity is different between bike-sharing and carsharing services. \paragraph{Relocations for Carsharing.} Unlike for bike-sharing services, the relocation process for carsharing service is constrained by physical limitations induced by the size of the vehicles. Indeed when a single staff member of a bike-sharing service can relocate a dozen bikes all at once by driving a truck with bikes inside, staff members of carsharing services need to drive each vehicle to relocate. This adds an additional overhead as at the end of the relocation, the staff members have potentially no other means of transportation to reach the next cars to relocate, whereas in bike-sharing relocations the staff member would always use his truck. Thus the general concept of relocation is the same for bike-sharing and carsharing services, but the relocation processes from the bike-sharing literature cannot be directly applied to carsharing services. For station-based carsharing services, in the article~\cite{guo_vehicle_2020}, the authors seek to rebalance a fleet of electric vehicles in order to minimize the waiting time of customers queuing at each \textit{passenger stations}. This methodology is split into two parts to take into account the imbalance of the demand and the need for recharge of the electric vehicles, made exclusively in \textit{charge stations} that customers cannot access. The first part concerns the relocation of vehicles between \textit{passenger stations} so that no station is in shortage or oversupply of cars. The authors proposes a nonlinear integer programming formulation to find the number of cars to move from one station to another. The second part is about the movement of vehicles by the staff of discharged vehicles from \textit{passenger stations} to \textit{charge stations} or the inverse for fully charged vehicles present in \textit{charge stations}. This part is divided into two sub-parts, first the computation of the charging schedule for discharged electric vehicles, from \textit{passenger stations} to \textit{charge stations}, and second the placement of fully charged vehicles, from \textit{charge stations} to \textit{passenger stations}. To find the solution to the scheduling of vehicle recharging the authors proposes a nonlinear integer formulation and a mixed-integer linear formulation for the placement of fully charged vehicles back in \textit{passenger stations}. It should be noted that both rebalancing problems are in real time, i.e. the relocations can be done at any time of the day. In~\cite{boyaci_integrated_2017}, the objective of the authors is to rebalance electric vehicles too. However contrary to~\cite{guo_vehicle_2020} an additional information about the staff responsible for each relocation is given by the authors' model. Furthermore, stations of the service are not split into two categories as each station can both serve customers with vehicles and recharge them, the recharging problem is not addressed in this case. By using a hierarchical optimization formulation, i.e. an optimization formulation that has multiple objective function with a hierarchical order of importance, the authors seek to improve the usage rate of the vehicle first and to reduce the cost of relocations in second. In addition to this optimization formulation, the authors developed a simulator in order to confirm that the proposed relocation plan returned by the solver can be done with the electric charge level of the vehicles before the relocation. If not, constraints are added to force vehicles to stay in a station and recharge and the optimization is launched again. Thus this approach addresses both the relocation of vehicles and the trips made by the jockeys, i.e. a staff member making relocations, in order to relocate the vehicles. However this is done for a service that can relocate the cars during the whole day, as opposed to the operator of the services provided by \textit{Free2Move} which has an additional constraint of being able to relocate cars only once per day. Another approach in~\cite{zakaria_car_2014} studies the effectiveness of a greedy algorithm in the relocation of vehicles for station-based carsharing services. Unlike previous articles, the recharging of electric vehicles is not taken into account and the objective of the authors is to elaborate a greedy algorithm to replace the usage of exact solvers for the \textit{ILP} proposed. This \textit{ILP} formulation seeks to minimize the number of rejected demands and the number of relocations made by the staff to do in order to reach this minimum of rejections. To do so, the service is modeled as a directed graph in which nodes represent a given station at a given time. In this graph, each arc between two nodes denotes a trip between a station at the departure time to another station at the arrival time of this trip. This representation makes an explicit \textit{Integer Linear Programming} formulation to be given to an exact solver to get an optimal solution. However, the authors observe during their experiments that the time needed for the exact solver to find a solution can take several hours, for a service that would consist of 50 stations with 10 parking lot and 6 trips per car, starting from only 4 jockeys. Moreover, the greedy algorithm developed by the authors consistently runs under a second, with the same material configuration, while keeping the number of rejected demands comparable to the optimal solution found by the exact solver. Thus for the current thesis while the formulation cannot be taken as is because its main hypothesis is that the demand is known beforehand, the need to have a greedy algorithm to find a solution should be taken into account in the thesis experiments. \begin{figure}[!ht] \centering \includegraphics[width=0.7\textwidth]{figure/ch1_reloc_weikl.jpeg} \caption[Operator-based Relocation Example]{Example (from~\cite{weikl_practice_2015}) of relocations proposed by the methodology~\cite{weikl_practice_2015}. Two macro-zones are shown in dashed lines and the micro-zones are the hexagons. Red hexagons are considered as hotspots, with a high demand, while blue hexagons are cold spots, with a low demand. Green squares are vehicles selected for maintenance, e.g for recharging or refueling. Arrows show relocations between micro-zones either from two different macro-zones or from the same one.} \label{fig:ch1_reloc_weikl} \end{figure} Using methods designed for station-based services can lead to different results on free-floating carsharing services. Indeed, as seen previously in Section~\ref{sec:user_behavior} the customer usage of services depends on the type of service, whether it's a station-based or free-floating one. Effects like the demand for cars for commute trips might lead to make station-based methods not optimal for free-floating carsharing services. Thus dedicated relocations methods have been developed specifically for free-floating carsharing services. For example, in~\cite{weikl_practice_2015}, the authors present a methodology developed for a carsharing operator in Munich. In this article, the authors propose an online five-step methodology that is supposed to monitor the distribution of cars continuously to keep it as close as possible to an ideal car distribution in the city. A preliminary step made before the five other steps is the discretization of the geographical area serviced. This discretization is first made by clustering the GPS points of trips departure into ten virtual stations, the objective is to create a small number of areas, also called \textit{macro-zones}, to be used for a later optimization step. Since each resulting macro-zone is wide, an additional grid consisting of hexagons, also called \textit{micro-zones}, is applied to represent the maximum distance a user is willing to travel to reach a car. Thus the operator is able to place a given number of cars inside the macro-zone by distributing them within the grid of micro-zones. Furthermore at the end of this preliminary step, the authors have discretized the geographical area serviced by the operator. The example of discretization given by the authors is illustrated in Figure~\ref{fig:ch1_cells_district}. After this preliminary step, the methodology is applied and its first step is run. The objective of the first step is to analyze historical data in order to categorize each micro-zone as either a hot spot, i.e. a zone with a short car idle time and a lower than average number of vehicles, a cold spot, i.e. a zone with a long car idle time and a higher than average number of vehicles, or a neutral spot, as shown in Figure~\ref{fig:ch1_cells_district}. Note that this categorization is done for every time period of the day, knowing that the day is split into periods of 3 hours. Then knowing a period of time in which relocations should be made, the second step computes the lower and upper bounds of the number of vehicles that should be present inside each macro-zone based on the historical number of reservations. Depending on the number of cars present in each macro-zone for the given time period, this step makes relocations of vehicles between macro-zones through an optimization formulation and based on the additional profit made by relocating the cars. Then the third step is run and take the relocations that have been proposed in step two in order to precise from which micro-zone to which micro-zone the relocation should be made. The vehicles are individually selected at this step and the selection is based on the list of high-priority vehicles depending on their idle time or the need for recharging. Furthermore, depending on the status of the car the relocation is potentially linked with a maintenance trips, such as plugging the selected vehicle in an EV station. Then the fourth step rebalance internally each macro-zone, with the aim to relocate cars from cold spots to hotspots. Unlike for step two, this is done based on operator-decided rules rather than an optimization formulation, with the objective of relocating an operator-decided maximum number of cars to take most idle cars in a macro-zone to the hotspots of the same macro-zone. It should be noted that macro-zones are rebalanced internally only if it is visited by a relocation from step two, i.e. a staff member is actually moving to this macro-zone. Finally, the last step is about the remaining maintenance trips that could not be associated with a relocation trip, e.g. for an electric car with a battery too low. An example of output given by this methodology is shown in Figure~\ref{fig:ch1_reloc_weikl} on a subspace of the service. This methodology has been tested on a real service in Munich during the months of October 2013, February 2014 and May 2014 and shows an increased in profit made by the serviced of 6\%. While this methodology is well designed for the operator running its service in Munich with its own constraints and capabilities, this methodology cannot be taken off the shelf to be directly applied and to leverage the capabilities of \textit{Free2Move} services, notably in the service located in Madrid. Indeed in the case of \textit{Free2Move}, the operator is capable of relocating the cars only during the night and EV charging stations of the city cannot be used, meaning that the operator has only one station available at its local headquarters from which all fully charged cars leave and all discharged cars arrive. Thus the constraints of this operator does not fit well the hypothesis of the presented methodology. \begin{figure}[!ht] \centering \includegraphics[width=0.5\textwidth]{figure/ch1_weikl_practice.jpeg} \caption[Weikl Methodology Steps]{Summary of the methodology proposed in~\cite{weikl_practice_2015}. The methodology has one preliminary step to define the macro-zones and micro-zones used for the relocation of cars. Then all other steps are applied one after another for each period of three hours to generate the relocations to do by the operator. This process is repeated for each period in the day, such that the service is continuously rebalanced by the operator.} \label{fig:ch1_weikl_practice} \end{figure} A different approach is made by the authors of~\cite{folkestad_optimal_2020} to improve a free-floating carsharing service. The objective of the authors is to optimize the recharging of electric vehicles, in order to both recharge them and relocate them in the same time. The main idea is to relocate only the car with a low battery state, i.e. those that cannot be used by the customers, to charging stations all around the city and not only to the nearest charging station. Furthermore, the authors make the hypothesis that the carsharing operator has vehicles dedicated to the staff members to move them around the city, e.g. to drop them near a battery depleted car or take a staff member who had finished a relocation job. Thus the methodology could propose to move a low battery vehicle to a station located far away if it allows the jockey to be taken by a staff vehicle right after. To do this, the authors propose a \textit{Mixed Integer Linear Programming} (\textit{MILP}) formulation to make the relocations while taking into account the route of the jockeys. As commercial \textit{MILP} solvers cannot solve instances of this problem, due to the complexity of managing both the route of jockeys and the route of staff vehicles, the authors propose a genetic algorithm to find a near-optimal solution. The experiments made show that the commercial solver used by the authors fails to find the optimal recharging and relocation for instances of eight vehicles with three staff vehicles and eight jockeys. Moreover, the algorithm proposed by the authors can solve instances with more cars, from 60 up to 200, and more staff vehicles and jockeys while keeping a computation performance under the hour. However this methodology does not fit the problem currently faced in the service in Madrid of \textit{Free2Move}. Indeed the authors only consider the relocation of cars with a low battery state, meaning that the cars to relocate can be picked up anywhere in the city but dropped only in charging stations or in their immediate vicinity once fully charged. But in the case of \textit{Free2Move}, the operator possess only a single charging station, thus optimization of car recharging location cannot be done. Moreover, the authors consider only the relocation problem with the strong hypothesis that all the customer demand is known in advance, which is not the case of \textit{Free2Move}'s service. \paragraph{Conclusion.} Fleet rebalance methods have been proposed for both bike-sharing and carsharing services. Bike-sharing focused methods cannot be directly applied to carsharing methods even if the global service can be similar, first because most works are designed around station-based services whose customer use cases are different than free-floating carsharing customers use cases. Second because constraints for bike-sharing are not strictly similar to those encountered in carsharing services, such as each vehicle as to be separately relocated by one staff member. Moreover methods from the station-based carsharing literature considered a low number of stations in their service. As shown later in this thesis, the number of ``virtual'' stations that should be made for free-floating carsharing make those methodology not scalable. In all cases, none considered the placement of vehicles for the next morning as the only way to address the fleet imbalance. Indeed, most methods table on ``online'' relocations meaning that those relocations are made throughout during the day, even if this might enter in conflict with customer usage since customer usage is more important during the day than during the night. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % SECTION - SECTION - SECTION - SECTION - SECTION - SECTION - SECTION - SECTION - SECTION - SECTION - SECTION % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \section{Transportation Simulation} The evaluation of either user-based or operator-based relocations by the service itself is limited by costs and by the difficulty to make the test each time a new strategy has to be tested. Indeed the operator of the service needs to redesign internal tools to incorporate the methodology to evaluate, not knowing if it will actually improve the service, and the operator needs to alter either how the service works for customers for user-based relocations or how the staff is managed to do the relocations in the other case. Furthermore in all cases, the operator needs to be able to take financial loss if the methodology has a poor performance. Thus, the practical evaluation of the methodology is capable of returning results to confront the methodology against the reality but needs resources to be done. It is in this context that the usage of simulators to emulate the functioning of real carsharing services has been developed. The simulation of carsharing services can be carried out by two different approaches. The first can be done without an a priori knowledge of the carsharing service itself, but requires to model the city and its inhabitants. This approach is based on multi-agent simulators in which the objective is to observe how each agent, e.g city dwellers, reacts to the presence of a carsharing service as an alternative to other public transportation systems or private vehicles. A second approach exists and models the usage of the service not as the product of agents usage but as a chain of events that modify the state of the carsharing service itself. In this second approach, less contextual data about the city or its inhabitants is needed to obtain a usable carsharing simulator. However the calibration of the simulator needs historical data about the carsharing service to choose which events and how many to take into accounts. Both approaches are presented here. \toignore{ Constraints: \begin{itemize} \item We don't have contextual datasets, e.g., fine population count. \item There is little data, at most 300 entries. \end{itemize} Finally, the last part of the bibliographic review shows the current state of art about urban mobility simulator. Since the aim of the internship is to optimize a carsharing service, it is mandatory to be able to compare which relocation strategies are good candidates for the free floating carsharing type of service. The simulation of car-sharing services can approached by two different types of methodologies. First, it is possible to use an event-based approach. In this case a series of events are prepared in advance and ordered chronologically to be applied to update an internal state. A second approach consist in creating a model of the simulated environment and add agents with their own objectives and internal rules. Agent-based simulations work by making its agent react to their needs and the modeled environment. In~\cite{ciari_modeling_2016}, the authors model the transportation infrastructure of Berlin, e.g., roads and public transportation tracks and stops, and its inhabitants. Parts of the population is chosen to be able to use a car-sharing service by being members. In this work, the authors don't need to explain how the car-sharing trips have been generated beforehand since all agents decide on-the-fly which transportation mode is used. Furthermore we lack data about contextual information, notably precise data about population residency, workplace and leisure places, precise spatial distribution of car owners in the city and so on. Thus works using such information to either directly generate city trips~\cite{goulias_recursive_1991}~\info{Il y a pas vraiment besoin de garder cette citation là.} or generate accurate agents to be used in multi-agent based simulation~\cite{ciari_modeling_2016} cannot be applicable in our current case. } \subsection{Multi-agent Based Simulation} Multi-agent simulations are used in transportation research in order to simulate the behavior of individuals facing the need to move from a spatial point to another. Different modes of transportation are offered such as buses, planes, trains, bikes or cars, with their own infrastructure such as bus/train lines, bus/train stops, city streets, highways or airports. By modeling as realistically as possible the real environment in which each agent will evolve, the aim is to compare the behavior of agents, e.g. people, when they need to plan their trips according to the transportation offers. Thus by changing parameters of the transportation system, such as adding bus lines or adding roads, the behavior of the agents changes accordingly and help to design better transportation infrastructure. With such simulators, the impact of adding a carsharing system can be studied as well as how the number of cars or the deserved areas affect the customer behavior. Furthermore different relocation strategies and how are placed the cars of the system can be simulated and their impacts studied. \paragraph{SimMobility.} The first example of multi-agent simulator is \textit{SimMobility}~\cite{adnan_simmobility_2016,azevedo_simmobility_2017} which has been developed as a tool to understand the evolution of a city through time depending on its transportation infrastructure. This simulator is split into three scales of simulation, each scale receiving and feeding information to another. The first and short-term scale simulates the behavior of the car traffic, its interaction with possible buses, bikes and pedestrians. This scale describes in detail the movements of the vehicles like lane changes, vehicles behaviors in intersections and so on. The aim of this short-term scale is to retrieve a realistic travel time needed for each simulated trip done by a person, for example to go from a building to another. Thus it is possible to simulate the details about the time needed for a person to travel from a certain building to another one in the city. The aim is to know how long it takes to travel through a given path at a certain hour of the day, e.g. for commute trips in the morning or evening, notable to be able to decide which path or what kind of transport to take. The second scale is a medium-term one : it simulates the schedule of each inhabitant in order to motivates the trips made during the day. For example, if the simulated person is an office worker, the simulator decides at what time he needs to leave home to go to work and which path and transportation mode to take in order to be quickly at work. The simulator could decide that the person then needs to move from the office at the end of the day to the nearest shop to buy some groceries before going home. This medium-term scale highly relies on the short-term scale to compare the time needed to travel a path in the city for each trip. All the trips created in this medium-term scale are used by the short-term scale simulation to simulate the traffic and the reasons behind the traffic, i.e. each car has a point of spatiotemporal point of departure and a given desired arrival. The last scale is a long-term scale which simulates the city real estate dynamics and the vehicle ownership dynamics. The aim of this scale is to simulate the change of home or office locations of the city inhabitants, depending on the inhabitants needs and financial capabilities, e.g if a worker's home is too far away from his workplace he might want to move to a nearer house. Thus, this scale needs the average schedule and the average time used to move in the city of each person to decide if this person needs either to buy a car or not, or to change for another job. Furthermore, it gives to the medium-term scale essential information about each inhabitant such as where he lives or works or if he owns a car or need to take the public transportation system. All those interactions between each scale is summarized in the Figure~\ref{fig:ch1_sim_mobility}, where all the information exchanged between each part of the simulation is represented. As is, the proposed simulator is not related to any carsharing service simulation since it only simulates the city's inhabitants trips dynamics. But it is possible to add a carsharing service to the simulator and offer it as a possible transportation system for the city dwellers. \begin{figure}[!ht] \centering \makebox[\textwidth][c]{\includegraphics[width=0.4\textwidth]{figure/ch1_simu_simmob.jpeg}} \caption{Diagram from~\cite{adnan_simmobility_2016} showing the interactions between each scales in the simulator framework. The long-term scale gives the location of the inhabitants and their jobs to the medium scale while receiving information about the time needed for a person to do the daily trip from his home to his job. The short scale receives from the medium scale the path the inhabitant has to take and gives back to the medium scale the time needed to do this path.} \label{fig:ch1_sim_mobility} \end{figure} Indeed as studied by the authors of the article~\cite{marczuk_autonomous_2015}, an application of this simulator is presented for the city of Singapore in which the inhabitants are simulated. A carsharing service is added to the city in order to evaluate its effectiveness, but with several conditions: \begin{itemize} \item The service is only working in the Central Business District of Singapore. \item Private car traffic is forbidden in the Central Business District, but the public transports and the taxis are allowed to freely run in this district. \item The carsharing service is run with \textit{autonomous} vehicles, meaning that the constraint of relocating the vehicles with jockeys is avoided. The vehicles moves without the need to have a human driver. \end{itemize} In this study, two types of carsharing are tested to compare which is the most efficient in this configuration. The first type is station-based, where vehicles always have to park to the nearest stations after a trip was completed. The stations have no limit on the number of parking lots. The second type is the free-floating type, where vehicles starts at the same stations, but without the need to get back to any station after a trip. It is sufficient for the car to be parked on the nearest standard parking lot. In this setting, the authors show that the free-floating type of carsharing performed better than the station-based service in terms of the number of trips serviced. The explanation given is based on the fact that cars of the station-based service needed to get back to a station before serving the next trip, thus leading to many more empty vehicles on the road and increasing the overall street congestion. \textit{SimMobility} provides a detailed simulation of how inhabitants reacts to the transportation offers in a city, such as shown by~\cite{marczuk_autonomous_2015}, and allow to study the impact of a new (autonomous) carsharing system. Relocation strategies could be studied in the case of free-floating carsharing, such ash the number of trips serviced or the profitability of the service. However this kind of simulator needs a lot of data to be correctly calibrated and thus to be as realistic as possible. Indeed the city roads, the building types and capacity, the public transportation system, current inhabitants detailed statistics and many other parameters are needed as exogenous data to do the calibration of the simulator. Thus in practice for the current thesis, this methodology is not usable because of the lack of such exogenous data. \paragraph{MATSim.} If one does not need to simulate the housing and workplace expectations from city inhabitants, MATSim~\cite{axhausen_multi_2016} is an available second state-of-the-art approach to run multi-agent simulation to study how inhabitants uses the transportation infrastructure. Instead of simulating housing and workplace expectations of each inhabitant according to their daily lives, MATSim takes as an input demand data about the population in the form of a place of residency and chains of activities to do in the city for each simulated agent, i.e a person. To do this, MATSim is split into five submodules with three main modules searching for the route each agent should take to do their chain of activities, as shown in Figure~\ref{fig:ch1_matsim}. \begin{figure}[!ht] \centering \makebox[\textwidth][c]{\includegraphics[width=0.8\textwidth]{figure/ch1_matsim.jpg}} \caption[MATSim modules]{Diagram showing how the modules of MATSim interact to simulate the inhabitants and their daily activities. Five modules are necessary to run the simulation, with three used in a main simulation loop to find through co-evolutionary method the optimal way to do each activity the chain of activity for each agent.} \label{fig:ch1_matsim} \end{figure} The first module \textit{Demand Initialization} is about the modeling of the data provided to MATSim to fit the simulator. Chains of activity are defined by this module as well as the agents. A chain of activity is defined by the ideal time of departure or arrival in each point of interest (\textit{POI}), such as \textit{Home} or \textit{Shop}, visited by the agent in the city, with additional information about the means of transportation used to go from \textit{POI} to \textit{POI}. Each agent is capable of memorizing up to a user-defined number of variations of the chain of activity with an associated score to reflect how optimal this particular chain of activity is for its owner. The second module \textit{Mobility Simulation} simulate the actual movement of agents, with the aim to compute the time needed for each agent to reach their destination knowing their departure location. Each agent chooses from its memory the best plan to be used during the simulation, i.e. the chain of activity with the highest objective score. An agent can be either the driver of its vehicle, e.g. a driver of a private car, or be the passenger of a vehicle, e.g. a bus passenger, and each agent interacts with the other agents to share the transport infrastructure, e.g. the road or the number of available seats in a bus. In the third module named \textit{Agent's Scoring}, each agent evaluates and updates the objective score of its trips and how well they allowed the agent to respect the initial chain of activity. It should be noted that each agent seeks to maximize the score of its own chain of activity. The score is computed according to observations between the actual chain of activity and the ideal chain of activity provided at the beginning, such observations as the waiting time (e.g arrived too early), or that activities are performed at the ideal time and with the ideal duration. This leads to have a simulation with a co-evolutionary approach in which each agent optimize its objective score without the aim to optimize a global score over all the other agents. The fourth module \textit{Agent Activities Replanning} concerns 10\% of the agent, by default, who are able to copy the chain of activity previously simulated and modify the copy to be simulated afterward. The modification can be done only on the departure time from a \textit{POI}, the route taken from a \textit{POI} to the next one, the mode of transportation used between two \textit{POI}s and the destination. While the time of departure and the mode of transportation are random based modifications, the route can be modified by the agent to be the best route possible knowing the traffic conditions of the last simulation. Finally, the fifth module \textit{Analysis} exposes the solution found by the simulator with analyses about them, such as the average score of each agent through the rounds. This fifth module is reached only when the user-defined number of simulation loops are done or when the average score of each agent during the simulation has converged. From this module the analysis of carsharing service usage is possible. This simulator has been used to study carsharing services as in~\cite{ciari_modeling_2016}. In this study the authors present a summary on how to model different types of carsharing services in \textit{MATSim}, either station-based (round-trip or one-way) or free-floating, with notably the management of members’ subscriptions. In other to check whether the simulator is realistic, the authors make a comparison between the rental data of a round-trip carsharing operator in Zurich and the simulated counterpart with all the exogenous data needed to represent the city and its inhabitants. The comparison shows that with a simulator calibrated with traffic count data from this city, both the distribution of rental length and the distribution of carsharing trips start time of the simulation matched the distributions observed in real. In the study~\cite{ciari_modelling_2015}, \textit{MATSim} is used on the same simulated city and round-trip carsharing service to evaluate the impact of using different pricing strategies and observe how is affected the spatial repartition of the trips as well as their purposes. However even if \textit{MATSim} can be used as an accurate tool to simulate the utilization rate of carsharing services, several design constraints make it unable to be used in the current thesis. Indeed census data about inhabitants residency and workplaces are needed to build the chain of activity previously described. Furthermore, the simulator itself is used to simulate one day at a time: relocations acting on a weekly term cannot be accurately simulated without major modifications on the simulator or without using a computing intensive workaround to simulate all days at once. \subsection{Event Based Simulation} \textit{Discrete Event-based Simulation} (\textit{DES}) is a type of simulation in which the system is affected by a chain of events that modify the internal state of the simulator. Each event to be simulated has a timestamp attached, so that the chain of events correspond to a temporal order of events to resolve. During the simulation, the events are simulated one after another until there is either no event or no time left to simulate. Furthermore, each event changes the state of the simulation in a discrete manner, meaning that time skip can occur between two events since the simulation state does not change between two time-consecutive events. In this case the \textit{DES} is a \textit{next-event time progression}. Indeed the first event of the chain is simulated, then the internal clock of the simulation is set to the next event to simulate before simulating it. If time is incremented by fixed time slices, e.g. one minute, instead of jumping from event to event, with events within the time slice been resolved by the simulator, then the \textit{DES} is called a \textit{fixed-increment time progression}. The flow of event resolution is summarized in Figure~\ref{fig:ch1_des}. It should be noted that some agent-based simulations are \textit{DES}, indeed the mesoscopic simulation of the vehicles of \textit{MATSim} is based on chains of events such as a car entering a road or leaving it. However other agent-based models are not \textit{DES} because time skips cannot happen due to the physical phenomenons to simulate, such as the microscopic simulation of travel time on roads from \textit{SimMobility} which is done to replicate the physics involved in the vehicles driving on the road, e.g. accelerating or breaking, and interacting with others, i.e traffic dynamics. \begin{figure}[!ht] \centering \makebox[\textwidth][c]{\includegraphics[width=1\textwidth]{figure/ch1_des.jpg}} \caption[\textit{DES} Event Resolve Flow]{Execution flow of \textit{Discrete Event-Based Simulation} (\textit{DES}) depending on whether it is a \textit{next-event time progression} (top) or a \textit{fixed-increment time progression} (bottom). In all cases, the events are in a time-ordered stack and drawn from the earliest to the latest event to resolve. In the \textit{next-event time progression}, a timestamp is kept to resolve the events, the next event's timestamp is set as the current timestamp before resolving the given event. This is repeated for all the events until no events are left in the stack. In the \textit{fixed-increment time progression} a period is initialized as the start, all events in this period are resolved simultaneously and the period is incremented after. This is repeated until there is no event left in the stack.} \label{fig:ch1_des} \end{figure} Transportation simulation uses \textit{DES} and one example of \textit{DES} utilization is the article~\cite{cats_mesoscopic_2010} about the simulation of a public bus system in Tel Aviv. In this work, the authors use a simulator called \textit{Mezzo} which simulates vehicles and roads on mesoscopic scale, for example roads are represented as two parts: the first one listing moving vehicles and the second part listing the queued vehicles waiting to leave the road while taking its source at the running traffic from the first part. In the case of public buses and with this scale of representation, important phenomenons such as traffic jams and bus bunching are kept. The authors also defines the events linked to the public bus behavior on top of the ones necessary for traffic simulation, such as \textquote{Enter Bus Stop} or \textquote{Trip Departure} to take respectively into account a bus arriving at a bus stop to let people enter/leave the bus and a bus that begin its trip on a given line. Even if the bus simulation developed by the authors cannot be used by itself for the simulation of a free-floating carsharing simulator, this example of \textit{DES} is one example of the state-of-the-art about the design of a \textit{DES} and the nature and orders of events to take into account if a \textit{DES} has to be designed for a transportation simulator specifically for carsharing. Some carsharing works presented in Section~\ref{sec:share_vehicle_service_improvements} have developed their own \textit{Discrete Event-Based Simulation}, usually on a macroscopic level. For example, to evaluate their relocation and recharge methodology, the authors of~\cite{boyaci_integrated_2017} uses a \textit{DES} developed by the authors of~\cite{repoux_simulation_2014}. In~\cite{repoux_simulation_2014}, the authors developed a \textit{DES} to simulate a station-based, one-way, carsharing service with its customers’ reservations, either spontaneous or in advance, and staff-based relocations. These actions on the system are modeled by events both for customer-based trips, such as \textquote{Rental Start} or \textquote{Rental End}, and for staff-based relocation events, such as \textquote{Personnel Availability Start} or \textquote{Relocation End}. It should be noted that the customers-based events and the staff-based relocation events are fed to the simulator as parameters. Thus contrary to previously mentioned simulators, to feed this simulator with rental events a user needs to have a historical dataset of the customers trips. Indeed the creation of the rental events, notably \textquote{Rental Request}, is done before the simulator is run unlike agent-based simulators such as \textit{SimMobility} or \textit{MATSim}. Furthermore, the status for stations and their parking lots as well as for each electric vehicle are modeled in the internal state of the simulation. Thus the events act on those states and modify them, with for example an event \textquote{Rental Start} modifying the state of a car from \textquote{Available} to \textquote{Occupied} and the state of the parking lot where the car was located too. In this particular simulation, the authors of~\cite{repoux_simulation_2014} decided to loosen arrival constraints linked to station-based services by allowing customers to drop off vehicles near the station on extra parking lots, with these extra-spots unable to serve as charging points for electric vehicles. Another example of \textit{Discrete Event-Based Simulation} usage for carsharing is presented in~\cite{fassi_evaluation_2012}. The authors seek to select the best growth strategy for a station-based, round-trip, carsharing service, i.e. how the set of stations and their size should evolve in the service. Several possibilities are studied by the authors such as the increase of the station's capacity, the creation of new stations or the merging of several stations. The objective is to answer the demand growth with the modification of the carsharing service, while keeping a high customer satisfaction and minimizing the number of vehicles required for that. Several assumptions are made for the \textit{DES} designed by the authors, such as reservations possibly made six days in advance, the customer station selection linked to his distance to the station or the absence of distinction between weekday and weekend demand. Once the events representing the actions that customers can do in the system and the internal state are defined by the authors, with similarities to~\cite{repoux_simulation_2014} without the need for relocation events since the simulated service is round-trip, the authors define the three actions the carsharing operator can make. The \textquote{increment capacity of existing stations} is the first action a carsharing operator can do when the demand increase, affected by a demand growth input at the start of the simulation, and this action consist in adding additional car to the station. This action is usually done when the station is in a dense area or when it would be viable to add a new station close by. The second action is the \textquote{merging of station} and merge at least two stations into a unique station whose capacity is the sum of the merged stations. This action is taken by the operator when a close group of station each has a low utilization rate. Finally, the last action is the \textquote{new station implementation} which create a new station in the service with its size determined according to the demand in the area. This action is used when a new spatial demand emerges in a place not deserved by carsharing stations. These three actions are combined and creates a scenario of growth for the carsharing operator, with the objective to simulate the performance of different scenarios when simulating the same demand growth. This approach is tested on the case of \textit{Communauto}, a station-based service in Montreal. The authors evaluate four scenarios, after an initial data analysis phase to determine the current utilization and its expected growth in each region of the city. The first two scenarios are created from the data analysis made by the authors while the third scenario is based on actual service growth actions made by the operator \textit{Communauto}. The fourth scenario studies the actions made by \textit{Communauto} and actions added by the authors to counteract the negative effects observed for the third scenario. While the results of this study in themselves are not of interest in the scope of this thesis, the presentation of the \textit{DES} created by the authors, like for~\cite{repoux_simulation_2014}, is an accurate vision of how \textit{Discrete Event-Based Simulation} is used to study either relocation or growth strategy for carsharing services. \paragraph{Conclusion.} \textit{Discrete Event-based Simulation} is a type of simulation in which each action is modeled by events that modify the internal state of the simulation. This type of simulation can be used to simulate transportation modes and in particular carsharing services, notably when contextual data about the reasons why each customer individually wants to use the service lacks. Examples such as~\cite{fassi_evaluation_2012,repoux_simulation_2014,boyaci_integrated_2017} study actions that can be made by the operator of carsharing services such as relocations or station modifications to improve the utilization rate of the carsharing service. However the presented simulations have flaws about the generation of demand during the simulation; indeed the demand is fixed at the start of the simulation and does not adapt itself to a possible new state of the distribution of cars in the city: the demand is inflexible and constrained to historical data. Furthermore in those studies, the past trip data is considered de facto as a demand data. While past trip data is near the real demand data, the real demand data is often unobserved since in the presented cases stations can be empty, a demand cannot be satisfied and cannot be registered into the trip data, or can be full, a demand for \textit{A to B} can be mis-registered in the trip data as \textit{A to C} if station \textit{B} is full and the customer needs to find another station to drop off his car. These studies serves as the base for the design of a \textit{DES} specifically designed for free-floating carsharing and designed to reduce the flaws linked to the historical trips being considered as demand data. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % SECTION - SECTION - SECTION - SECTION - SECTION - SECTION - SECTION - SECTION - SECTION - SECTION - SECTION % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \section{Regression Algorithms} The contribution of this thesis, presented in Chapter~\ref{ch:method}, is based on the utilization of regression algorithms to predict the daily usage of cars. Regression is a type of \textit{Supervised Learning}, meaning that the algorithm will use the data present in a \textit{training set} in order to learn a model, i.e. a mathematical function, to predict the numerical value of the \textit{label}. Each label is associated with a set of \textit{features}, i.e. values of interest, present in the data. The aim is to learn a function ($\hat{f}$) as close as possible to a real (and unknown) function ($f$) with only a set of observations, the values $f(x)$ of label given a set of features' value $x$. This is done by tuning the internal parameters of the model used. For example, in the case of a simple linear regression $\hat{f}(x) = a \cdot x + b$ only $a$ and $b$ are the internal parameters of the model and their value need to be tuned so the trained function $\hat{f}$ is close to the real function $f$. This \textquote{closeness} is assessed by the use of a loss function ($\mathcal{L}$) measuring the distance between the learned function's prediction and the real observations in the \textit{training set}. For example, the \textit{Mean Squared Error} (\textit{MSE}) is a common loss function and is defined as $$MSE = \mathcal{L}(f, \hat{f}) = \frac{1}{n} \sum^{n}_{i = 1} \left(f(x_i) - \hat{f}(x_i)\right)^{2}$$ with $f$ being the real (unknown) function to model, with the approximate and learned function $\hat{f}$, with $n$ observations, with $x_i$ the $i^{th}$ set of features' value and with $f(x_i)$ the label of the $i^{th}$ observation. Thus, training the model means to find the best parameters of the models such that the loss function is minimized. It should be noted that if there is only one label to predict ($\hat{f} \in \mathbb{R}^n \mapsto \mathbb{R}$), then it is a \textit{single output regression} model, and if multiple labels are to be predicted at the same time ($\hat{f} \in \mathbb{R}^n \mapsto \mathbb{R}^p$), then it is a \textit{multi-output regression} model. Once the model is trained with the \textit{training set}, the performance of the model is then evaluated with a set of data called the \textit{test set}. This different set of data is used to assess the prediction behavior of the model on data it has never encountered before. This is to detect if it has \textit{underfitted} the data, i.e. it does not have enough data to learn a precise enough generalization, or \textit{overfitted} the data, i.e. it has \textit{learned by heart} all the observations. For regression models, the most used evaluation functions are the \textit{Mean Absolute Error} (\textit{MAE} in Equation~(\ref{eq:ch1_mae})), the \textit{Mean Squared Error} (\textit{MSE} in Equation~(\ref{eq:ch1_mse})) and the \textit{Root Mean Squared Error} (\textit{RMSE} in Equation~(\ref{eq:ch1_rmse})). In the three equations, $n$ is the number of instances of the label to predict in the test set, $y_i$ is the true value of the $i^{th}$ instance of the label and $\hat{y}_i$ is the value predicted by the model of the $i^{th}$ instance of the label. Each function is used depending on the wanted interpretation of the error. \textit{MAE} is used to linearly measure the mis-estimation made by the model, for example an error of $4$ between the real value and the prediction counts for twice the error of $2$ in the final \textit{MAE} value. With \textit{MSE} the measure impact of an error is quadratic, for example an error of $4$ between the real value and the prediction counts 8 times more than an error of $2$ in the final \textit{MSE} value. This measure is used to give a high single error more importance than multiple small errors in the final measure. The measure \textit{RMSE} is the root square of the \textit{MSE}. In the next chapters, \textit{MSE} and \textit{RMSE} have not been chosen and only \textit{MAE} is kept because this measure is less sensitive to outliers in the errors. Indeed, higher errors due to outliers are less affected by the function \textit{absolute} than \textit{square}. \begin{equation} \label{eq:ch1_mae} MAE = \frac{1}{n} \sum^{n}_{i = 1} \left|y_i - \hat{y}_i\right| \end{equation} \begin{equation} \label{eq:ch1_mse} MSE = \frac{1}{n} \sum^{n}_{i = 1} \left(y_i - \hat{y}_i\right)^2 \end{equation} \begin{equation} \label{eq:ch1_rmse} RMSE = \sqrt{\frac{1}{n} \sum^{n}_{i = 1} \left(y_i - \hat{y}_i\right)^2} \end{equation} For models having hyperparameters, i.e. parameters controlling the training process of the model, a \textit{validation set} different from the test set can be used, like a test set but with the only objective, to find the best hyperparameters. The best hyperparameters are the ones maximizing the performance of the model in the prediction of labels from the features with both from the validation set. \begin{figure}[!ht] \centering \makebox[\textwidth][c]{\includegraphics[width=0.6\textwidth]{figure/ch1_decisiontree.jpg}} \caption[Example of Decision Tree]{An example of a \textit{Decision Tree}. The problem is to predict the number of inhabitants in a city district. Square nodes are decision nodes with their criterion and circles are the leaves with their returned value. This Decision Tree needs to know two \textit{features} of the district to predict the number of inhabitants, the type of the area, e.g. residential, and the number of bus stations. For example, if the district is a residential area with only two bus stations, then the Decision Tree will predict that $1205$ inhabitant live in this district.} \label{fig:ch1_decisiontree} \end{figure} \paragraph{Gradient Boosting Decision Trees.} The first regression algorithm that is going to be used in the Chapter~\ref{ch:method} is the \textit{Gradient Boosting Decision Tree} in its regression variant. It is an \textit{ensemble method}, meaning that it combines multiple occurrences of the same type of simple regression model in order to create a model more accurate than one occurrence of this simple regression model alone. In the case of the \textit{Gradient Boosting Decision Tree}, an ensemble of \textit{Decision Tree} is made. A \textit{Decision Tree} is a machine learning model based on a binary tree in which each leaf is a numerical value in the case of a regression. All other nodes, including the root node, is a decision node with a criterion based on the data features to decide whether to select the next node on the left or right. If the next node is a decision node the same action is applied, if the next node is a leaf then its value is returned as the prediction. It is during the training of the model that the Decision Tree is created. Each decision node is created by taking the features and labels assigned to the node and finding the best test to separate all the values of the label, for the root node all the training set is assigned, while for the remaining decision node it is only the data answering (or not) to the test. The test is created such that the entropy of the data fitting the test on both sides, test true or false, is as low as possible, i.e. the data regrouped for the creation of the children decision node (or leaf) is as homogeneous as possible. If the maximum tree depth is reached, or not criterion can be found, a leaf is created by taking the mean value of the label (in the case of the regression variant). In the Figure~\ref{fig:ch1_decisiontree} a mock-up decision tree of depth three is represented as an example of the prediction of the inhabitant number living in a district according to the features \textquote{area} and \textquote{nb\_bus\_station} of the district. One can note that the tree is not required to be balanced, one branch is shorter than the others. In this example only the type of area and the number of bus stations are necessary to predict the number of inhabitants. \textit{Gradient Boosting Decision Tree} is a set of \textit{Decision Trees} that are trained one after the other. The first Decision Tree is trained with the data from the training set like detailed previously, and then the following Decision Trees are trained to take into account the error made by its precedents Decision Treed trained. This means the data given to each subsequent Decision Tree for its training is altered by how well the preceding Decision Trees had trained on the data from its training set. When used, the first tree of the ensemble of tree is given the value of the features to predict the value of the label. Then the second tree is given the same features' value to predict the \textit{correction} to apply to the value of the label predicted by the first tree. This operation is repeated until all the tree of the ensemble have been used. As explained previously, the main advantage of this approach is the increase in the accuracy of the ensemble model. However this regression model needs more computational power to be trained and used for the prediction. \paragraph{Support Vector Regressor.} The second regression algorithm used in the Chapter~\ref{ch:method} is the \textit{Support Vector Regressor} (\textit{SVR}). Instead of creating binary trees which result to split the dimension of features into subspaces, the Support Vector Regressor algorithm aims to find a plane to describe the data. It is inspired by the \textit{Support Vector Machine} (\textit{SVM}) which is its counterpart in classification, i.e. to predict categorical labels instead of numerical labels. The \textit{Support Vector Machine} can either have a linear or a nonlinear kernel. In the case of a linear kernel, the algorithm seek a plane to separate the points according to their features such that one subspace of the feature space correspond to a label and the other subspace to the other label. The plane is chosen so the margin between the plane and the data points of each type of label is symmetric and as wide as possible. In the case of a nonlinear kernel, the plane is chosen in a higher dimensionality then the space of features, creating a \textit{hyperplane} to separate the data points of the training set. In the case of the \textit{Support Vector Regressor}, instead of separating the space of features to have two distinct subspaces, one for each categorical label, the algorithm seek a plane to cover the most data points within the user-given symmetric margins. The objective is to take into account as many data points as possible to create the plane whose function will serve as the function to make the prediction. Like the Support Vector Machine, a linear or a nonlinear kernel can be used depending on the complexity of the phenomenon to model. In the first case, the plane will be in the same dimension as the feature space while in the second case like for the SVM a hyperplane will be learned from the data. For both SVM and SVR models, categorical features, such as the type of area in the previous example, cannot be used as is since the space of features needs to be $\mathbb{R}^n$, with $n$ the number of features. In order to use those categorical features with SVM and SVR, they can be cast into multiple numerical features in a one-hot-encoding fashion. Thus for a categorical feature, each possible value of this feature will be transformed into one numerical feature being either $1$ if the categorical feature has this value else $0$. For example, if in the previous example there is three types of \textquote{area}, e.g \textquote{residential}, \textquote{commercial} and \textquote{office}, then three numerical features are created \textquote{area\_residential}, \textquote{area\_commercial} and \textquote{area\_office}. If a district is a residential area then the feature \textquote{area\_residential} is $1$ while the remaining two are $0$. \paragraph{Conclusion.} Regression algorithms seeks to create a model capable of predicting a numerical label given a set of features and their value. The objective is to model a real phenomenon whose exact mathematical function is unknown, e.g. the number of inhabitants in a district according to the type of district and its public transportation offer. To create the model, a dataset is necessary and split into three subsets, one for the \textit{training} of the model, one for the \textit{validation} of the model's hyperparameters and one to \textit{test} the performance of the model. Two state-of-the art regression models are the \textit{Gradient Boosting Decision Tree} and the \textit{Support Vector Regression}, both model the label's values according to the space feature by different means, the first by creating subspace answering criteria while the second create a (hyper)plane to model the data points. Other regression models have been tested (such as \textit{k-nearest neighbors} or \textit{multi-layer perceptrons}), however since only the \textit{Gradient Boosting Tree Regressor} and the \textit{Support Vector Regressor} are the best models found, only them are going to be used and tested to predict the utilization of cars in a carsharing service, as presented in Chapter~\ref{ch:method}.