WO2020101474A1

WO2020101474A1 - A continuous journey scheduling system

Info

Publication number: WO2020101474A1
Application number: PCT/MY2019/050088
Authority: WO
Inventors: Nor Azura Binti ZAKARIA; Airul Azha Bin ABD. RAHMAN; Sharifah Binti SALEH
Original assignee: Mimos Berhad
Priority date: 2018-11-14
Filing date: 2019-11-12
Publication date: 2020-05-22

Abstract

A continuous journey scheduling system (100) is provided, the system (100) includes at least one database of traffic data (101) and resource data of traffic congestion factors (103), characterized by, a speed and space estimation module (105) in connection with the at least.one database of traffic data (101) and the resource data (103), including any or any combination of traffic complexity block (201), weather condition block (203), drive condition block (205), and speed and space estimation block (207); and a scheduling module (107) that provides users with a travel time slot and suggested route based on weightage of factors determined in the speed and space estimation module (105); wherein the scheduling module (107) groups users, and time slots are assigned to the groups of users based on weightage of factors to reduce traffic congestion by distributing the groups of users over different suggested routes and time slots.

Description

A CONTINUOUS JOURNEY SCHEDULING SYSTEM

Field of invention

'Hie invention relates to a continuous journey scheduling system based on traffic data and congestion factors and a mobile device comprising said system thereof. Background

Existing traffic monitoring systems are able to provide drivers with information on traffic conditions by checking on traffic routes using an application on a mobile device. However, if The user is on a highway, the alternative routes at that point are limited when the congestion is heavy, leaving the user with not much choice but to stay on the route with the congestion.

US20160335893 A1 provides a system for predicting travel time for a particular travel route and is able to calculate traffic congestion as well as integrate data from third party sources such as weather information and landslides. However, this solution only works for individual users who want to find a least congested route.

US82S5146 B2 describes a traffic management system that wirelessly tracks motorists that are required to travel at a specific tune on roadways during peak horn's. However, the system does not take other factors that affect congestion into account or provide any arrival time for the destination. Therefore, there is a need for a platform that manages traffic beyond individual users and efficiently reduces traffic congestion.

Summary of Invention

In an aspect of die invention, a continuous journey scheduling system is provided, the system includes at least one database of traffic data and resource data of traffic congestion factors, characterized by, a speed and space estimation module in connection with the at least one database of traffic data and the resource data, including any or any combination of traffic complexity block, weather condition block, drive condition block, and speed and space estimation block; a scheduling module that provides users with a travel time slot and suggested route based on weightage of factors determined in the speed and space estimation module, wherein the scheduling module groups users, and time slots are assigned to the groups of users based on weightage of factors to advantageously reduce traffic congestion by distributing the groups of users over different suggested routes and time slots.

In one embodiment, the traffic database is connected to a live monitoring module to receive locations of users. Typically, the resource database receives information from users through mobile applications.

Typically, tire traffic complexity block determines probabilities of traffic congestion which is used to assign weightage based on number of additional minutes it will take to reach the destination estimated by Global Positioning System, GPS. Advantageously, number of minutes is added to expected time of arrival depending on a number of probabilities, P(N) that is found to be true when determining weightage of traffic complexity factor, Wt that is derived from the traffic complexity block.

Typically, the weather condition block receives data from the traffic complexity block which is updated by the live monitoring module and advantageously, determines an additional weather factor weightage, WeF based on weather condition.

In one embodiment, the drive condition block receives data from the weather condition block and further assigns D values and V values based on type of distance associated to a driver and vehicle type. The type of distance tor 1) value is assigned based on transit probabilities, TP defined by number of transits and duration of each transit in estimating a travel plan which is advantageously added into the application before departure or during a trip. Typically, the speed and space estimation block receives data from the drive condition block and estimates time taken to destination based on D values, V values, weather condition and traffic complexity factor with a recommended time gap between vehicles.

Typically, the scheduling module provides a scheduling block to receive data from the speed and space estimation module to further advantageously provide user with a pre travel option and post travel option on an application.

Advantageously, the system is used to assign different routes for multiple groups of people intending to reach a particular destination on a single platform. In one embodiment, the system comprises a mobile application used to advantageously estimate time of arrival at destination.

In a further aspect of the invention, a mobile device comprising the continuous journey scheduling system is provided.

In one embodiment, the mobile device is located in a vehicle or integrated therewith.

Brief Descrintion of Drawings

It will be convenient to further describe the present invention with respect to the accompanying drawings dial illustrate possible arrangements of the invention. Other arrangements of the invention are possible, and consequently the particularity of the accompanying drawings is not to be understood as superseding the generality of the preceding description of the invention.

Figure l illustrates a main block diagram of a continuous journey scheduling system.

Figure 2 illustrates a detailed block diagram of a speed and space estimation module and a scheduling module.

Figure 3 illustrates a flow chart showing a weather condition block within the speed and space estimation module. Detailed Description

A continuous journey scheduling system (100) is described herein as seen in Figure 1. The system (100) includes at least one database of traffic data (101) and resource data of traffic congestion factors (103), a speed and space estimation module (105) in connection with (lie at least one database of traffic data (101 ) and the resource data (103). Figure 2 shows details of the speed and space estimation module (105), wherein the speed and space estimation module (105) includes any or any combination of a traffic complexity block (201), weather condition block (203), drive condition block (205), and speed and space estimation block (207). A scheduling module (107) that provides users with a travel time slot and suggested route based on weightage of factors that is determined in the speed and space estimation module (105), wherein the scheduling module (107) groups users, and time slots are assigned to the groups of users based on weightage of factors, to reduce traffic congestion by distributing the groups of users over different suggested routes and time slots.

The traffic database (101) as seen in Figure l is connected to a live monitoring module (109) that provides live traffic updates from users’ locations and a decoder (111) that provides said locations to the traffic database (101). The resource database (103) receives information from users through mobile applications. Example of data collection provided by the user application to be updated in the resource database (103) are number of cars on the road, driver information such as driver type (long distance or short distance) or vehicle type (heavy or light), travel points and routes. Further information such as traffic accident data and route compilation is further collected from the live monitoring module (109) and updated in the traffic database (101). The traffic complexity block (201) determines probabilities of traffic congestion which is used to assign weightage based on number of additional hours it will take to reach the destination. Table 1 shows a range of probabilities that may be determined for an example of traffic conditions by building a truth table to generate output to be fed into a next block.

For example if there is a traffic jam found within 0 to 10 km from the location of user, a traffic complexity factor of 001 is sent into Decoder Route I as seen in Figure 2. Weightage of traffic complexity factor, Wt Is derived from the traffic complexity block (201 ) and is used to adjust estimated time taken for travelling if additional time is required. If traffic congestion probabilities PI, P2, P3, P4, P5 and P6 are all found to be true, i.e. probability 1, that particular route is congested for up to 60 km and it is likely that the route cannot be taken for next 12 hours due to a major event that has caused the congestion. Conversely, if all probabilities PI, P2, P3, P4, P5 and P6 are found to have a false value, i.e. probability 0, this would be an ideal condition where the weightage, Wt to be added is 0 as no congestion is expected.

If either one- of PI, P2, P3, P4, P5 or P6 are found to have a probability value of 1 (true), an additional delay that is estimated by Global Positioning System, GPS is added to the expected time of arrival. The delay, typically a specific number of minutes, is added to expected time of arrival depending on the number of P(N) that is found to be true, wherein

P(N) is defined as the probabilities PI, P2, P3, P4, P5, P6 or more if necessary as described earlier and as seen in Table t. If 2 of the probabilities are found to be true, therefore the weightage, Wt is determined by the delay estimated by GPS in addition to the expected time of arrival. However, if mote than three of P(N) is true, the next probability of weightage based on weather conditions is evaluated. As an example, it can be assumed that if there are more than 3 points of traffic congestion, drivers have been affected by weather condition factors or some drivers who are not following a suggested route.

Figure 2 shows details of weather condition block (203) that receives data from the traffic complexity block (201) and determines an additional weightage based on weather condition. Table 2 shows a truth table for determining weather factor weightage.

^'fable 2 Weather Factor Weightage

Figure 3 shows a flowchart showing traffic weightage sent into the weather condition block (203) where specific weather conditions produce a particular weightage factor. For example, good weather produces weather factor weightage WeF4 that will be sent to decoder (21 1). Rainy weather may produce either one of Wel l or WeF2 depending on how heavy the rain is. Information, which is the output from the decoder (21 1 ) is then sent to the subsequent block which is the drive condition block (205). The weather condition is updated by the live monitoring module (109) and ties up with third party applications such as GPS and highway information applications where necessary.

The drive condition block (205) receives data from the weather condition block (203) and sends out processed data to the speed and space estimation block (207). Tables 3 and 4 show truth tables for types of drivers and types of vehicles.

Table 4 Type of Vehicle

As seen in Table 3, a D value is assigned based on the type of distance associated to a driver.

A corresponding decoder (213) bits are then generated. Type of distance for D value is assigned based on transit probabilities, TP. Transit probabilities, TP are generated from 0 to

2, which provides the probability of a driver making a transit stop during the course of the trip. 0 indicates a zero probability of a transit and 2 is the maximum number of transits in one trip up to 60 km. This transit plan is added into the application either before departure or during the trip, 'fhe probability is defined on the number of transits and duration of the transit. Each distance or route is classified to a user and the driver condition block (205) checks whether the vehicle is heavy or light. The user inputs this distance and vehicle information into the application before the trip. A V value is assigned based on the type of vehicle, if this is a heavy vehicle, then bits 00 are generated with V value of Hl/HO. For example, HI indicates a heavy car driver and HO indicates a non-heavy car driver. The D values and V values are programming settings that are used to set the conditions in the system (100). The V values and D values ate further to be used in the subsequent module, which will be described later. This data is collected from the user’s input into the application on the mobile device.

Figure 2 further shows speed and space estimation block (207) that receives data from the drive condition block (205). Table 5 shows a space and factorial decoder calculation performed by final factorial decoder (215) for vehicles from B50 cc to IQOOcc between a speed range of 56km/h to 89 km/h. Table 6 shows a space and factorial decoder calculation performed by final factorial decoder (215) for vehicles from 1500 cc or higher between a speed range of 89 km/h to 121 km/h. Users adhering to the rules as laid out by the truth table will be able to accurately estimate time taken to reach destination.

Factorial decoder calculation is done using AND operation on the input values of Wt, D

Value, and V Value. The usage of the AND operation indicates that each of the input values are to be considered in conjunction with each other when calculating a final weightage factor..For example, Wt values are determined by the traffic condition and are further used to calculate delay in minutes. The D values indicate the driver’s travel condition which are long distance, medium distance, half medium distance and short distance group. Based on these D values.the transit minutes can be determined either during trip in progress or if the information is input into the system (100) prior to the trip.. V Values are used to refer to the appropriate truth table as seen in Table 5, Table 6 and Table 7 which is in accordance to type of vehicle. Users are provided with a spacing rule as seen in the tables that they should be ideally obeyed to avoid congestion.

For each scenario which is dependent on the D values and V values from the earlier blocks. the gap between vehicles is provided in order for the estimated duration to be accurate. Additional weightage factors are as described in the preceding blocks. For example, when there is heavy rain, the recommended time gap from one vehicle to another is 3 + l seconds (4 s). The estimated time of arrival will be based on number of minutes to be added from the weightage, Wt() estimation from traffic complexity block (201) and a transit duration calculated from drive condition block (205). The transit minutes will be also included since the original estimation of arrival may change if there are additional transits made by the driver during the trip.

Table 5 Space and Factorial Decoder Calculation for Vehicle Type l

Table 6 Space and Factorial Decoder Calculation for Vehicle Type 2

Similarly, Table 7 is a truth table shows a space and factorial decoder calculation drawn up for heavy vehicles with a speed of 56 km/h to 89 km/h. These tables provide an estimation of time of arrival based on weightage from all the blocks within this speed and space estimation module (105). Tie speed and space estimation block (207) receives data from the drive condition block (205) and estimates time taken to destination based on D values, V values, weather condition and traffic complexity factor with a recommended time gap between vehicles, i.e the time taken for a current vehicle to reach the position of the vehicle in front of the current vehicle.

Table 7 Space and Factorial Decoder Calculation for Vehicle Type 3

Figure 2 also shows details of the scheduling module (107) that provides a seheduling block (217) to receive data from the speed and space estimation module (105). The scheduling block (217) is able to estimate a worst, typical and best estimate of traffic congestion and reschedule a journey based on change in factors. User is able to view this pre travel option (218) and post travel option (219) on an application on their mobile device. Data from the scheduling module (107) is sent to the user through the application on the mobile device. It is to be understood that this mobile device may be a mobile phone and may be fitted within a vehicle. The scheduling module (107) groups and time slots are assigned to the groups of users, based on weightage of factors to reduce traffic congestion by distributing the groups of users over different suggested routes and time slots. The system as described above may be used to assign different routes for multiple groups of people intending to reach a particular destination on a single platform. A mobile device such as a mobile phone comprises the continuous journey scheduling system (100) as described above. ^"lire mobile device is located in a vehicle or integrated therewith wherein it can be fixedly mounted within the vehicle or used as a detachable device.

It is further to be appreciated that various other blocks may also be integrated for additional features such as earthquake occurrence, number of emergency vehicles on the road, air pollution index, landslide occurrence and other third party information that will be useful for estimation of traffic congestion. The system and mobile device are able to provide the user with an estimation of time of arrival at destination if the user uses the suggested routes and keeps to the suggested speed and space between vehicles.

Claims

1. A continuous journey schedul ing system ( 100), the system ( 100) includes:

at least one database of traffic data (101) and resource data of traffic congestion factors (103),

characterized by.

a speed and space estimation module (105) in connection with the at least one database of traffic data (101) and the resource data (103), including any or any combination of traffic complexity block (201), weather condition block (203), drive condition block (205), and speed and space estimation block (207); and

a scheduling module (107) that provides users with a travel time slot and suggested route based on weightage of factors determined in the speed and space estimation module (105);

wherein the scheduling module (107) groups users, and time slots are assigned to the groups of users based on weightage of factors to reduce traffic congestion by distributing the groups of users over different suggested routes and time slots.

2. The system (100) as claimed in claim 1, wherein the traffic database (101) is connected to a live monitoring module (109) to receive locations of users.

3. The system (100) as claimed in claim 1, wherein the traffic complexity block (201) determines probabilities of traffic congestion which is used to assign weightage based on number of additional minutes it will take to reach the destination estimated by Global Positioning System, GPS.

4. The system (100) as claimed in claim 3, wherein number of minutes is added to expected time of arrival depending on a number of probabilities, P(N) that is found to be true when determining weightage of traffic complexity factor, Wt that is derived from the traffic complexity block (201 ).

5, The system (100) as claimed in claim 1, wherein the weather condition block (203) receives data from the traffic complexity block (201) which is updated by the live monitoring module (109) and determines an additional weather factor weightage,

WcF based on weather condition.

6. The system (100) as claimed in claim 1, wherein the drive condition block (205) receives data from the weather condition block (203) and further assigns D values and V values based on type of distance associated to a driver and vehicle type.

7. The system (100) as claimed in claim 6, wherein the type of distance for D value is assigned based on transit probabilities, TP defined by number of transits and duration of each transit in estimating a travel plan which is added into an application before departure or during a trip.

8. The system (100) as claimed in claim 1, wherein the speed and space estimation block (207) receives data from the drive condition block (205) and estimates time taken to destination based on D values, V values, weather condition and traffic complexity factor with a recommended time gap between vehicles.

9. 'Che system (100) as claimed in claim 1, wherein die scheduling module (107) provides a scheduling block (217) to receive data from the speed and space estimation module (105) to further provide user with a pro travel option (218) and post travel option (219) on the application.

10. The system (100) as claimed in claim 1, wherein the system (100) is used to assign different routes for multiple groups of people intending to reach a particular destination on a single platform.

1 1. The system (100) as claimed in claim l, comprising a mobile application used to estimate time of arrival at destination.

12. A mobile device comprising the continuous journey scheduling system (100) according to claim 1.

13. The mobile device as claimed in claim 12, wherein the mobile device is located in a vehicle or integrated therewith.