Evaluating prebooked on-demand mobility services using MATSim

Sebastian HÖRL, Tarek CHOUAKI, Oliver LUDWIG, Hannes REWALD, Steffen AXER

25 April 2024

ABMTRANS 2024

  • Mobility-on-Demand / Demand Response Transport systems are frequently simulated using MATSim
     
  • For a long time, only immediate requests were supported (customers sends a request and a vehicle approaches)
     
  • However, in many contexts (rural), services will required customers to prebook their requests
     
  • Existing solution: Identify trips in the beginning of the day, then preplan the schedules of the fleet vehicles - Preplanning approach by Chenqi LU
     
  • This solution: Integrate prebooked requests into the insertion algorithm used in MATSim - Prebooking approach

Introduction  /  Context

  • We document the implementation of prebooked requests in MATSim's DRT algorithm
    • Challenge: The DRT algorithm itself is not well documented, so we needed to describe the basic functioning and our modifications
       
  • Changes were required in three areas
    • Insertion algorithm
    • Vehicle scheduling
    • Stop simulation
       
  • Proof-of-concept simulations using the new code to show functionality
     
  • Caveats and Next steps

Introduction  /  Scope

DRT Algorithm

  • Each vehicle has a schedule of tasks: Idle, Drive, Stop
     
  • At each stop, several pickups and dropoffs of passengers happen
     
  • A new request needs to be inserted into the schedule
    • Each request has a latest pickup time and a latest dropoff time
    • Need to find the best insertion along all vehicle schedules that fulfills the constraints for the new request as well as for all scheduled requests

Prebooking  /  Overview

  • Now, agents can send requests in advance (prebook them)
    • In their daily schedule, a DRT trips is present
    • A prebooking identifier is assigned to each prebooked trip
       
    • A request is already sent at a configurable submission time in advance
    • Each prebooked request has a earliest departure time that is used by the algorithm
      (= When does the agent plan to depart?)
       
  • General optimization / simulation process

Insertion

Scheduling

Simulation

Where along the should new requests be inserted?

  • For prebooked requests
  • In the presence of schedule prebooked requests

How are idle times introduced by prebooked requests are handled?

How are interactions with customers handled? Late arrivals?

Prebooking  /  Insertion algorithm

  • Insertion algorithm calculates a slack time s (black) by which every existing stop can be shifted to the future (limited by the end of day and latest pickup/dropoff times)
  • Slack time of a stop is limited by the following slack times

Prebooking  /  Insertion algorithm

  • Insertion algorithm calculates a slack time s (black) by which every existing stop can be shifted to the future (limited by the end of day and latest pickup/dropoff times)
  • Slack time of a stop is limited by the following slack times
  • Prebooked requests (pickup far in the future) introduce an additional idle slack that extends the slack of preceding stops

Prebooking  /  Vehicle scheduling

  • Initially, a new stop (pickup or dropoff) is inserted as early as possible in the schedule at the insertion location and the vehicles continues as early as possible to the next stop as all requests are immediate

Prebooking  /  Vehicle scheduling

  • Initially, a new stop (pickup or dropoff) is inserted as early as possible in the schedule at the insertion location and the vehicles continues as early as possible to the next stop as all requests are immediate
  • Now, prebooked requests introduce idle times during the day. Should the vehicle wait at the preceding stop, or drive directly to the prebooked stop? Are there performance impacts? A new parameter is introduced!

Prebooking  /  Stop simulation

  • In the standard case, each vehicle stop has a fixed duration. Dropoffs happen upon arrival, pickups at the end.

Prebooking  /  Stop simulation

  • In the standard case, each vehicle stop has a fixed duration. Dropoffs happen upon arrival, pickups at the end.
     
  • Now, customers assigned to the same stop may arrive at different times. However, we want to enforce a fixed interaction time with the vehicle. This required introducing a small-scale queue simulation per stop.

Proof-of-concept  /  Experimental design

  • Test simulation for the city of Melun
     
  • Cut out from an open large-scale synthetic travel demand for the Île-de-france region (10% sample)
     
  • Obtained all car trips and converted them to DRT

823 requests

Proof-of-concept  /  Experimental design

  • Test simulation for the city of Melun
     
  • Cut out from an open large-scale synthetic travel demand for the Île-de-france region (10% sample)
     
  • Obtained all car trips and converted them to DRT

823 requests

Hour

Proof-of-concept  /  Experimental design

  • Test simulation for the city of Melun
     
  • Cut out from an open large-scale synthetic travel demand for the Île-de-france region (10% sample)
     
  • Obtained all car trips and converted them to DR

823 requests

Hour

Prebooking parameters

  • Share of prebooked requests
  • Submission slack
  • Scheduling mode: drive early vs. late

Proof-of-concept  /  Results

  • Rejection rate decreases with higher prebooking share (at any submission slack)
  • Prebooked requests are rarely rejected in any configuration
  • Submission slack has primarily impact on remaining immediate requests
  • Proactive driving ("Eager") to the next step reduces performance in most cases

Proof-of-concept  /  Results

  • Wait times and detours decrease with higher prebooking rate

Proof-of-concept  /  Results

  • Fleet distance increases with higher prebooking share
    • Because more requests are accepted overall
  • Empty distance share increases as well
    • Apparently, high empty detours are introduces to accommodate the demand

Proof-of-concept  /  Results

  • Increases of occupancy throughout the day due to higher demand

Proof-of-concept  /  Conclusion

  • We now have the tools to explore prebooked services in MATSim
     
  • More sensitivity analysis in different contexts are required
    • High demand / low demand
    • High density / low density
    • Spatial balanced / imbalanced
    • ...

Caveats  /  Prebooking logic

How do we decide when a request is sent? How much in advance?

 

  • Flexible interface has been provided in the code
     
  • Three default implementations can be chosen
     
    • Fixed duration before planned departure (for instance, 2h in advance)
    • Configurable probability for each request being prebooked
       
    • Advance duration is saved in an attribute of each trip of each agent
    • Requests are prebooked if attribute is present
       
    • Submission before the end of the current activity (for instance at work)
    • Duration configurable per activity in the agent plan
    • This strategy is dynamic (prebooked requests are sent during simulation)

 

 

1

2

3

Caveats  /  Request canceling

  • Approach so far works well for single-trip simulations (each agent is one DRT trip)
     
  • Full MATSim simulations are based on agent plans and delays can accumulate, leading to delays
     
  • Agents may have multiple prebooked requests (return trips), what happens if the first one is rejected?
     
  • Conclusion: Being able to cancel and unschedule requests even once they are scheduled goes hand-in-hand with prebooked requests.
     
  • Again, flexible interfaces have been provided. Default implementation: Wait for a configurable duration for customers, then abandon the request.

Additional topics  /  Rebalancing

  • Prebooking introduces idle times for the vehicles during the day. Especially, we may submit and schedule a request for some time very late in the day.
     
  • However, the relocation logic in MATSim is triggered when the vehicle arrives at the last task (which is always Idle).
     
  • Relocation should also be triggered for idle tasks along the schedule (but logic is slightly more complicated as the vehicle needs to drive to the next planned location on time)
     
  • Not yet implemented!

Additional topics  /  Alonso-Mora

  • As an alternative to the DRT insertion algorithm, we work with the algorithm proposed by Alonso-Mora et al. for a while now
     
  • Separate repository as it introduces "unconventional" dependencies (GLPK / CPLEX / Gurobi)
     
  • Prebooking is naturally supported by the AM algorithm (as well as late rejections and cancelations), but so far those features were a mere "hack". Now they are well-integrated.

matsim-org / alonso-mora

Next steps

  • Apply the functionality in large-scale scenarios (for Paris)
     
  • Question of interest: How do the results of a DRT simulation change with increasingly realistic choices?
    • Individual taxis (Hörl et al. 2019, for Paris)
    • Pooled taxis (use DRT)
    • With prebooking (use this contribution)
    • With intermodality (Tarek CHOUAKI's presentation at MUM 2024)

How to use this?

  • Already included in the MATSim
     
  • Can be activated via configuration
    • Attention: Comes with updated stop logic, etc.



       
  • By default, it does nothing. A prebooking logic that submits the requests in advance needs to be installed:
PrebookingParams prebookingParams = new PrebookingParams();
drtConfig.addParameterSet(prebookingParams);
ProbabilityBasedPrebookingLogic.install(controller, drtConfig, 0.5, 7200.0);

Prebooking probability

Prebooking slack

How to use this?

public class RunMelunPrebooking {
	static public void main(String[] args) throws ConfigurationException {
		// ...
	}
}
  • Runs all the simulations presented here from resources

Questions?

https://slides.com/sebastianhorl/abmtrans24

sebastian.horl@irt-systemx.fr