GB2501075A - Dynamically demand-responsive transport - Google Patents

Abstract

A system for directing multiple passenger-carrying vehicles 102, 104, 106 retains planned vehicle routes 108, 110 and periodically queries the vehicles locations. It compares a travel request from a passenger 112 with the current location and route of one or more of the vehicles, adjusts the route to accommodate the request, and sends details of the revised route to the vehicle to replace its current route. Optimal routes may be calculated according to different departure or arrival times, pick-up or set-down points or fares. The passenger can chose a more convenient but more expensive vehicle (Fig.3) or one that is more convenient to the operator and less expensive (Fig.4). Each vehicle may include a location device (e.g. GPS or Smartphone) which reports current location and receives route information via wireless telephony (e.g. EDGE, 2.5G, 3G or 4G). Vehicle locations may be used to identify congestion for updating planned routes.

Description

Improvements in or relating to transport management

FIELD OF THE INVENTION

The present invention relates to the management of transport infrastructure and transport management.

BACKGROUND ART

Public transport is an important part of the transport infrastructure of a locality.

Without it, larger numbers of private vehicles would cause greater congestion, and those who were unable or unwilling to use a private vehicle would be unable to travel to places of employment, local amenities and services, and the like.

Public transport is however inherently inflexible and difficult to organise. Rail services require dedicated infrastructure to be laid down. Buses can run on most roads, but their routes must be decided in advance and published, along with their timetable, so that passengers can plan their journey. Great difficulty can sometimes be encountered by bus companies in coping with congestion, resulting in late running. Bus and rail routes and timetables will often be centrally planned and may bear only a general resemblance to the needs of individual passengers, resulting in passengers having to set off early in order to catch a suitable service and walk some distance to the nearest terminus or stopping point, thereby wasting time. Passengers may have to change services one or more times in order to complete their journey, creating further inefficiencies.

Taxi cabs offer an individualised service, departing at the time desired by a passenger and proceeding directly to their desired destination. However, their cost reflects this, and makes them non-viable as a routine measure for many passengers. Efforts have been made to allow for ad-hoc sharing of taxis, but it is rare for two passengers to be S departing from the same point at the same time towards a compatible destination, and for them both to know this.

SUMMARY OF THE INVENTION

An ideal public transport service would combine the flexibility of a taxi with the cost profile of a bus. The present invention closely approaches this, by providing a system that monitors a number of vehicles, compares an incoming travel request from a passenger with the current location and route of one or more of those vehicles, adjusts the route to accommodate the travel request, and communicates details of the vehicle to the passenger.

Ideally, the system compares the travel request with the locations and routes of a number of vehicles and offers a number of options to the passenger, which may involve different arrival times, different departure times, different pick-up points, different set-down points and/or different fares. The passenger can then choose to accept a vehicle that is more convenient for them but more expensive, or one that is more convenient to the operator and less expensive.

The vehicle can then collect the new passenger and continue its journey, with the route adjusted to take account of the desired destination of the passenger. Of course, further travel requests may arrive during the progress of that journey, and the route may be adjusted further in order to accommodate those. Thus, we prefer that the passenger is offered two arrival times, one that is the expected arrival time based on the currently-planned route of the vehicle, and one that is a promised arrival time and which includes some leeway to allow for further adjustments to the route. The promised arrival times for all passengers currently allocated to that vehicle are ideally recorded, and any later travel requests are checked for compliance with those promised arrival times before offering that vehicle to a later passenger.

The vehicles are preferably monitored by GPS or a similar system. The location of the vehicle can be fed back to passengers who are yet to be collected, to allow them to ensure that they are ready at the correct time. This will also mean that the system will have access to real-time information as to the road speeds and locations of the vehicles, i.e. the current traffic congestion situation. This information is preferably used to inform the routing decisions of the system, thus directing other vehicles away from the congestion and also S adjusting the departure and/or arrival times offered to new passengers.

The invention is embodied in a number of forms. First, there is the central device which accepts incoming travel requests, calculates routes for the vehicles involved, and advises the drivers of their routes and the passengers of their transport arrangements.

Second, there is a display for the driver advising them of the route to take, and where to collect and set down passengers. Finally, there is the interface with the passengers, to accept incoming travel requests and advise them of their travel options, where to be collected from, and the current progress of the vehicle that will be collecting them.

The driver's display may be in the form of a suitably programmed hand-held device, such as a smartphone or tablet device. Such devices often have integrated GPS receivers which can be interrogated, to report back to the central device as to the current location of the vehicle. Alternatively, a dedicated device could be developed.

The interface with the passenger could be by way of a web interface or a smartphone app, for example. The servers could be physical servers installed at a suitable location, or virtual servers provided by a cloud-computing or other suitable network.

The vehicles can be any suitable vehicle, such as a car, taxi, minicab, minibus, bus, coach, rickshaw or other vehicle capable of carrying passengers. The fleet may comprise a number of different types of vehicle.

Such a system is defined in the claims appended hereto.

BRIEF DESCRIPTION OF THE DRAWINGS

An embodiment of the present invention will now be described by way of example, with reference to the accompanying figures in which; Figure 1 shows a flowchart of the system operation; and Figures 2, 3 and 4 show the real-time adjustment of routes for alternative service preferences.

DETAILED DESCRIPTION OF THE EMBODIMENTS

We make use of onboard satellite navigation (SatNav) devices with 3G data connectivity to establish communications between a central server and the vehicle fleet.

Incoming travel requests are processed in real time. The system selects the best vehicle for each request, based on current course and available capacity, and calculates its new route.

Each vehicle is dynamically re-routed to pick up and drop off different passengers at specific locations as requested.

1. Making a travel request When making a travel request, the passenger notifies the central server of the pick-up location and destination, as well as any special needs such as luggage room or disability access. They may specify a pick-up time if they do not require immediate service. The system then performs relevant calculations and informs the passenger about the available service preferences, the arrival time guarantee, estimated arrival time and the estimated fare. The passenger then decides whether or not to confirm the request.

There are several different ways available for requesting our service, the first being the use of a smartphone application. Requests can also be made through a website. The interface on these two platforms features an interactive map, allowing customers to easily specify their start and end point. The smartphone application offers an additional feature that detects the passenger's current location automatically as the pick-up location with the in-built GPS functionality. For people who have no immediate access to a smartphone or a personal computer, a telephone number can be provided in order to allow the passenger to specify their request over the phone verbally, in a way similar to conventional taxi services.

As an alternative, kiosks could be installed at strategically chosen locations, featuring touch screen panels that replicate the website and app functionality.

2. Arrival time guarantee Since the routes of vehicles are constantly being updated to accommodate new passengers, they would not know in advance exactly how their assigned vehicles would bring them to their destinations. However, most people do not mind the route as long as they arrive within an acceptable time. Hence we offer passengers an arrival time guarantee.

This guaranteed time takes into account both the waiting time and the trip duration, and is a multiple of the base time', which is the shortest possible trip duration without traffic or S diversion. The value of this multiple depends on the service preference considered. The guaranteed time is presented to the passenger each time before they confirm the trip so as to help them better decide whether or not to use our service. In the unfortunate event that the guarantee is not met, their fare will be discounted in relation to the amount of delay.

We also provide passengers with the estimated arrival time', which is calculated from past statistics of how long trips of similar nature would take. This serves as a useful reference for the passengers but will only be available after some time into operation after sufficient data is gathered.

3. Process Flow Chart Figure 1 provides an overview of the typical process of how a travel request will be handled. A passenger makes a travel request (step 10) by appropriate interaction with a web interface, a smartphone app, or a telephone call to a customer service agent. This request is passed to a server (step 12) running a program which prompts the server to search (step 14) for vehicles which have a generally similar course or direction. This search can be by any suitable algorithm, for example by looking for vehicles which have at least one spare seat and which meet some or all of the following criteria: -a planned route which takes the vehicle within a preset distance of the requested start point -a planned route which takes the vehicle within a preset distance of the requested end point -a vehicle on standby within a preset distance of the requested start point If a large number of vehicles meet the chosen criterion/criteria, then the preset distances can be reduced or the vehicles can be ranked according to how closely they meet the criterion or the combined criteria (if more than one). If no or few vehicles meet the chosen criterion/criteria, then the preset distances can be increased.

For the vehicles on this shortlist, a new proposed route is calculated (step 16) which includes all the existing start and end points that have been allocated to the vehicle, plus the new start and end points for the new passenger. This will affect the arrival time for the vehicle at all subsequent waypoints, so a first check is made to ensure that the arrival time S guarantee made to all of the passengers who are already booked onto the vehicle in question can still be met. Any vehicles for which this is not the case are ruled out, step 18.

If this applies to all the vehicles on the shortlist, i.e. there are no vehicles that can provide the journey and still meet previously made promises, then the passenger is notified that their request cannot be met (step 20).

Assuming that one or more vehicles are left, routes are selected which best match the service preferences (see below) with the minimum diversion (step 22). The details of the collection points, waiting times, expected arrival times and arrival time guarantee for each of the service preferences which can be accommodated are then sent to the passenger via the web interface or smartphone app as applicable, and the passenger is invited to choose (step 24). On receipt of a valid passenger choice, the route for the relevant vehicle is adjusted and fresh instructions are sent to the driver's satellite navigation device (step 28) together with details of the passenger and a pass-phrase. The same pass-phrase is sent to the passenger (step 30) along with confirmation that the trip is booked.

The web interface or the smartphone app then allow the passenger to monitor the progress of the vehicle towards the collection point. This allows the passenger to time their departure for the collection point, thus making best use of their time and ensuring they arrive at the collection point at the right time (step 32). Once the vehicle arrives, the driver can ask the passenger for the pass-phrase (step 34), to ensure that they are collecting the right passenger. This allows for the use of standard collection points at which multiple vehicles may be stopping within a short space of time. The passenger provides the correct pass-phrase (step 36) and is allowed onto the vehicle. The driver then confirms collection (step 38) and continues en route.

The driver may stop on the way to that passenger's destination in order to collect and/or drop off other passengers, guided by the in-vehicle satellite navigation system supplied with routing instructions by the system server. Once the driver arrives at that passenger's destination, the passenger is allowed to alight (step 40) once payment has been dealt with. If the passenger has an account then this is debited automatically (step 42). If the passenger does not have an account then the driver is advised of the appropriate amount to collect (step 44). The passenger will have been advised of this amount when choosing the service preference; any discounts for late arrival can be deducted from the S amount automatically according to preset rules.

4. Service preferences According to the invention, three service preference options are available, namely Normal', Saver' and Express'. From the passenger's perspective, they differ in the arrival time guarantee, precision of the drop-off location, and most importantly, the fare. A summary of the three service preferences is listed below: Guaranteed/base Approx waiting time Maximum walking distance to time ratio (mm) destination (m) Normal 2.5 10 150 Saver 2.5 10 650 Express 1.5 5 150 Table 1.6 The three service preference options The Express option guarantees a 4O% faster arrive time, and the estimated waiting time will be half of the other options. The Saver option, on the other hand, gives the system a bigger flexibility to decide the drop-off location for that particular request if needed.

A greater or smaller number of service preference options could be provided if desired. A greater number will allow the service to be more individually tailored to a passenger and more responsive to their needs, at the expense of greater processing demands and (potentially) more complexity for passengers. Equally, different parameters could be chosen according to the operator's preference, if a different structure of service preference options was felt to be appropriate.

5. Selecting vehicle and routing solutions After a travelling request is received, a pool of vehicles with a similar courses of direction as the requested trip are shortlisted. For each chosen vehicle, the system computes an optimal route to accommodate the new passenger along with those already S on-board, whilst taking available real-time traffic information into account. Real-time traffic information is available from a number of external sources, and also from the current progress of the GPS-equipped vehicles forming the fleet (see later). The system then checks each generated routing solution if a service guarantee is met, and discards those which fail.

From the remaining solutions, the one requiring the smallest diversion from the original route will be selected.

As different service preferences have different arrival time and drop off precision guarantees, a solution will be separately chosen for each of the Normal, Saver and Express options. Note that the solutions may or may not involve the same vehicle. Occasionally some service preferences may not be available as no vehicles can meet the guarantees at that instance. Available preferences will then be presented to the passenger. The vehicle corresponding to the passenger's final chosen option will be updated with the new route.

6. Collection points and Drop-off location precision The invention aims to provide a transport service that can reach pick-up and drop-off locations at a level of precision comparable to taxis. However, total geographical precision would not be practical since that would result in a possible situation where a vehicle has to stop at every few metres on one street to pick up or drop off passengers. Our solution is to define collection points to cluster passengers' pick-up and drop-off locations. These collection points are similar to conventional bus stops, however they are virtual and have a much denser distribution. They will be at most 300m apart so that walking distance is kept reasonably short.

Passengers will be notified of the exact location they are going to be picked up from after the request confirmation. The actual pick-up and drop-off locations will be the collection point closest to the requested locations, unless the Saver preference is chosen. In this case, the drop-off point will be subject to any further diversion to accommodate new passengers during the journey, with a maximum walking distance being capped at 650m.

This and the selecting vehicle and routing solutions are shown in figures 2, 3 and 4.

Figure 2 shows the routing pattern for two vehicles being controlled according to the invention. A road network 100, indicated with solid lines, is programmed into the system in a generally known manner for routing software. Three vehicles are currently available, a S first vehicle 102, a second vehicle 104, and a third vehicle 106. In practice, there will of course usually be more than two vehicles in use, but these suffice for explanatory purposes.

The first vehicle 102 has a pre-planned route 108 which it is following for the benefit of at least one other passenger who is currently on-board. Likewise, the second vehicle has a pre-planned route 110. This third vehicle is currently stationary with no allocated passengers or routes.

A new passenger 112 makes a request for a journey from their current location to a destination 114. Neither the current location nor the destination co-incide with either of the pre-planned routes 108, 110. The third vehicle 106 is relatively close to the passenger and is available, so an obvious solution is to send this vehicle to the passenger 112 to take them direct to the destination. This corresponds of course to a normal taxi system. However, this solution is also the most inefficient, as it uses the maximum number of vehicles, and the most expensive, as it requires all three vehicles to be running and hence consuming fuel, emitting pollution and causing congestion.

The system calculates a range of possible diversions (or journeys, for the third vehicle 106) for each vehicle in order to determine the best option for each service preference. Clearly, all of the possible diversions for the second vehicle 104 will be more involved and lengthy given that its ultimate destination is in the opposite direction to that desired by the passenger 112. We can therefore discount this vehicle.

The third vehicle has an obvious route proceeding directly to a location close to the passenger and then directly to the destination. As noted above, however, this is also the most expensive and inefficient solution. It does however offer the earliest arrival time, as the passenger does not need to wait for the first vehicle 102 to arrive. This will therefore give both the shortest waiting time and the shortest walking distance for the passenger, and is thus likely to form the "express" service preference.

The first vehicle 102 could divert as shown in figure 3 towards a collection point A close to the passenger 112, and then divert along road 116 to reach the destination 114. A short walk 118 to the collection point A is all that would be required for the passenger, and they would be delivered direct to the destination 114. The passenger 112 would however have to wait for the first vehicle 102 to arrive. This option will therefore give a slightly longer waiting time, but retain the shortest walking distance for the passenger, and is thus S likely to form the "normal" service preference.

A third option is also apparent, as shown in figure 4. This requires no diversion for the first vehicle 102 but requires the passenger 112 to walk a distance along a walking route to an alternative collection point A' which is already on the pre-planned route of the first vehicle 102. It also requires the passenger 112 to walk from a drop-off point B', which is likewise on the pre-planned route of the first vehicle 102, along a second walking route 122 to the final destination 114. Thus, this route offers the greatest waiting time and walking distance for the passenger 112, but allows the minimum diversion for the vehicle. This minimises the cost of the journey for the operator, having a minimal marginal cost related only to two additional halts, and also minimises the diversion and hence the delay for other passengers. Thus, this option can be offered at the lowest cost and is likely to form the "saver" option.

If, for example, the first vehicle 102 already has a number of passengers and is unable to accommodate the diversion of figure 3 without breaching the arrival time guarantees for one or more of those passengers, then that may mean the "normal" service preference is unavailable and the passenger 112 will be offered only the "express" or "saver" options.

Alternatively, if the third vehicle 106 is not available for some reason, then the passenger 112 will be offered only the "normal" or "saver" options.

7. Obtaining real-time traffic information The system constantly monitors the locations of vehicles by communicating with their onboard SatNav devices via the 3G network or any other mobile internet network that may be available. Each vehicle is thus acting as a traffic flow sensor, so the entire network can be used to obtain accurate information on the real-time traffic condition in the city. This assists our system to direct our vehicles away from congested roads, improving our service reliability and easing city traffic congestion.

8. In-app vehicle monitoring Once a travel request has been confirmed, the passenger can use the smartphone application to check the position of the assigned vehicle while they wait. This allows passengers to more effectively manage their time.

9. Boarding pass-phrase To ensure that passengers are boarding the correct vehicles at a popular location, the registration number or other official number of the assigned vehicle and a pass-phrase will be supplied via an SMS text or via the app once the request has been confirmed. The driver will prompt the passenger for the pass-phrase when the vehicle has arrived. If the response matches with what is displayed on the driver's SatNav device, the passenger will be allowed to board. The driver then confirms the pick-up with our server through their device.

10. Payment and online account Users can set up a personal account online to enjoy the convenience of automatic fare payment. Credits can be added to the account through available online payment methods. Passengers who are not registered or have insufficient account balance will have to pay the fare in cash to the driver at drop-off. The fare to be collected will be displayed on the driver's SatNav screen to avoid mistakes.

Registered users will have access to other features such as scheduling regular travel requests, as well as viewing travel history. This is particularly helpful to users who want to use the service regularly, such as those commuting to work daily. It allows the server to optimise the route matching with other regular commuters well in advance so that a highly consistent journey time can be provided.

As the main modes of request are via the internet (i.e. the smartphone application or web browser), this allows users to communicate with our servers automatically without the need of human inputs. This means it is economically viable to handle enough requests to match the volume of local bus systems, even operating in real time so as to provide substantially immediate responses to passenger requests.

It will of course be understood that many variations may be made to the above-described embodiment without departing from the scope of the present invention.

Claims (11)

1. CLAIMS1. A system for directing a plurality of passenger-carrying vehicles, comprising; a processor a set of program instructions for the processor, and S a network interface able to accept incoming travel requests from passengers and to communicate with the plurality of passenger-carrying vehicles wherein the set of program instructions are arranged to direct the processor to; i. for each vehicle of the plurality, retain a planned route allocated to that vehicle H. periodically, query each vehicle as to its location iH. accept an incoming travel request from a passenger via the network interface, the travel request including a departure location and an arrival location and at least one of a departure time and an arrival time, and iv. for at least one vehicle of the plurality, calculating at least one revised route taking onto account the departure location, the arrival location and the departure or arrival time, and v. sending details of the revised route to the vehicle and replacing the planned route for that vehicle with the revised route.
2. 2. A system according to claim 1 in which at least one revised route is calculated for several vehicles of the plurality and an optimal route is selected according to preset criteria.
3. 3. A system according to claim 1 or claim 2 in which; a plurality of preset criteria are retained by the system, an optimal route is selected for each criteria, details relating to each of the plurality of optimal routes are transmitted to the passenger by way of the network interface, and the processor is arranged to adopt as the revised route the optimal route of the plurality selected by the passenger.
4. 4. A system according to any one of the preceding claims in which each vehicle has a location-determining device able to communicate with the processor via the network interface.
5. 5. A system according to claim 4 in which the location-determining device is a GPS device.
6. 6. A system according to claim 4 or claim 5 in which the location-determining devices communicate with the processor to report the current vehicle location and to receive route information.
7. 7. A system according to any one of claims 4 to 6 in which the location-determining devices are smartphones.
8. 8. A system according to any one of the preceding claims in which the network interface comprises a wireless telephony system.
9. 9. A system according to claim 8 in which the wireless telephony system is one of an EDGE, 2.5G, 3G or 4G systems.
10. 10. A system according to any one of the preceding claims in which the processor uses the locations of vehicles to identify congestion and updates the planned routes accordingly.
11. 11. A system for directing a plurality of passenger-carrying vehicles substantially as described herein with reference to and/or as illustrated in the accompanying figures.