• Aucun résultat trouvé

Offered service – Rental protocol

Dans le document The DART-Europe E-theses Portal (Page 33-36)

1.2 VSS design, offered services & consequences

1.2.2 Offered service – Rental protocol

When designing a one-way VSS, system operators need to decide what types of service to offer to the users: how the system can be used and what is the protocol for a user to access these services. In the following, we describe different possible services. They are not exclusive and they can be mixed to form a general offer.

Protocol definition A VSS user is interested in reaching a destination location d (GPS point), from an original location o (GPS point), during a specified time frame. For instance, for a morning commuter, o would be his home, d his work place, and his time frame would be constrained by leaving his bed not before 7am and by arriving at his desk not after 9am. To perform his journey, the user has to find an available vehicle close to his original location. He can question the system

1.2. VSS DESIGN, OFFERED SERVICES & CONSEQUENCES 19

Figure 1.1: VSS protocol, from a GPS-GPS demand to taking a station-station trip.

either directly at a station or through a software (on his smart-phone for example).

He has probably several admissible options to take his trip. These options respect his time frame, his time flexibility, but also his spatial and his price flexibilities. We call protocol the interaction, the communication process between the user and the system. If the protocol ends with a feasible solution, i.e. a spatio temporal trip admissible for the user and the system, the user takes this trip.

Figure1.1 schemes an example of a station-based system in which a user wants to take a trip between two GPS locations (from left to right represented by the crosses). He has 4 admissible original stations and 5 admissible destination stations represented in the circles. He finally chooses a trip between 2 stations out of the 20 admissible trips. The way he reaches the original station (resp. destination location) from his original location (resp. destination station) can be hidden or not from the system’s point of view. Hence, users might use different transportation means in coordination with the VSS system through a multi-modal trip planner. For instance, inHangzhou Public Bicycle, the same card is used to take the bus and a bike.

Real-time rental To the best of our knowledge, in all BSS, users ask to take a vehicle to use right now. We call this protocolreal-time rental. When a user takes a vehicle at a station, he can return it whenever and wherever he wants (under the condition of finding a free parking spot!). In station-based systems, due to the finite station capacities, it might be impossible for a user to return his vehicle at the desired station. It is a big issue for cars, first because costs are higher than for bikes and second because problems of traffic jams and blockings may occur. In Autolib’, when a user is unable to find a free parking spot in a whole area, he can contact special agents to retrieve his vehicle. This management costs money and might be a bad experience for the user.

Parking spot reservation One of the solutions to avoid considering this “return-ing” problem is to introduce the possibility of reserving a parking spot at destination.

For instance, Autolib’ allows the user to reserve a parking spot at a station for 90 minutes. From the user’s point of view, such reservation possibility is convenient.

However, from the system’s point of view, it might decrease the overall performance.

Indeed, to ensure that a user will park his vehicle at a specified station, the system needs to lock a parking spot during the whole time of the trip. For high intensity rental systems, overbooking policies might significantly improve the number of trips.

Nevertheless overbooking leads to a complex management of “collateral damages”.

Trip reservation in advance Another feature that users could appreciate is the possibility to reserve a trip in advance. This possibility is offered in Autolib’ and Car2go that allow to reserve a vehicle 30 minutes in advance. When receiving a future trip request from a stationa to a stationb, the system’s unique way for being sure to serve it is: 1) to currently have a vehicle at stationaand a free parking spot at station b, 2) to lock them until the reservation ends. Such reservation protocol (locking resources) may work when booking at most half an hour in advance or so.

For earlier reservations, its efficiency might be poor because of its rigidity: a single reservation could lead to refuse a lot of trips.

Subscription Since some users are periodically taking the same trip, they might be interested to subscribe to a regular service. In this case, and maybe also for long term single trip requests, one could assume that users are ready to wait after expressing their request. During this period, the system could be able to consider several trip requests at the same time and to select which ones to serve in order to maximize a global interest.

Real-time hazards If a system’s operator wants to offer reservations in advance or subscriptions, it is not reasonable to think that he will lock a vehicle and a parking spot for a couple of days until the trip happens. Moreover, if he coordinates several trip reservations to obtain a feasible (deterministic) solution, it could work in a theoretical world but may not meet the reality. Indeed, one cannot assume that all reservations will go through because of real-time hazards such as no shows, accidents, traffic jams. . . Hence, since problems of reservation feasibilities are inherent, allowing overbooking and considering real-time routing can be a solution to improve the system efficiency.

1.2. VSS DESIGN, OFFERED SERVICES & CONSEQUENCES 21

Overbooking When allowing reservations in advance, the system’s operator needs to consider the probability of not going through a reservation of a vehicle or parking spot. It is also the case when playing with overbooking. In practice, special agree-ments with users, such as financial engagement or taxi use as substitution, should be considered.

Real-time routing When users have issues to find a free parking spot at des-tination, or if they have a car that is getting low in energy, the system operator might like to help them to route their vehicle in real-time in order to find a solution.

Autolib’ offers such service: when a user is unable to find a free parking spot in a whole area, he can contact special agents to retrieve his vehicle. Car2gomaintains a

“fleet team” that is dispatched to address issues such as low battery levels. When-ever any car falls below 20 percent charge, the fleet team is notified and a team member is dispatched to the car to bring it to a charging location.

Multi-modal routing VSS are part of the city public transportation system.

Multi-modal trip planners, integrating VSS with other public transportation means, are interesting from the user’s point of view. Regarding the VSS utilization max-imization, such trip planner might also enable to dispatch the demand by offering alternative trips to users. Notice that for such trip planners, having systems offering trip reservations in advance could be interesting for users so they can really count on taking the VSS trip proposed.

Car pooling For CSS, cars’ 5 or 7 seats might be seen as a resource to dispatch.

To use efficiently the system, one should coordinate users taking the same trip,i.e.

organizing car pooling. It would be a chance for users to diminish their individual financial cost as well as their ecological impact.

Dans le document The DART-Europe E-theses Portal (Page 33-36)