KR20150100619A - Determining real-time delay of transportation means - Google Patents

Abstract

The delay of the scheduled transportation means that travels along the route is determined according to the timetable. The path includes at least one section. Determining the delay is based on a detailed reference schedule that represents any timestamped reference positions of the vehicle traveling on time. A request for a real-time delay of the vehicle is received by the user device located in the vehicle. The request indicates at least the current location of the means of transport. The delay of the vehicle is calculated based on the current location indicated in the request, the timestamp, and the corresponding timestamped reference location of the detailed reference schedule. The calculated delay is returned to the user device. The calculated delay is stored in the logbook. In response to the request not indicating the current location of the vehicle, the delay is returned based on the logbook.

Description

DETERMINING REAL-TIME DELAY OF TRANSPORTATION MEANS

The present invention relates generally to the delayed determination of a scheduled vehicle. More particularly, it is intended to provide real-time delay information for the vehicle to passengers carrying the mobile user device.

The travel time of a vehicle traveling along a predetermined route is one of the basic information for most passengers. When traveling on public transport such as trains, buses, boats, aircraft or trams, passengers often want to know the exact travel time, departure time and arrival time of the vehicle. For this reason, a formal timetable for each public transport is provided to the passengers on the web, for example by the operator. In general, these official timetables include planned departure and arrival times for all stations within a given route. However, transportation can be delayed due to unexpected factors (eg, harsh weather, traffic conditions, etc.). As a result, the timetables may not reflect the actual progression of the means of transport.

JP 06044495 A discloses a method for providing delay information to passengers on a local train or bus. This describes an arrival time display device having a position measurement device such as a GPS device. The arrival delay time and the early arrival time of the train or bus are calculated by using a time difference calculation part included in the arrival time display device to calculate the time difference between the scheduled arrival time and the current time .

According to the present invention, a method is provided for determining a real-time delay of a scheduled vehicle traveling along a route by a timetable. The path includes at least one leg. Determining the real-time delay is based on a detailed reference schedule that represents any time-stamped reference locations of the vehicle on which it is on time. This method includes location based decision and time based decision. Location-based judgment

(i) receiving, by a user device located in the vehicle, a request for real-time delay of the vehicle, indicative of at least the current location of the vehicle;

(ii) calculating a real time delay of the transportation means based on the requested current position, the time stamp, and the corresponding timestamped reference position of the detailed reference schedule;

(iii) returning the calculated real-time delay to the requesting user device; And

(iv) storing the calculated real-time delay in a logbook.

The time-based determination includes returning a real-time delay based on a logbook containing real-time delayed entries for the vehicle in response to a request by a different or identical user device that does not indicate the current location of the vehicle.

According to another aspect, a computer system is provided for determining a real-time delay of a scheduled vehicle as described above.

According to another aspect, there is provided a non-transitory computer readable storage medium having computer program instructions stored thereon, which, when executed on a computer system, performs the method as described above.

According to another aspect, there is provided a computer program that, when executed on a computer system, causes the computer to perform the method as described above.

Further aspects are configured in the dependent claims.

BRIEF DESCRIPTION OF THE DRAWINGS The invention will be described with reference to the accompanying drawings. Like numbers refer generally to like or functionally similar elements.
1 is a flow chart showing the principles of the present delay judgment.
2 is a more detailed flowchart according to an example of the present delay judgment.
FIG. 3 illustrates a passenger name record (PNR) database utilized in an example of the present delay judgment.
Figure 4 is an exemplary timetable for scheduled vehicles.
5 is an exemplary detailed reference schedule that may be employed in the present delay determination.
FIG. 6 is an example of a calculation illustrating a reference time calculation using linear interpolation.
7 is an exemplary motion curve of the vehicle;
8 is an exemplary logbook that may be employed in this delay determination.
9A, 9B and 9C are detailed flowcharts showing user device and server side procedures according to an embodiment of the present delay judgment.
10 is an architecture of an exemplary system deployed to perform the delay determination.
11 and 12 are graphical user interfaces of a user device executing an application that performs the determination of the delay.
13 is an exemplary schematic diagram of an internal architecture of a user device;

Before starting the detailed description with reference to Figs. 2 to 13, some general aspects will be described first based on Fig.

The present invention relates generally to scheduled scheduled transporters that move regularly according to a specific timetable. Such scheduled vehicles may be, for example, trains, buses, shuttle cars, airplanes, boats or ferries, trams or other public transport means (such as international, high speed, domestic, local or suburban trains).

Timetables are usually created and issued by the operator of the vehicle. For example, SCNF generates and issues timetables for all TGVs in service in France, while Deutsche Bahn generates and issues timetables for ICEs operating in Germany. Operators make these timetables available to the public, and in particular to the passengers in the station or vehicle itself, via the Internet. The timetables of the means of transport usually indicate the starting and final destination of the means of transport as well as the intermediate stations. Moreover, timetables usually indicate departure times at intermediate stations and, optionally, arrival times as well as departure times at the departure station and arrival times at the final destination.

Thus, the operators' timetables logically group scheduled transportation means by their route and travel time. The means of transport going on the same route at the same time are hereinafter referred to as means of transport belonging to a particular "connection. &Quot; For example, every train that runs from Nice to Paris at 10:00 every day forms a line like this. On the other hand, the term "route " refers to the scheduled way of transportation according to the timetable from the starting station to the final destination. For example, in the case of trains belonging to the above-mentioned routes (for example, TGV for Nice-Val-Paris at 10:00 daily), this route is given by the rail tracks between Nice and Paris. Furthermore, in general, the route of the scheduled transportation means consists of legs. In the following, the term "interval" refers to a portion of the path between two consecutive stations listed in the timetable. Exceptionally, if the timetable does not prescribe any intermediate stops between the departing station and the final destination, one path consists of one section. However, a normal path is divided into a plurality of intervals. For example, if the timetable represents six intermediate stops between the departure station and the final destination, the route is subdivided into seven segments.

Normally, passengers are interested in the planned arrival and departure times of the means of transport set by the operator's timetable, as well as the actual progress of the particular means of transport they intend to use or are currently using. For example, it may be beneficial for passengers to have knowledge of whether their means of transportation is now perfectly on time, later than schedule, or earlier than scheduled, in order to minimize waiting times or select suitable con- junction vehicles Do. In this regard, the term "delay" is used herein to cover all three of these possibilities. The delay is positive if the vehicle is later than the schedule and arrives at the next station, perhaps later than indicated by the timetable. If the vehicle is on time and arrives at the next station at the time indicated by the timetable, the delay is zero. If the vehicle is faster than the schedule and arrives at the next station earlier than indicated by the timetable, the delay is negative.

User devices adapted to calculate the current delay of a vehicle to address this need are known in the prior art. An example is JP06044495A already mentioned above. However, the delay calculations disclosed herein require, for example, a Global Positioning System (GPS) to manually input the destination information and provision for the current location of the user. Therefore, this system does not work properly in situations where GPS coverage is poor or does not exist. In addition, the approach described in JP06044495A is based on a simple comparison of the scheduled arrival time, the current time, and the destination location and the current location. Obviously, a linear progression of the user vehicle is assumed. This is not related to the progress of the real world, which is usually nonlinear. Therefore, this approach proposed by JP06044495A is inherently inaccurate.

It is an object of the present invention to address such problems of the prior art. The delay information method / system presented here allows to provide real-time delay information to user devices in a situation where the location judgment function is not available or the location judgment is not possible. Moreover, this aims to improve the accuracy of the delay information.

On the other hand, this delay judgment is based on a more detailed reference schedule (4) than the timetables issued by the transport operators. As outlined above, these operator timetables simply include target times associated with the stops or stations of the vehicles. However, this information is presently perceived as insufficient because it does not provide any reference information for locations within intervals, e.g., between intermediate stations. One possibility of supplementing the operator timetables is to assume a linear progression of the vehicle between the intermediate stations and thus "populate " the timetables by linear interpolation. At the present time, a detailed reference schedule 4 aiming at more accurately reflecting the actual real-world progress of the transportation means that is in the middle between the intermediate stations is introduced. For this purpose, the detailed reference schedule 4 contains target time information for arbitrary positions in the route, as well as target time information at intermediate stations that can be taken in each operator timetable. In other words, the detailed reference schedule 4 not only indicates the arrival and departure times of the stations designated by the operator, but also includes additional time stamped reference positions of the vehicles, which are scheduled to run on time, , Stops, or stations. In a system arranged to operate in accordance with the delay judgment presented herein, there will be detailed reference schedule data for each route to be covered by this delay judgment. For example, referring back to the TGV example mentioned above, detailed baseline schedule data for daily TGVs from Nice to Paris departing Nice at 10:00 and detailed daily schedule data for daily TGVs from Nice to Paris departing Nice at noon There will be reference schedule data. There are several possibilities for establishing a detailed baseline schedule (4), which will be described below. One possibility is the so-called "social approach" whereby data from location-based requests related to on-time transport means are collected. This detailed reference schedule 4 permits a more precise determination of the delay of the vehicle due to the increased granularity of the reference data compared to a timetable based approach using only the scheduled stops as reference data .

On the other hand, the present delay determination method utilizes the logbook 5 in which real-time delay information about the inquired transportation means is collected. The logbook 5 is filled with the real-time delay information generated by the position-based delay judgment performed as follows (visualized by the left branch of FIG. 1).

The passenger in the vehicle is equipped with a mobile user device 1 such as a mobile phone, a smart phone, a laptop, a tablet computer, and the like. The user device 1 generates a request for a real-time delay of the vehicle. This request includes at least the current location of the user device 1 which is identical to the current location of the means of transport. Which may be issued to the server or alternatively may be processed locally at the user device 1 using a cache mechanism (this will be described in more detail below). This request is then received internally by the server or by the user device 1. The request is then processed to calculate the delay of the vehicle. Based on the current location indicated in the request and the time stamp associated with the request, the detailed reference schedule (4) is consulted and the time stamped reference locations for the on-time transport means, respectively, calculate the real- (Box 12 in Figure 1). Details of the delay calculation are described below. In box 8 of Figure 1, the resulting delay information is returned to the user device 1 (again, by the server or internally in the user device 1). In addition, the calculated delay information is logged and stored in the logbook 5.

The logbook 5 filled with the delay information obtained by the location-based determination facilitates a pure time-based determination (shown in the right branch of FIG. 1) that operates without any position determination by the user device 1. The user device 1 which is the same as or different from the user device which previously issued the location based request generates a time based request which does not include an indication of the current location of the user device 1 in contrast to the location based request. The reason for this is that the device does not have any position determination means and is equipped with only an inaccurate position determination means that is not sufficient for the purposes of the present delay judgment, or the lack of coverage, the free line of sight to satellites (e.g., lack of sight), remoteness from the means of transportation (e.g., a user interested in the home), etc., and the device 1 is not capable of determining the current location have. If the logbook associated with the user's transportation means can be determined based on this time-based request, the delay of the transportation means is determined based on the available real-time delay entries in the logbook 5 (Box 7 ) (Again, Box 8 of FIG. 1) to return delay information about the vehicle.

In this way, real-time delay information about the vehicle is displayed on the passenger's user device 1. The real-time delay information may include, for example, the scheduled arrival time to arrive at the reverse station, in particular the next station (the end point of the current section), the current time delay of the vehicle and the next station and / And may include the potential actual arrival of each of the final destinations.

As outlined above, both location-related requests and time-related requests are associated with timestamps. This timestamp is used to determine the interval in which the vehicle is expected to be located when the request is made and to calculate the real time delay. Basically, there are two ways to generate a timestamp. One possibility is to include the time stamp directly in the request by the user device 1. Thus, according to this option, the requests actually contain a timestamp. Another possibility is to generate a timestamp only when the request is received. This option is particularly useful when the request is processed centrally by the server (as opposed to locally processing the request at the user device 1 using the cache mechanism described below). Generating a timestamp on the server guarantees consistent time management because all requests are timestamped by one and the same server-side clock. Similar coherent time management is also possible when using the first option (i.e., including a timestamp in the request), i.e., when user devices 1 are synchronized with a trusted clock.

As already indicated above, there are several options for how to establish the detailed reference schedule (4) of the vehicle and to generate the arbitrarily timestamped reference positions needed. As already explained at the beginning of the above, these timestamped reference locations are "arbitrary" because they refer to certain locations on the path that are independent of stations or stops of the transportation means. One possibility to establish a detailed baseline schedule (4) is a so-called "social approach" that is independent of the coopertaion of transport operators. Thus, it can be employed to convey detailed data about the network and the timing conditions of their vehicles without having to rely on operators' good will. The social approach utilizes the actual location based requests issued by the user device (1) located on the vehicle. Since each of these requests provides the location of the vehicle and the associated time stamp (i.e., timestamp + location pair), they generally provide a valuable database. Since the entries of the detailed reference schedule 4 serve as reference time stamped locations, verification of the collected data is performed. From the total number of collected timestamps plus location pairs, these pairs belonging to the timely transportation means (i. E., Transportation means commensurate with the operator's timetable) are obtained and the remaining data collected from the non- The sets are discarded. This sorting can be performed by the operator viewing the time stamp + location pairs together with the locations near the stations that set the reference times. If the pairs with locations near the stations are coincident with the times specified by the operator's timetable, then each transport is considered on-time and all timestamp + location pairs collected on this transport are considered valid, These are included in the detailed reference schedule 4.

Further optional alternatives for establishing a detailed baseline schedule 4 are the artificial requests that may be generated by dedicated personnel on the vehicle and the simulation or provision of each data by the operator of the vehicle.

The logbook 5 is conventionally used in two ways in response to requests that did not indicate the current location of the vehicle (Box 7 in Figure 1). One method is simply to return the most recent real-time delay entry associated with the vehicle in the logbook 5 to the requesting user device 1. This option is particularly suitable if the most recent entry in the logbook 5 is current and therefore accurately reflects the current real time delay of the vehicle. The latest entry in the logbook 5 is the latest one, for example, by comparing the timestamp of the logbook entry with the timestamp associated with the request. If the difference between these two timestamps is less than or equal to a given threshold, e.g., 5 or 10 minutes, or is still within the current interval of the vehicle, then the accuracy of the last logbook entry is assumed, The delay information of the entry is returned. Another way to utilize the logbook 5 for requests that do not indicate the location of the current vehicle is extrapolation of logbook entries to determine the trend of the delay. (E.g., the difference between the timestamp of the last entry and the timestamp of the request is greater than the given threshold mentioned above), so that it is not very up-to-date and accurately reflects the actual real-time delay of the vehicle Extrapolation may be deemed to be appropriate. An extrapolation technique that may be suitably applied is exponential smoothing. The result of the extrapolation is returned to the user device 1.

Similarly, there are several options for performing real-time delay calculations (Box 12 of FIG. 1) in response to requests indicating the current location of the vehicle. For example, if the detailed reference schedule 4 includes a timestamped reference location corresponding to the current location of the vehicle indicated in the request, the reference time stamp associated with the location contained in the detailed reference schedule 4, It is sufficient to calculate the difference between the relevant timestamps. This difference between the two timestamps is the accurate real time delay of the vehicle and is returned to the user device 1 (box 8 in FIG. 1). On the other hand, if the detailed reference schedule 4 does not include a reference location corresponding to the location indicated in the request, there are two further options. One of them is that the detailed reference schedule 4 is searched for the closest reference position in the position indicated in the request and the reference timestamp 4 just related to the position contained in the detailed reference schedule 4, Lt; RTI ID = 0.0 > time stamp < / RTI > associated with the request. However, this introduces some inaccuracies that are substantial when the two locations (i.e., the locations contained in the detailed reference schedule 4 and the locations contained in the request) are more likely to differ from each other. In order to minimize this imprecision, linear interpolation techniques for time-stamped positions included in the detailed reference schedule 4 near the location indicated in the request may be employed.

It has already been briefly outlined above that there will be detailed baseline schedule data for each route and vehicle to be covered. Therefore, the correct transportation means or the detailed reference schedule data corresponding to each route must be deduced from the request of the user device. One option for making the association between the request and the vehicle / route / detail criteria schedule data is the identification code included in the request that allows identifying the vehicle. It is then possible to conclude with the correct timetable data, the appropriate data contained in the current section and the detailed reference schedule (4) (using the geographical location contained in the request). In one implementation, the identification code is a passenger reservation information (PNR) identifier that allows querying the PNR database for the traveler's travel schedule information. This travel schedule information may include information about routes of the vehicle currently in use by the passenger. Alternatively, an identification code other than the PNR identifier is included in the request. For example, the user device 1 can prompt the user to enter his / her current means of transportation and route, respectively, and passengers will then manually enter this information to be included in the request.

In an optional implementation, the location based determination comprises caching the detailed reference schedule (4) in the requesting user device (1). For example, the user device 1 sends its first location-based request for a particular vehicle to the delay judgment server. The server maintains a detailed reference schedule (4) containing data relating to the route of the vehicle currently in use by the passenger. The location based request of the user device 1 is processed by the delay judgment server as described above, and the calculated real time delay is returned to the user device 1. However, in an optional implementation using caching, the detailed reference schedule data belonging to the passenger ' s current transportation means may also be included in a separate message with or in combination with the real-time delay information, (1). The detailed reference schedule data is then buffered in the cache memory of the user device 1. As a result, successive location based requests by the same user device 1 can be processed locally in the user device 1 without having to send a location based request to the delay judgment server. In this way, the location-based delay calculation is enabled without requiring the user device 1 to activate an external communication link, and thus can be performed, for example, in regions without wireless coverage.

Due to the user device 1 without the wireless link, when the location based delay judgment is performed locally in the user device 1 using the cached detailed reference schedule 4, consequently, locally calculated real time delay information It can not be stored in the logbook 5 that can be held in the delay judgment server. If this happens, the locally computed real-time delay information will also be buffered locally in the local logbook at the user device 1. When the wireless link becomes available again, the user device 1 transmits the buffered real-time delay information to the delay judgment server, and this information is stored in the logbook 5 (server-side center).

The caching of the user device 1 is not limited to the detailed reference schedule data of the vehicle currently in use by the passenger. Rather, it can be usefully extended to other information. For example, more detailed reference schedule data potentially suitable for future transportation means that passengers, such as connection vehicles, may use may also be cached in the user device 1. More or all detailed reference schedule data that may be appropriate for future passengers may be stored in the user device 1 if it is reasonable in terms of the available buffer space of the user device 1 and the communication link bandwidth available to the user device 1. [ And stored therein for localized location-based delay determination. Furthermore, in response to the first location based request by the user device 1, the logbook 5 on the server side can also be delivered to the user device 1 and cached there. Even if this cached logbook is out of date and therefore less important if it has not been updated for a long time, it is possible for the time-based determination to be made locally at the user device 1 . The extent to which data is cached on the user device is a problem of the trade-off between the resources available for the user device (e.g., empty buffer space, the quality of the communication link) and potential improvements that can be achieved by the cached data to be.

The basic approach outlined above, i.e., collecting location based delay requests and their computation results and populating the logbook 5 with real-time delay information can be leveraged to more applications. For example, the information maintained by the logbook 5 may be used for display in the inverse, web sites or web services accessible via the Internet, push services such as RSS or SMS, Information distribution channels. Thus, other people who are not traveling using each vehicle can benefit from the present real-time lag determination mechanism regardless of their current location.

It is also within the scope of the approach presented here to supply messages to the real time delay system and the logbook 5 that are not necessarily directed to take information about the real time delay of the means of transport. Rather, these messages can neatly accomplish the purpose of informing the system about the current delay of the vehicle, without actually requesting a delay. For example, people like station personnel, real or potential travelers or other interested parties can send messages to delayed decision servers using, for example, GSM SMS, Delay. In response to such a message, the delay judgment server performs the verification of the information, and adds the delay indication to the logbook 5 when it is determined that the information is valid.

Turning now to the more detailed description, FIG. 2 shows a more specific example of the present real-time delay judgment. Similar to FIG. 1, the left-hand side of FIG. 2 illustrates the location-based delay determination while the right-hand side illustrates the time-based delay determination.

In the example of FIG. 2, the user device 1 is a smartphone arranged to have locally installed delay judgment applications and to generate delay judgment requests. It has a graphical user interface that is arranged to display information to the user and to allow input to the user when he or she wishes to initiate the delay judgment. It is also provided with a mobile communication interface using transceivers operating with other mobile communication standards such as 2G, 3G and / or 4G transceivers and / or WiFi IEEE 802.11. These communication interfaces facilitate mobile communication, in particular, the transmission of delay judgment requests and the reception of real-time delay information.

Furthermore, the user device 1 is equipped with a GPS receiver, so that it can determine its position if a communication link to GPS satellites can be established. If for some reason GPS is not available, the smartphone 1 may employ other position determination methods such as triangulation or Observed Time Difference techniques. When position determination is possible, the smartphone 1 starts position-based delay determination after each input command from the user. It determines its location and includes the geographic location of the result in the request. Furthermore, a time stamp indicating the current time is included in the request generated by the smartphone 1. [ Alternatively, as described above, the timestamp is not included in the request, but is taken from the side of the server for reasons of overall temporal consistency. Finally, a PNR identifier is included in the request. The user may be prompted to enter it or the PNR identifier may be automatically generated if each piece of information is locally available in the smartphone 1. When the smartphone 1 terminates the generation of the location based request, it transmits the generated request to the delay judgment server 47 via the appropriate mobile communication link (the server is not shown in FIG. 2, Will be described below with reference to FIG. 10).

After the request is received by the server, the geographical location and the PNR identifier included in the request are used to determine the current location of the vehicle (more precisely, the route of the vehicle) where the user is currently located and, more specifically, It is used to judge. For this purpose, the delay judgment server 47 is suitably combined with a travel information system such as the PNR database 2. [ A novel representation of the PNR database 2 is given by FIG. This includes travel schedule information of the user trip. The journey consists of several sections, such as flights from A to B and connecting trains from B to C. One of these intervals is formed by the current vehicle in which the user is located and the delay determination request is associated. Below, an example of train travel from B to C is referenced for illustrative purposes, and this example will not introduce any limitations with respect to the type of vehicle. Each identification information stored in the PNR database 2, that is, the ID of the train to which the user is to be boarded according to the itinerary for his / her trip from B to C, (See FIG. 3).

After having the train ID (e.g., "Tr1"), the server 47 may also refer to the correct timetable 3 of the available train operators. An example of the timetable 3 is given by FIG. The timetable includes the TrainID, StationID ("stID"), the geographic locations of the stations ("lat" represents latitude, "lng" represents longitude and degrees), arrival and departure times ("ArrTD" , "DepTD"). Thus, according to a very simple example of FIG. 4, the departure station of train Tr1 is St1 located at latitude 43.55 degrees and 7.02 degrees of latitude. The train is supposed to leave there at 7:30. The next stop is the middle station St2 located at latitude 43.59 degrees and longitude 7.12 degrees. The train arrives there at 7:38, eight minutes later, and leaves at 7:40 after two minutes of stopping. The final destination is station St3, which is located at a latitude of 43.70 degrees and a longitude of 7.28 degrees, which is scheduled to arrive at 8:01. In addition, the timetable 3 includes the distance information between the stations, that is, the length of the section (not shown in Fig. 4) as well as the geographical position information of the inverses. The purpose of querying the timetable (3) is to determine the section in which the means of transportation is currently located (ie, the next planned stop in accordance with the operator's timetable (3)). Thus, the geographical location contained in the request is passed as an argument of the query to the timetable (3), and the current section is retrieved. Thus, the process may include a geographical location (originally included in the request), a timestamp (set by the server when included in the request or upon receipt of the request), and a PNR database (2) and timetable (3) (Refer to < / RTI > reference).

The next step is the update of the detailed reference schedule 4 (box 10 of FIG. 2). As already described in detail above, the detailed reference schedule includes any timestamped reference positions, i.e., timestamp + location pairs, for the transportation means to be on time basis according to the operator's timetable (3). An example of the detailed reference schedule 4 is given by FIG. This includes trainID (e.g., Tr1, Tr2), legID, timestamp, and location (lat, lng). According to the example of Fig. 5, the train Tr1 is to be located at coordinates of 43.56 degrees in the latitude and 7.11 degrees in the longitude at 7:35, and 43.57 degrees in the latitude and 7.11 degrees in the longitude at 7:36. Such a collection of arbitrary timestamped reference positions forms a motion curve of the vehicle (see FIG. 7), which is more accurate when it includes more verified data.

As described above, one approach to establishing and enhancing the detailed baseline schedule table 4 is the so-called "social approach" in which actual location-based user requests are collected and stored in the table. The step 10 of updating the detailed reference schedule table 4 performs this purpose correctly. This step is generally optional since this step is not required if there is sufficient valid data already in the detail criteria schedule table 4. Update 10 means that a pair of geographic location and timestamp is added as reference data to the detailed reference schedule table. However, when this optional addition is performed, another process, that is, verification 11, is executed subsequently. The added time stamped reference position needs to be verified to ensure that this is indeed suitable to serve as the reference position. This is only appropriate if the means of transport (i.e. train Tr1 in this example) is actually on-time. As described above, the determination as to whether or not the specific Tr1 is on time can be performed by matching any timestamped positions added to the detailed reference schedule table to the reference data of the time table (3). As long as verification has not yet been performed, the corresponding value of the flag "valid" is set to "No" (see FIG. 5). If the unvalidated entry appears to be valid, the value of the "valid" flag is changed to "Yes ". If the unvalidated entry appears to be invalid (i.e., the train has not run on time), the entry is deleted from the detailed reference schedule table 4.

The location based delay decision leads to the actual calculation of the delay based on the validated entries of the timestamped reference positions in the detailed reference schedule table 4 (box 12 of FIG. 2). The geographical location resulting from the request by the smartphone 1 is tested against the detailed reference schedule table 4. If the detailed reference schedule table 4 includes a reference position that exactly matches the geographical location of the request, then the reference time can simply be taken from the detailed reference schedule table 4. [ Otherwise, the reference time for this geographic location may be calculated by linearly interpolating times relative to the reference locations in the detailed reference schedule table 4 immediately before and after the geographic location included in the request. It is also not possible to exclude that the detailed reference schedule 4 contains only a very small number of timestamped reference positions in relation to the current interval or does not include any entries that are away from stops / stations. This may be especially in the early stages of the deployment of the delay judgment or when the base timetable has changed (e.g., it has been on the train timetables twice a year). In this case, the detailed reference schedule 4 will contain at least data that can be taken from the operator's timetable, and the delay is calculated using linear interpolation of time and geographic location indications.

An example is given by FIG. 6, which includes only the reference times for the departure station St1 (departing at 7:30) and the final destination St3 (arriving at 8:01) . The distance between the two stations is estimated from the geographic locations of the inversions either within the timeline (see FIG. 4) or using the following equation:

(Lng_St3) + sin (lng_St1) sin (lng_St3)) cos (lng_St1) cos (lng_St3)

[Note: Arguments of sine and cosine expressions are given in radians]

Distance in km = Distance (St1, St3) * 6372,795477598

The distance between the current geographical location indicated in the location based request received from the user device 1 and the next station or reference location in the detailed reference schedule 4 is calculated in the same way. Then, linear interpolation is performed using the following three rules.

Tp = T1 * Dp / D1

Where Tp is the time required to reach the next reference position assuming a linear progression of the vehicle, T1 is the reference time required for transportation to complete the journey from the previous reference position to the next reference position, Dp is the current time The distance between the position and the next reference position, and D1 is the distance between the two reference positions (see the specific example numbers given by FIG. 6). Thus, in the example of Fig. 6, the train Trl is set to 7:42:25 (8: 1 - 17: 35), which is the resultant reference time calculated from the geographic location indicated in the request and the data contained in the detailed reference schedule Seconds) should be located at the reference position of 43.65 degrees longitude and 7.15 degrees longitude indicated in the request.

The difference between this resulting reference time and the time stamp associated with the request is calculated, which is the desired real-time delay of the train Trl.

One example of the delay calculation 12 according to the delay-based request is given with reference to FIG. 7 shows a reference motion curve of the train Tr1 determined by the detailed reference schedule table 4. In FIG. The position is displayed on the X axis of the diagram, and the time is displayed on the Y axis. As described above, this motion curve is established by collecting, for example, time stamp + location pairs included in location based requests related to the transportation of the very connection on the time line. As more entries are generated and collected in the detailed reference schedule (4), the motion curve will be more accurate and complete. Using this motion curve, the reference time of the train Tr1 is determined based on the geographical position included in the request as an input parameter. For example, the geographical location of latitude 43.65 degrees and longitude 7.25 degrees corresponds to a reference time of 7:52 according to the motion curve. This reference time is then compared to the actual time of the timestamp associated with the request. If this timestamp is 8:12, the real time delay is 20 minutes.

Referring back to FIG. 2, the location based delay determination process proceeds with updating the logbook table 5 (box 13). As already explained above, the purpose of the logbook table 5 is to make available real-time delay information for passengers who can not provide location information with their requests. One example of the logbook table 5 is given by FIG. (E.g., " planTime ") and a timetable 3 (departure station ["stDep"] from the detailed reference schedule table 4, "stArr"], planned start time ["planDep"], and planned arrival time ["planArr"]). In particular, it includes real-time information from the request and delay calculations, namely the geographical location ("lat, lng") displayed in the request, the time stamp associated with the request ("realTime"), the delay and the estimated arrival quot ;, "realArr").

Finally, the requested real-time delay information, such as the next arrival station and the real-time delay value, is transmitted back to the smartphone 1 via the mobile communication interface (step 8 of FIG. 2). The client software installed in the smartphone 1 displays information to the passenger.

Turning now to the time-based delay determination shown on the right-hand side of FIG. 2, the smartphone 1 generates a time-based request with no indication of its current location in situations where the GPS signal is too weak or the GPS link is not available at all . Thus, a time-based request contains only a PNR identifier and a timestamp (alternatively also may be added only on the server side). This request is sent to the server 47. The PNR database 2 and the timetable (3) are referred to in order to determine the trainID as described above in connection with the location-based determination. After determining the train ID in this way, the logbook table 5 is inquired using the train ID to find the potentially existing real-time delay information generated by the previous location-based delay judgment. For example, if it is determined that the logbook table 5 contains an entry for the current section of the passenger train, the delay associated with the entry is taken.

In the example of Fig. 8, the train Tr1 is assumed to be in the second section between the stations St2 and St3. According to the timetable, the train leaves station St2 at 7:40 and arrives at St3 at 8:01 (see also Figures 4 and 5). During this trip, two location based requests were generated and processed, and the calculated real time delays were stored in the logbook table 5. The first location-based request occurred at 7:46 when Tr1 was still in the first section between St1 and St2. A delay of 10 minutes was detected. Thereafter, when Tr1 went to the second section between St2 and St3, another location based request was received at 8:12, and a further increased delay of 20 minutes was determined. Now, assuming that the time-based request is received by the server at 8:15, the logbook table 5 is referenced and an 8:12 entry for the current section of the train Tr1 that is just three minutes old is found. The delay value of this entry, i.e. a 20 minute delay, is determined (box 7 in FIG. 2). The delay, for example, the next arrival station St3, is returned to the smartphone 1 which displays the information to the passenger.

In the following, an implementation of the location-based and time-based delay judgment including the caching function already outlined above will be discussed in more detail with reference to the flow charts of Figs. 9a, 9b and 9c. Figure 9A illustrates the processes that continue on the user device 1 until a request for a delay decision is issued. FIG. 9B shows processing of a request in the server 47. FIG. Finally, FIG. 9C again visualizes the operation on the user device 1 side after the result of the delay judgment is returned by the server 47. FIG.

In general, the appropriate data flows can be classified according to the following conditions.

(i) Both the position determination function and the mobile communication link are available in the user device (1).

(ii) The position determination function is available. However, a mobile communication link is not available.

(iii) the location determination function is not implemented or is temporarily unavailable. However, a mobile communication link is available.

(iv) neither position determination function nor mobile communication link is available.

(The location determination function and the mobile communication link are available), the data flow of (i) is as follows.

After the start step at step 19, the process begins with a validity check (step 20) of the PNR identifier that is present in the user device 1 or manually entered by the user. Then, after positively confirming the availability of the mobile communication link in step 21, the user device 1 verifies the cache in step 29. [ If the cache is empty, the mobile communication link is utilized to download detailed reference schedule data and current delay information for the vehicle referenced by the PNR identifier. For this purpose, a cache update message is sent to the server 47 at step 30. In response to the cache update message, the server 47 queries the database (i.e., the PNR database 2, the timetable 3, the detailed reference schedule 4, and the logbook 5) (1). The user device 1 stores these data in its own cache. The cache includes, for example, timetable data for this means of transport, in particular the next arriving station, detailed reference schedule data for this means of transport, and recent train delay information of this means of transport available in the logbook 5 . This information will be sufficient to calculate or predict the real-time delay of the vehicle for the location determination function and / or the absence of the mobile communication link.

Subsequently, the user device 1 checks in step 27 whether the GPS signal is available as a positive outcome. The user device 1 generates a location based request at step 28 and sends it to the server 47. [ On the server side (FIG. 9B), the server 47 checks whether the time table 3 associated with the vehicle currently in use by the passenger is already available. If not available, each timetable information in step 32 can be retrieved by the operator of the vehicle. To include these data as soon as possible, the server 47 appropriately has a communication link to the operator and his timetable database.

After making a positive determination in step 33 that the request received by the user device 1 includes a geographical location, the server 47 optionally performs verification of the geographical location included in the request (not shown in Figure 9B) . This verification function is to ensure that the geographical location contained in the request matches the path of the train indicated by the PNR. To perform this verification, a description of the train path in terms of geographic location is available to the server 47. The geographic location indicated in the request is compared to the geographic location reference of the route. If the geographic location of the request is determined to be "within the route ", that is, matches or at least approximately matches the location on the path, the geographic location of the request is considered valid. The geographic location reference information of the route may be obtained from the carrier operator or from an external map service and may be collected and inferred by an operator of the server 47 and / or by a significant number of received location based requests. Additionally, requests indicating geographical locations that are on or near the path but which are significantly away from the actual location of the train (requests made by future passengers who have already been waiting in the next stations or previous passengers who have already left the train in the previous station May be filtered to align the geographic location of the request and the timestamp pair with the information already contained in the detailed reference schedule 4 and / or the logbook 5. For example, if the logbook 5 already contains entries for geographic locations further down the path (such invalid requests can still be processed based on the logbook 5, for example, , A recent real time delay included in the logbook 5 may be returned), and the request indicating the geographical location where the train has already passed may be filtered. As another example, in view of the entries in the logbook 5, requests indicating future geographic locations where trains could not have arrived can be filtered (similarly, in response to these requests, Delay information can be returned). Generally, if it is determined that the geographic location indicated by the request is not related to the current position of the train, such a request can be handled similarly to a time based request. That is, no geographical position is deemed to exist, and real-time information can be returned using the logbook 5.

Following this selective verification step, the server 47 executes the location-based delay determination. (Shown on the right side of Fig. 9B). As already described in detail above with reference to Figure 2 above,

- querying the timetable (3) using the geographical location contained in the request of the user device in step 41 to determine the current section;

- querying the detailed reference schedule (4) for the interval and the geographical location in step 42 and, if applicable, interpolating the time stamped reference positions stored in the detailed reference schedule (4);

- calculate the next inverse estimated arrival time corresponding to the real time delay in steps 43 and 44; And

- updating the logbook 5 with at least a time stamp ("realTime"), a computed real delay ("delay") and an estimated next station ("stArr") actual arrival time ("realArr" .

Then, in step 40, the server 47 returns the resultant real-time delay information, such as the next arrival station, the estimated actual arrival time, and the calculated real-time delay to the user device 1. After receiving each message over the mobile communication link (FIG. 9), the user device 1 updates its cache with this information in step 46 and presents this information to the user in the case of a graphical user interface. This process ends at step < RTI ID = 0.0 > 48.

(The position determination function is available, and the mobile communication link is not available), the data flow of (ii) is as follows.

If it is determined that the mobile communication link is not already available from the start of step 21, the user device 1 checks in step 22 whether the cached information associated with the vehicle indicated by the user is available. If the check is positive, the delay judgment in step 23 is locally possible in the user device 1. If the cached data includes detailed reference schedule data related to the user's transportation means, the location based request may be sent by the user device 1 in a manner similar to what would have been handled by the server 47 if a mobile communication link was available Internally generated and processed. The only fundamental difference is that it is not possible for the user device 1 to update the logbook 5 as performed by the server at step 45 without a mobile communication link. Accordingly, the user device 1 buffers the appropriate data in the local logbook to update the server-side logbook 5 when the mobile communication link becomes available again (this activity is not shown in Fig. 9A ). The delay information calculated locally by the user device 1 is presented to the user, and the process is terminated at step 24. [

(The mobile communication link is available and the location determination function is not available), the data flow of (iii) is as follows.

In this case, a time-based delay judgment is performed. This process starts with steps 19 to 21, 29 and 30 in the user device 1 again as described above with reference to the case (i) of the data flow. In step 27, the user device 1 determines that the GPS signal is not available. The presence of the mobile communication link is again verified in step 25.

If the mobile communication link becomes unavailable in the meantime, the delay determination is generally performed locally at steps 22 and 23 because the cache has previously been updated at steps 29 and 30 and the required criteria and logbook data are locally present in the cache It is possible. Since the current location is not known to the user device 1 in this scenario, local delay determination can be performed by the server 47 (as will be described subsequently with reference to Figure 9b) if logbook data is available Will be consistent with the time-based delay judgment. Alternatively, if there is no logbook data to be cached (e.g., because there have been no location-based requests for the current travel of the vehicle), at least the reference data contained in the timetable 3 will be displayed to the user . In this branch, the process ends at step 24.

If the re-verification at step 25 confirms that the mobile communication link is still present or available, the user device 1 generates a time-based request at step 26. This request includes a PNR identifier and a timestamp of the current time (as described above, the timestamp may only be added later by the server when the server 47 receives the request). On the server side (now referring again to Figure 9b), steps 31 and 32 are performed as previously described. The determination at step 33 shows that the request does not contain a geographic location, i. E., A time based request. Accordingly, the server 47 performs the visualized delay determination on the left side of FIG. 9B.

In step 34, the server 47 checks whether the transportation means indicated by the PNR identifier exists in the logbook 5. [ If not, the server attempts to retrieve at least the timetable information at steps 35 and 37, and returns at step 39, for example, the next arrival station and the scheduled arrival to the user device 1. Warnings or comments may be included that emphasize that this is not the actual arrival time but only the scheduled time. If even the scheduled information contained in the timetable 3 is also inaccessible for some reason, an error message will be returned to the user device 1 at step 38.

If, as a result of the check in step 34, the real-time delay information regarding the user's current mode of transportation is available in the logbook 5, a time-based delay calculation is performed in step 36. the entries of the logbook 5 related to the current section of the transportation means are retrieved by applying the condition realTime <timeAr <realArr. The parameters "realTime" and "realArr" are part of the logbook entries (see FIG. 8). The "realTime" values correspond to the timestamps of previous location based requests leading to entries in the logbook (5). The "realArr" values represent the actual arrival of the next station estimated by previous real-time judgments. Thus, logbook entries having values of "realTime " that are less than or equal to the value of the timestamp associated with the current time-based request include the results of previous delay judgments. It is assumed that logbook entries having values of "realArr" equal to or greater than the value of the timestamp associated with the current time-based request are indicative of the current interval at which the user's transportation means is located. However, if "realArr" is less than the time stamp of the request, each entry may represent a previous interval and the vehicle may have assumed that it has already reached the next arriving station. This may be an indication that the delay indicated by this entry is no longer up-to-date.

The way to calculate the real-time delay depends on the number of logbook entries and their time values. For example, if the logbook 5 contains one entry representing the current interval of the vehicle, then at step 36 the next arriving station ("stArr"), the estimated arrival time ("realArr" ("Delay") is retrieved and returned to the user device 1 at step 40. On the other hand, if there is no logbook entry satisfying the above condition (i.e., realTime < realStr < realArr), only an error message may be returned in step 38 only. Alternatively, at least scheduled information (next arrival station, scheduled arrival) may be retrieved from the timetable 3 and returned to the user device 1. However, if the logbook 5 contains only a plurality of entries related to previous intervals (i.e., timestamp> realArr), extrapolation may be performed on the delay values of these old entries, The value can be returned as an approximate estimate. In this case, a warning or comment may be added back that the delay information may be inaccurate. Eventually, the process returns to the user device 1 (Fig. 9C). If so, the user device 1 updates its cache at step 46 and the process ends at step 48. If the real time delay information is provided by the server 47,

Finally, the data flow of (iv) (when there is no available position determination function and no mobile communication link) is as follows.

If the user device 1 has already determined early in the step 21 that the mobile communication link is not available, if the logbook data has been previously cached or at least timetable data can be presented to the user, local time-based delay judgment is possible It is possible. In this case, reference may be made to the description of steps 22 and 23 given above with reference to case (ii). If the available logbook and / or timetable is not in the cache and the check at step 22 is not successful, the process ends at step 24.

However, if the mobile communication link is available at step 21, the cache is updated at steps 29 and 30. [ After that, if the mobile communication link is released and it is judged in step 25 that the link is absent, a time-based delay judgment is made in steps 22 and 23. This is similar to the time-based delay judgment by the server described in detail previously with reference to case (iii). In this case, the process is similarly terminated in step 24. [

Figure 10 provides a high-level overview of possible architectures for the present delay estimation system. In this example, the user device 1 includes a position determination function in the form of a GPS transceiver 50. [ To implement the caching function, a certain portion of the user device's memory (non-volatile memory such as volatile RAM or flash memory) is utilized as the cache 53. The client-related functions of the delay judgment are implemented by the delay judgment mobile application 51. [ Communication with the user / passenger is possible through a graphical user interface such as a touch screen. Among them, the graphical user interface is used by the user to input his / her travel schedule information such as PNR number or transportation connection information and to display real time delay information.

On the other hand, the server side 47 provides the web services to the user device 1. This includes an infrastructure for maintaining basic data, in particular timetables (3), detailed reference schedules (4) and logbooks (5). In the example of pursuing real-time delay calculation of trains, the server-side infrastructure includes a Rail Distribution Platform (RDP) 54, a RailIT server 55 and a database 56.

FIGS. 11 and 12 visualize an example of a graphical user interface of the exemplary smartphone 1, and display the determined real-time delay information to the user through the software installed in the smartphone 1. ("Intercity 12345"), next scheduled stop ("Pisa"), scheduled information associated with the next station ("19/10/2011 20:10 ("Arrival at 20:15 on 19/10/2011") and delay ("Delay: 5 minutes") at that station, underneath which the actual location of the vehicle Some of the major stations ("Napoli", "Rome", "Torino") are displayed. Stations arriving on time are particularly highlighted by the green background color, for example. For example, a button labeled "Detailed Schedule" can be used to summarize the user to an overview of the table appearance of scheduled and calculated arrival / departure times for major stations (Shown in Fig. 12). In addition, Typically, with the arrival / departure times and calculate the scheduled arrival / departure time, and is presented with a complete list of the region and the upcoming arrival station.

Finally, Fig. 13 is a diagrammatic representation of the internal structure of the user device (1). The user device 1 is arranged to execute a set of directives to perform any of the methodologies discussed herein. The mobile communication device includes a processor 121, a main memory 122 and a wireless network interface 123 and / or a 2G / 3G / 4G mobile network interface device (not shown) (such as a Wi-Fi and / , All of which communicate with each other via bus 124. The mobile communication device further includes a static memory 125, e.g., a non-removable flash or solid state drive, or a removable micro or mini SD card, which allows the user device 1 to perform local delay determination functions, And permanently stores the software to communicate with the structure 47. Furthermore, it is possible to use a display 127, preferably a touchscreen, a user interface (touchscreen) control module 129 and optionally additional (non-parametric) alphanumeric and cursor input devices 128 If present). The wireless network interface device 123 connects the user device 1 to the server-side infrastructure 47. An optional GPS transceiver 126 provides position determination. A set of directives implementing any or all of the methodologies described above fully or at least partially resides in the static memory 125. When executed, each of the directives and / or data remains in the main memory 122 and / or the processor 121. The software 130 may be downloaded from the server-side infrastructure shown in Figure 10 or from / to the server in the Internet via the wireless network interface device 123 or the 2G / 3G / 4G mobile network interface in the form of a propagated signal 132 Transmitted or received.

The server-side infrastructure 47 is constructed in a similar manner with the exception that some or all of these components can not have any wireless network interfaces and GPS modules.

Although certain products and methods in accordance with the teachings of the present invention have been described herein, the scope of coverage of the present invention is not limited thereto. On the contrary, the present patent application includes all embodiments in accordance with the teachings of the present invention which fall within the scope of the appended claims literally or equivalently.

Claims (14)

CLAIMS 1. A method for determining a real-time delay of a scheduled vehicle traveling along a path in accordance with a timetable, the path comprising at least one section, the determining of the real-time delay comprising the step of: Based on a detailed reference schedule that represents the reference positions,

Receiving, by the user device located in the vehicle, a request for real-time delay of the vehicle, indicative of at least the current position of the vehicle;

Calculating a real time delay of the transportation means based on the requested current position, timestamp and corresponding timestamped reference position of the detailed reference schedule;

Returning to the user device requesting the calculated real-time delay; And

And storing the calculated real-time delay in a logbook.

Returning a real-time delay based on a logbook containing real-time delayed entries for the vehicle in response to a request by a different or the same user device not presenting the current location of the vehicle, &Lt; / RTI &gt; The method according to claim 1,
Wherein the timestamp is determined by receipt of the request. 3. The method according to claim 1 or 2,
Any time-stamped reference positions of the vehicle are collected via requests by user devices located in the vehicle, the requests indicating at least the current location of the vehicle, and the vehicle being verified to be on- Lt; / RTI &gt; 4. The method according to any one of claims 1 to 3,
Wherein the most recent real time entry in the logbook is returned in response to a request by a different or the same user device not displaying the current location of the vehicle. 4. The method according to any one of claims 1 to 3,
In response to a request by a different or the same user device not presenting the current location of the vehicle, the real-time delay entries in the logbook are extrapolated; And the result of the extrapolation is returned. 6. The method according to any one of claims 1 to 5,
Wherein the request by the different or the same user device not indicating the current location of the vehicle is transmitted by the device which is unable to determine its current location. 7. The method according to any one of claims 1 to 6,
Calculating the real-time delay may include calculating a linear relationship between timestamped reference positions in the detailed reference schedule if the current position indicated in the request by the user device does not exactly match an entry in the detailed reference schedule that represents one of the time- And interpolation. 8. The method according to any one of claims 1 to 7,
Wherein the request further comprises an identification code that allows identifying the timetable of the vehicle. 9. A method according to any one of claims 1 to 8,
Caching at least a detailed reference schedule to the requesting user device, and
- determining in real time a local delay in the user device in response to a request by the user device indicating at least the current location of the means for transport. 10. A method according to any one of claims 1 to 9,
- storing locally determined real-time delays in a local logbook of the user device, and
Further comprising the step of the user device sending a local logbook for inclusion in a central logbook. 11. The method according to any one of claims 1 to 10,
Wherein the vehicle is a train, a ship, a bus, an airplane, a tram or a shuttle service vehicle. A computer system for determining a real-time delay of a scheduled vehicle traveling along a path in accordance with a timetable, the path comprising at least one section, wherein determining the real-time delay comprises determining at least one time- Based on a detailed reference schedule representing reference locations, the computer system comprising:

Receiving, by the user device located in the vehicle, a request for real time delay of the vehicle, at least indicating the current location of the vehicle;

Calculate a real time delay of the transportation means based on the requested current position, the time stamp, and the corresponding timestamped reference position of the detailed reference schedule;

Return to the user device requesting the computed real-time delay;

And configured to store the calculated real-time delay in a logbook, whereby the real-time delay of the vehicle is determined based on the position,

In response to a request by a different or the same user device not presenting the current location of the vehicle, to return a real time delay based on a logbook containing real time delay entries for the vehicle, Based on time-based decisions. There is provided a non-transitory computer readable storage medium having stored thereon computer program instructions stored thereon for causing the computer system to determine a real-time delay of a scheduled vehicle traveling along a timetable when executed on the computer system, Wherein determining the real-time delay is based on a detailed reference schedule that represents any timestamped reference locations of the transportation means operating on time, and wherein the instructions cause the computer system to:

Receiving, by the user device located in the vehicle, a request for real time delay of the vehicle, at least indicating the current location of the vehicle;

Calculate a real time delay of the transportation means based on the requested current position, the time stamp, and the corresponding timestamped reference position of the detailed reference schedule;

Return to the user device requesting the computed real-time delay; And

To make a location based decision to store the calculated real time delay in a logbook,

In response to a request by a different or identical user device not presenting the current location of the vehicle, to return a real time delay based on the logbook containing the real time delay entries for the vehicle &Lt; / RTI &gt; 12. A computer program that instructs a computer to perform the method of any one of claims 1-11.

Images