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)

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

Evaluating prebooked on-demand mobility services using MATSim

More from Sebastian Hörl