Scheduling Rural DRT

Rural DRT schemes often see vehicles covering a large geographical area, and scheduling vehicles to carry as many passengers as possible is a challenging task.

Scheme designers face a stark choice:

• A simple booking process, where the user calls and is given an instant decision on whether they can be carried. This is simple for the provider and for the user, but seriously inefficient.

OR

• A more efficient system, where the schedule is built only when the provider can see the requirements of all users at once. The snag is that this is much more complicated for the user.

What's wrong with simple scheduling?

The problem with a simple, instant-booking, system is that your schedule is built up as the requests come in at the start of the booking period. This causes two problems:

• You will end up with wasted time, from gaps that are too short to allow extra trips. If the first booking that you take sees your bus arrive in town A at 10.00, and the next caller wants to leave A at 10.30, then the 30 minutes in between will probably be too short to allow any productive use of the vehicle.
• There will be a lot of “dead mileage”, where the bus travels empty to get to the next pickup point.
• You will end up with poor utilisation  - ie the average number of passengers carried at any time will be lower than you could achieve with a better-planned schedule. 
• If your first caller wants to travel from B to A at 0900, then that gets fixed in the schedule. If a later caller wants to travel from B to A at 1030, and the schedule allows it, you will end up making a second visit to B. Had you been able to look at the whole pattern of demand, you might have been able to make a single trip from B to A at 0945 and still accommodate the needs of both passengers.

• Potential users who don’t get through as one of the first few callers may not be able to fit times that have been set to satisfy those who got through first:
• The schedule may not see the bus going near their community on the day they need to travel
• The bus may be going near them, but at a time that doesn’t fit with their needs
• The bus may be going near, and at a suitable time, but the schedule that has been fixed doesn’t allow a detour to reach them

Here is a simplified example of a Rural DRT area centred for Town A, serving the surrounding area including villages/hamlets B, C, D, E

The first caller books a trip from C to A, arriving for 0930.  They are going shopping and this time suits them nicely (although they could go at a different time without much inconvenience). They get just the trip they requested.

The second caller books a trip from B to A, arriving for 0800 – they are catching a bus from A to city E at 0815. They too hit lucky, and get exactly the trip they request.

The third caller wants trip from D to A to arrive at 1000, so they ask to arrive for 0945 but are told that this will not fit with the schedule, so the caller accepts the need to arrive in A 45 minutes earlier.

The fourth caller lives in E, and wants to get to A for a job interview at 0900. They are told that the earliest that they could get a bus would be 0945, which would get to A at 1000. (The bus is idle between 0800 and 0820 in A, but that doesn’t give enough time to get out to E and back again). The caller cannot be offered a usable journey.

Creating a more efficient schedule

To avoid awkward time gaps - and to combine more users' needs into shared trip - requires a three-stage process, which makes for a much clumsier user experience, albeit that it means that more people get to be users!

• During a first phase, potential users are asked to give the details of their proposed journey. They would be committed to take a journey if offered, but won't know whether they will get an offer until the end of the "request" period. Information required for each trip:
• The earliest acceptable departure time for the outward trip
• The latest acceptable arrival time at the destination
  and for return journeys:

• The earliest acceptable departure on return trip
• The latest acceptable arrival back home
• The minimum acceptable time to spend at the destination
• The maximum acceptable time to spend at the destination

• Once the "request" period has closed, a least-bad schedule is constructed (either manually, or using some form of automated tool).
• Everyone is then contacted to tell them whether they can be accommodated by the schedule, and if so, at what time.
• Subsequent requests (made after the initial phase) are accepted where they can be accommodated within any “slack” built into the schedule so far, but are otherwise rejected.