Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q10/00—Administration; Management
  • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
  • G06Q10/083—Shipping
  • G06Q10/0833—Tracking
• • B—PERFORMING OPERATIONS; TRANSPORTING
  • B61—RAILWAYS
  • B61L—GUIDING RAILWAY TRAFFIC; ENSURING THE SAFETY OF RAILWAY TRAFFIC
  • B61L27/00—Central railway traffic control systems; Trackside control; Communication systems specially adapted therefor
  • B61L27/10—Operations, e.g. scheduling or time tables
  • B61L27/16—Trackside optimisation of vehicle or train operation
• • G—PHYSICS
  • G08—SIGNALLING
  • G08G—TRAFFIC CONTROL SYSTEMS
  • G08G1/00—Traffic control systems for road vehicles
  • G08G1/123—Traffic control systems for road vehicles indicating the position of vehicles, e.g. scheduled vehicles; Managing passenger vehicles circulating according to a fixed timetable, e.g. buses, trains, trams
  • G08G1/127—Traffic control systems for road vehicles indicating the position of vehicles, e.g. scheduled vehicles; Managing passenger vehicles circulating according to a fixed timetable, e.g. buses, trains, trams to a central station ; Indicators in a central station

Definitions

• the present invention generally relates to delay determination of scheduled transportation means. More specifically, it is directed to providing real-time delay information about the transportation means to passengers with mobile user devices.
• the travel time of transportation means which runs along a predetermined route is one of the primary information to most of the passengers.
• public transportation means such as trains, buses, ships, airplanes or trams
• the passengers usually want to know the exact travel time, the departure time and the arrival time of the transportation means.
• an official timetable for each public transportation means is provided to the passengers by operating companies, e.g. on the web.
• these official timetables include the planned departure and arrival times for all stations within a certain route.
• the transportation means may be delayed due to unexpected factors (e.g., rough weather, traffic situations, etc.). As a consequence, the timetables may not reflect the actual progression of transportation means.
• JP 06044495 A discloses a method to provide delay information to passengers of a local train or bus. It describes an arrival time display device with a position measuring device such as a GPS device. The arrival delay time and the early arrival time of the train or bus is calculated by means of a time difference calculation part included in the arrival time display device by calculating a time difference between the scheduled arrival time and the present time at a certain position.
• a method of determining a real-time delay of a scheduled transportation means which runs along a route according to a timetable is provided.
• the route comprises at least one leg. Determining the real-time delay is based on a detailed reference schedule which indicates arbitrary time-stamped reference positions of the transportation means being on time.
• the method comprises a position-based determination and a time-based determination.
• the position-based determination comprises
• the time-based determination comprises returning the real-time delay on the basis of the logbook containing real-time delay entries with respect to the transportation means in response to a request by a different or the same user device not indicating the current position of the transportation means.
• a computer system for determining the real-time delay of a scheduled transportation means as described above is provided.
• a non-transitory computer readable storage medium having computer program instructions stored therein, which, when executed on a computer system, perform the method as described above.
• a computer program which causes, when executed on a computer system, to perform the method as described above.
• Fig. 1 depicts a flow diagram showing the principles of the present delay determination.
• Fig. 2 shows a more specific flow diagram according to an example of the present delay determination.
• Fig. 3 shows a Passenger Name Record (PNR) database which is utilized in an example of the present delay determination.
• PNR Passenger Name Record
• Fig. 4 illustrates an exemplary timetable of a scheduled transportation means.
• Fig. 5 depicts an exemplary detailed reference schedule which may be employed in the present delay determination.
• Fig. 6 is a calculation example illustrating reference time calculation using linear interpolation.
• Fig. 7 illustrates an exemplary motion curve of a transportation means.
• Fig. 8 shows an exemplary logbook which may be employed in the present delay determination.
• Figs. 9a, 9b and 9c depict a detailed flow diagram showing the procedures in the user device and on the server side according to an implementation example of the present delay determination.
• Fig. 10 illustrates the architecture of an exemplary system arranged to perform the present delay determination.
• Fig. 11 and 12 illustrate the graphical user interface of a user device running an application performing the present delay determination.
• Fig. 13 is an exemplary schematic view of the internal architecture of user device. DETAILED DESCRIPTION OF THE FIGURES
• the present invention generally relates to scheduled transportation means which travel regularly according to a particular timetable.
• a scheduled transportation means may, for example, be a train (such as an international, a high-speed, a national, regional or a suburban train), a bus, a shuttle car, an airplane, a ship or a ferry, a tram or any other public transportation means.
• Timetables are normally created and issued by the operator of the transportation means.
• the SCNF creates and issues timetables for all the TGVs running in France, whereas the Deutsche Bahn generates and issues the timetables of the ICEs running in Germany.
• the operator makes the timetables available to the public and, in particular, to passengers at stations, via the Internet or at/in the transportation means itself.
• the timetables of the transportation means normally indicate the origin and the final destination of a transportation means as well as the intermediate stations. Furthermore, they normally indicate the departure time at the origin station and the arrival time at the final destination and as well as departure times and, optionally, arrival times at the intermediate stations.
• the timetables of the operators logically group the scheduled transportations means regarding their route and their travel time.
• Transportation means going an identical route at identical times are hereinafter referred to as transportation means belonging to a particular "connection".
• transportation means belonging to a particular "connection" For example, all trains running daily from Nice to Paris at 10 o'clock form such a connection.
• the term "route” refers to the way of the scheduled transportation means according to the timetable from the origin station to the final destination.
• the route of a scheduled transportation means is composed of legs.
• leg refers to a part of the route between two subsequent stations listed in the timetable. Exceptionally, a route consists of only one leg if the timetable does not prescribe any intermediate stop between the origin station and the final destination. Normally, however, the route is divided into a plurality of legs. If, for example, the timetable indicates six intermediate stations between the origin and the final destination, the route is subdivided into seven legs.
• the delay is used herein to cover all three of these possibilities. Hence, the delay is positive when the transportation means is behind schedule and will arrive at the next station probably later than indicated by the timetable. It is zero when the transportation means is on time and will probably arrive at the next station at the time indicated by the timetable. It is negative if the transportation means is before schedule and will, thus, probably reach the next station earlier than indicated by the timetable.
• JP 06044495 A which was already mentioned above.
• the delay calculation disclosed therein requires manual input of the destination information and a provision of the present position of a user, for example by utilizing the Global Positioning System (GPS).
• GPS Global Positioning System
• JP 06044495 A is based on simply comparing the scheduled arrival time with the present time and the destination position with the present position.
• linear progression of the user's vehicle is assumed. This does not correlate with real-world progression which is normally non-linear.
• the approach proposed by JP 06044495 A is inherently inaccurate.
• the delay information method/system presented herein allows providing real-time delay information to user devices which are not equipped with position determination functionality or are in situations in which a position determination is not possible. Furthermore, it aims at improving the accuracy of the delay information.
• the present delay determination is based on a reference schedule 4 which is more detailed than the timetables issued by the transportation means operators. As outlined before, those operator timetables merely contain target times regarding the stops or stations of a transportation means. However, this information is presently considered to be insufficient because it does not provide any reference information for positions between the intermediate stations, i.e. within the legs.
• the detailed reference schedule 4 is introduced which aims at reflecting the actual real-world progression of the on-schedule transportation means between its intermediate stations more accurately.
• the detailed reference schedule 4 contains target time information for any arbitrary locations along the route, in addition to the target time information at the intermediate stations which can be taken from the respective operator timetable.
• the detailed reference schedule 4 does not only indicate the arrival and departure times of stations prescribed by the operator, but also and in particular includes additional time- stamped reference positions of transportation means being on time, the positions being arbitrary, i.e. independent from the stops or stations.
• the present delay determination method utilizes a logbook 5 in which realtime delay information about the transportation means in question are collected.
• the logbook 5 is filled with real-time delay information generated by position-based delay determination which is performed as follows (visualized by the left-hand branch of Figure 1):
• a passenger located on or at the transportation means is equipped with a mobile user device 1 such as a mobile phone, a smartphone, a laptop, a tablet computer etc.
• the user device 1 generates a request for the transportation means' real-time delay. This request includes at least the current position of the user device 1 which is identical to the current position of the transportation means. It is issued to a server or may, alternatively, be processed locally at the user device 1 using a cache mechanism (this will be explained in more detail below).
• the request is then received, either by the server or internally by the user device 1.
• the request is processed in order to calculate the delay of the transportation means.
• the detailed reference schedule 4 is consulted and respective time-stamped reference positions regarding transportation means on-time are used to calculate the real-time delay of the transportation means (at box 12 in Figure 1).
• the specifics of the delay calculation are described further below.
• the resulting delay information is, at box 8 in Figure 1 , returned to the user device 1 (again, either by the server or internally within the user device 1).
• the calculated delay information is logged and stored in the logbook 5.
• the logbook 5 filled with the delay information obtained by the position-based determination facilitates a purely time-based determination (depicted on the right-hand branch of Figure 1) which works without any position determination by the user device 1.
• the user device 1 - which may be the same or another user device that has issued a position-based request beforehand - generates a time-based request which, in contrast to the position-based request described above, does not include an indication of the user device's 1 current position.
• the reason for this could be that the device 1 is incapable of determining its current position, either because it is not equipped with any position-determination means, it is only equipped with inaccurate position determination means which are insufficient for the purpose of the present delay determination or a position determination is impossible at the time of the request, e.g.
• logbook data associated with the user's transportation means can be determined on the basis of this time- based request, it is possible to determine the delay of the transportation means (at box 7 in Figure 1) and to return delay information (again at box 8 of Figure 1) concerning the transportation means on the basis of the real-time delay entries available in the logbook 5.
• the real-time delay information may include, e.g., the scheduled arrival time of the transportation means at a station according to the operator's timetable, in particular the next station (the endpoint of the current leg), the current time delay of the transportation means and the respective potential actual arrival at the next and/or final destination.
• both, the position-related request and the time-related request are associated with a time-stamp.
• This time-stamp is used to determine the leg at which the transportation means is supposed to be located at the time of the request and for the calculation of the real-time delay.
• One possibility is to directly include it in the request by the user device 1.
• the requests actually contain the time-stamp.
• the other possibility is to generate the time-stamp only at the reception of the request. This option is particularly useful if the request is processed centrally by a server (as opposed to process it locally at the user device 1 using the cache mechanism described further below).
• Generating the time-stamp at the server ensures a consistent time management as all requests are time-stamped by one and the same server-side clock.
• a similar consistent time management is also possible when using the first option (including the time-stamp in the request), namely if the user devices 1 are synchronized with a trusted clock.
• time-stamped reference positions are "arbitrary” because they refer to any locations on the route independent from the stations or stops of the transportation means.
• One possibility to establish the detailed reference schedule 4 is the so-called “social approach” which is independent from cooperation of the transportation means operators. Thus, it can be employed without having to rely on the good will of the operators to deliver detail data about the network and the timing conditions of their transportation means.
• the social approach utilizes actual position-based requests issued by the user devices 1 located on the transportation means. As each of these requests provides a position of the transportation means and an associated time-stamp (i.e.
• time-stamp + position pair they generally provide a valuable data base.
• the entries of the detailed reference schedule 4 serve as reference time-stamped positions, a validation of the collected data is performed. From the overall number of collected time-stamp + position pairs, those pairs are sought which belong to transportation means that were on time (i.e. transportation means which progressed in accordance with the timetable of the operator) and the remaining data sets from transportation means that were not on time are discarded.
• This sorting out can be performed by looking at the time-stamp + position pairs with positions in the vicinity of the stations for which the operator has set reference times. If pairs with positions in the vicinity of the stations correspond to the times prescribed by the operator's timetable, the respective transportation means is considered to have been on time and all time-stamp + position pairs collected from this transportation means are considered as valid and they are included in the detailed reference schedule 4.
• the logbook 5 is utilized (box 7 in Figure 1) in response to requests not indicating the current position of the transportation means in basically two ways.
• One way is to simply return the most recent real-time delay entry concerning the transportation means in the logbook 5 to the requesting user device 1. This option is particularly suitable if this most recent entry in the logbook 5 is up to date and, therefore, reflects the current real-time delay of the transportation means accurately.
• the up-to-dateness of the last entry in the logbook 5 is, for example, determined by a comparison of the time-stamp of the logbook entry with the time-stamp associated with the request.
• the real-time delay calculation (box 12 in Figure 1) in response to requests indicating the current position of the transportation means.
• the detailed reference schedule 4 contains a time-stamped reference position which corresponds to the current position of the transportation means indicated in the request, it is sufficient to calculate the difference between the reference time-stamp associated with that position in the detailed reference schedule 4 and the time-stamp associated with the request. This difference between the two time-stamps is the accurate real-time delay of the transportation means and is returned to the user device 1 (at box 8 in Figure 1). If, on the other hand, the detailed reference schedule 4 does not include a reference position corresponding with the position indicated in the request, there are two further options.
• the detailed reference schedule 4 is searched for the reference position closest to position indicated in the request and the real-time delay is calculated as just described before, i.e. by calculating the difference between the reference time-stamp associated with that position in the detailed reference schedule 4 and the time-stamp associated with the request.
• this introduces a certain inaccurateness which becomes more substantial the more the two positions (i.e. the position in the detailed reference schedule 4 and the position in the request) deviate from each other.
• linear interpolation techniques with respect to the time-stamped positions in the detailed reference schedule 4 in the vicinity of the position indicated in the request may be employed.
• this identification code is a Passenger Name Record (PNR) identifier which allows querying a PNR database for itinerary information of the passenger.
• This itinerary information may include information regarding the connection of the transportation means the passenger is currently using.
• an identification code other than a PNR identifier is included in the request.
• the user device 1 may prompt the user to enter the transportation means and the connection, respectively, s/he is currently using and the passengers then manually enters this information which is then included in the request.
• the position-based determmation includes caching the detailed reference schedule 4 at the requesting user device 1.
• the user device 1 directs its first position-based request regarding a particular transportation means to a delay determination server.
• the server maintains the detailed reference schedule 4 containing the data associated with the connection of the transportation means the passenger is currently using.
• the position-based request of the user device 1 is processed by the delay determination server as described above and the calculated real-time delay is returned to the user device 1.
• the detailed reference schedule data belonging to the current transportation means of the passenger is also transferred to the user device 1 , either together with the real-time delay information or in a separate message before or after the real-time delay information was returned by the server.
• the detailed reference schedule data is then buffered in a cache memory at the user device 1. Consequently, subsequent position-based requests by the same user device 1 can be processed locally at the user device 1, without any need to transmit the position-based request to the delay determination server. In this way, position-based delay calculation becomes possible without the necessity for the user device 1 to activate any external communication link and can, for example, therefore be performed in areas without radio coverage. If the position-based delay determination is performed locally at the user device 1 using the cached detailed reference schedule 4 due to the user device 1 lacking a radio link, it is consequently not possible to store the locally calculated real-time delay information in the logbook 5 which may be maintained in the delay determination server.
• the locally calculated delay information will also be buffered locally at the user device 1, in a local logbook.
• the user device 1 transmits the buffered real-time delay information back to the delay determination server and the information is then incorporated into the (central, server-side) logbook 5.
• Caching at the user device 1 is not limited to the detailed reference schedule data of the transportation means the passenger is currently using. Rather, it may usefully be extended to other information. For example, further detailed reference schedule data potentially relevant for future transportation means the passenger is likely going to use, such a connecting transportation means, may be cached at the user device 1 as well.
• the server-side logbook 5 may be transferred to the user device 1 and cached there.
• this cached logbook gets out of date and therefore less significant when not updated for a longer period of time, it enables time-based determination to be performed locally at the user device 1 without any need to consult the delay determination server.
• the extent to which data is cached at the user device is a trade-off between the resources available for the user device (e.g. free buffer space, quality of the communication link) and the potential improvements achievable by the cached data.
• the basic approach outlined above i.e. filling a logbook 5 with real-time delay information by collecting position-based delay requests and their calculation results, may be leveraged to further applications.
• the information maintained by the logbook 5 may be forwarded to displays at stations, to websites or web services accessible via the Internet, push services like RSS or SMS or any other broadcast-like information distribution channels.
• the present real-time delay determination mechanism independent from their current location.
• Figure 2 shows a more specific example of the present real-time delay determination. Similar to Figure 1, the left-hand branch of Figure 2 shows the position-based delay determination, whereas the branch on the right-hand side refers to the time-based delay determination.
• the user device 1 is a smartphone equipped with a locally installed delay determination application which is arranged to generate delay determination requests. It has a graphical user interface that is arranged to display information to the user and to allow user inputs if the user wishes to initiate the present delay determination. It is also provided with a mobile communication interface by means of a 2G, 3G and/or 4G transceiver and/or transceivers operating to other mobile communication standards such as WiFi IEEE 802.1 1. These communication interfaces facilitate mobile communication, in particular transmission of delay determination requests and reception of real-time delay information.
• the smartphone 1 is equipped with a GPS transceiver and, thus, capable of determining its location, provided that a communication link to GPS satellites can be established. If GPS is unavailable for some reason, the smartphone 1 may employ other position determination methods such as triangulation or Observed Time Difference techniques. If position determination is possible, the smartphone 1 initiates the position-based delay determination after a respective input command from the user. It determines its position and includes the resulting geo-position in the request. Furthermore, a time-stamp indicating the current time is included in the request generated by the smartphone 1. Alternatively, as explained above, the time-stamp is not included in the request, but only taken at the side of the server for reasons of overall time consistency. Finally, a PNR identification is included in the request.
• the smartphone 1 When the smartphone 1 has finished the creation of the position-based request, it transmits it over a suitable mobile communication link to the delay determination server 47 (the server is not shown in Figure 2, a high-level architecture of the overall system will be described further below with reference to Figure 10).
• the geo-position and PNR identification included in the request is utilized to determine the transportation means (more correctly, the connection of the transportation means) the user is currently located on and, more specifically, the current leg of the route on which the transportation means is currently located.
• the delay determination server 47 is suitably coupled to a travel information system such as a PNR database 2.
• a schematic representation of the PNR database 2 is given by Figure 3. It includes itinerary information of the user's travel.
• the travel may be composed of several segments such as a flight from A to B and a connecting train travel from B to C.
• One of the segments is formed by the current transportation means on which the user is located and to which the delay determination request relates.
• this example shall not introduce any limitations with respect to the type of transportation means.
• respective identification information kept in the PNR database 2 is of most interest, i.e. the ID of the train the user is supposed to take for his/her travel from B to C according to the itinerary (cf. Figure 3).
• the timetable may include several parameters, among them the TrainID, a StationID ("stID"), geo-positions of the stations ("lat” standing for latitude, “lng” standing for longitude, indicated in degrees) as well as arrival and departure times ("ArrTD", "DepTD”).
• the origin station of train Trl is Stl which is located at 43,55 degrees lat and 7,02 degrees lng. The train is supposed to depart from there at 7:30.
• the next stop is intermediate station St2 which is located at 43,59 degrees lat and 7,12 degrees lng.
• the train should arrive there eight minutes later at 7:38 and leave after a two-minutes stay at 7:40.
• the final destination is station St3 located at 43,70 degrees lat and 7,28 degrees lng which is supposed to be reached at 08:01.
• the timetable 3 may include geo-position information of the stations as well as distance information between the stations, i.e. the length of a leg (not shown in Figure 4).
• the goal of querying the timetable 3 is to determine the leg at which the transportation means is currently located (in other words: the next planned stop according to the operator's timetable 3).
• the geo-position included in the request is passed as an argument of the query to the timetable 3 and the current leg is retrieved.
• the process proceeds further with the geo-position (as originally included in the request), the time-stamp (either included in the request or set upon receipt of the request by the server) and the leg (determined from the consultation of PNR database 2 and timetable 3 as just described).
• the next step is an update of the detailed reference schedule 4 (box 10 in Figure 2).
• the detailed reference schedule contains arbitrary time- stamped reference positions, i.e. time stamp + position pairs for transportation means being on time according to the timetable 3 of the operator.
• An example of a detailed reference schedule 4 is given by Figure 5. It contains the trainID (e.g. Trl , Tr2), a legID, a time-stamp and a position (lat, lng).
• train Trl is supposed to be at coordinates 43,56 degrees lat, 7,1 1 degrees lng at 7:35, at 43,57 degrees lat, 7,1 1 degrees lng at 07:36 and so on.
• This collection of arbitrary time-stamped reference positions forms a motion curve of the transportation means (cf. Figure 7) which is more accurate the more validated data it contains.
• one approach to establish and enrich the detailed reference schedule table 4 is the so-called "social approach”: actually occurring position-based user requests are collected and stored in that table.
• the step of updating 10 the detailed reference schedule table 4 serves exactly this purpose. It is generally optional because it is not required if already sufficient valid data is present in the detailed reference schedule table 4. Updating 10 means that the pair of geo-position and time-stamp is added to the detailed reference schedule table as a reference date. However, if this optional addition is performed, a further process is executed subsequently, namely validation 1 1.
• the added time-stamped reference position needs to be validated in order to ensure that it is indeed suitable to act as a reference position. It is only suitable if the transportation means (i.e. train Trl in the present example) is actually on time. As already explained above, the determination whether that particular Trl is on time or not can be made by matching the arbitrary time-stamped positions added to the detailed reference schedule table with the reference data of the timetable 3. As long as validation has not yet been performed, the corresponding value in the flag "valid" is set to "No" (cf. Figure 5). If an entry which has not yet been validated is found to be valid, the value of the "valid" flag is changed to "Yes". If it is found to be invalid (i.e. the train has not been on time), it is deleted from detailed reference schedule table 4.
• the transportation means i.e. train Trl in the present example
• the position-based delay determination then moves on with the actual calculation of the delay (box 12 in Figure 2) on the basis of the validated entries of time-stamped reference positions in the detailed reference schedule table 4.
• the geo-position originating from the request by the smartphone 1 is tested against the detailed reference schedule table 4. If the detailed reference schedule table 4 contains a reference position exactly matching the geo-position of the request in which case the reference time can simply taken out of the detailed reference schedule table 4. Otherwise, the reference time for this geo-position is calculated by linearly interpolating the times associated with the reference positions in the detailed reference schedule table 4 directly before and after the geo-position from the request. Is it also not excluded that the detailed reference schedule 4 only contains very few time-stamped reference positions with respect to the current leg or none entries apart from the stops/stations at all.
• the detailed reference schedule 4 will at least contain the data which can be taken from the operator's timetable and the delay is calculated by using linearly interpolating the time and geo-position indications.
• Tp TI * Dp / DI
• Tp the time needed to reach the next reference position assuming linear progression of the transportation means
• TI the reference time needed by the transportation to complete the trip from the previous to the next reference position
• Dp the distance between the current location and the next reference position
• DI the distance between the two reference positions (cf. specific exemplary numbers given by Figure 6).
• train Trl should be located at the reference position of 43,65 degrees lat; 7,15 degrees lng indicated in the request at 7:42 and 25 seconds (08:01 - 17 minutes 35 seconds) which is the resulting reference time calculated from the geo-position indicated in the request and the data contained in the detailed reference schedule 4.
• FIG. 7 depicts the reference motion curve of train Trl as prescribed by the detailed reference schedule table 4.
• the position is plotted on the X axis, the time plotted on the Y axis of the diagram.
• this motion curve is, for example, established by collecting time-stamp + position pairs contained in position based requests relating to transportations means of the very connection which were on time. The more entries are generated and collecting in the detailed reference schedule 4, the more accurate and complete the motion curve will be.
• the reference time of train Trl is determined with the geo-position included in the request as input parameter.
• the geo-position of 43,65 degrees lat, 7,25 degrees lng corresponds to a reference time of 7:52 according to the motion curve. This reference time is then compared with the actual time of the time-stamp associated with the request. If this time-stamp reads 8: 12, the real-time delay is 20 minutes.
• the position-based delay determination process proceeds with updating the logbook table 5 (box 13).
• the purpose of the logbook table 5 is to make the real-time delay information available to passengers who are unable to provide position information with their requests.
• An example of a logbook table 5 is given by Figure 8. It contains the trainID (e.g. Trl, Tr2), reference information from the detailed reference schedule table 4 (e.g. "planTime") and the timetable 3 (departing station ["stDep"], next arrival station ["stArr"], planned departure time ["planDep”] and planned arrival time ["planArr"]).
• it contains real-time information from the request and the delay calculation, namely the geo-position indicated in the request ("lat, lng”), the time- stamp associated with the request (“realTime”), the delay and the presumed arrival at the next station ("delay", "realArr”).
• the requested real-time delay information such as the next arrival station and the realtime delay value is transferred back to the smartphone 1 (step 8 in Figure 2) via the mobile communication interface.
• the client software installed on smartphone 1 then displays the information to the passenger.
• the smartphone 1 generates a time-based request without an indication of its current position in situations the GPS signal is too weak or no GPS link is available at all.
• the time-based request only includes a time-stamp (which alternatively might also only be added at the server side) and the PNR identification.
• the request is transmitted to the server 47.
• the PNR database 2 and the timetable 3 are consulted in order to determine the trainID as it was described before regarding the position-based determination.
• the logbook table 5 is queried by using the trainID in order to seek potentially existing real-time delay information which have been generated by previous position-based delay determinations. For example, if it is determined that the logbook table 5 contains an entry for the present leg of the passenger's train, the delay associated with that entry is taken.
• train Trl is assumed to be on its second leg between stations St2 and St3. According to the timetable, it should have departed at station St2 at 7:40 and arrive at St3 at 8:01 (cf. also Figures 4 and 5).
• two position-based requests have been occurred and processed and the calculated real-time delays have been stored in the logbook table 5.
• the first position-based request occurred at 7:46 while Trl was still on its first leg between Stl and St. A delay of 10 minutes was detected. Later on, as Trl has progressed to its second leg between St2 and St3, another position-based request was received at 8:12 and a further increased delay of 20 minutes was determined.
• the logbook table 5 is consulted and the 8:12 entry regarding the current leg of train Trl which is only three minutes old is found.
• the delay value of this entry i.e. a delay of 20 minutes, is determined (box 7 in Figure 2).
• the delay and, for example, the next arrival station St3 is then returned to the smartphone 1 which displays the information to the passenger.
• Figure 9a depicts the processes going on at the user device 1 until a request for delay determination is issued.
• Figure 9b shows the processing of the request at the server 47.
• Figure 9c visualizes the action again at the side of the user device 1, after the delay determination result has been return by the server 47.
• the relevant data flows can be categorized according to the following conditions:
• the process commences with a validity check 20 of the PNR identification which is either present within the user device 1 or was entered manually by the user. Then, after having positively confirmed the availability of a mobile communication link at 21, the user device 1 verifies the cache at 29. If the cache is empty, the mobile communication link is utilized in order to download detailed reference schedule data and current delay information regarding the transportation means referenced by the PNR identification. For this purpose, a cache update message is transmitted to the server 47 at 30. In response to the cache update message, the server 47 queries its databases (i.e. PNR database 2, timetable 3, detailed reference schedule 4 and logbook 5) and returns the corresponding data to the user device 1. The user device 1 stores these data in its cache.
• PNR database 2 timetable 3, detailed reference schedule 4 and logbook 5
• the cache then contains, for example, the timetable data regarding the present transportation means, in particular the next arrival station, the detailed reference schedule data for the present transportation means and recent train delay information of the present transportation means available in the logbook 5. These information will be enough to calculate or estimate the real-time delay of the present transportation means in absence of a position determination function and/or mobile communication link.
• the user device 1 checks at 27 whether a GPS signal is available with a positive outcome. It then generates a position-based request at 28 and transmits it to the server 47.
• the server 47 checks at 31 whether a timetable 3 relating to the transportation means the passenger is currently using is already available. If this is not the case, the respective timetable information may be retrieved by the operator of the transportation means at 32. In order to be able to include these data as fast as possible, the server 47 suitably has a communication link to the operator and its timetable database.
• the server 47 After having positively determined at 33 that the request received by the user device 1 includes a geo-position, the server 47 optionally performs a validation of the geo-position included in the request (not shown in Figure 9b). The function of this validation is to ensure that the geo-position contained in the request is in line with the route of the train indicated by the PNR. In order to perform this validation, a description of the train's route in terms of its geo-position is available to the server 47. The geo-position indicated in the request is then compared with the geo-position reference of the route. If the geo-position of the request is determined to be "within the route", i.e. it corresponds or at least approximately corresponds to a location on the route, the geo-position of the request is considered to be valid.
• the geo- position reference information of the route may be obtained from the transportation means operator, an external map service, estimated by the operator of the server 47 and/or collected by and deduced from a significant number of received position-based requests. Additionally, requests indicating geo-positions on the or close to the route, but substantially remote from the actual position of the train (such as generated by future passengers already waiting at subsequent stations or former passengers who already left the train at a previous station) may be filtered out by aligning the geo-position and time-stamp pair of the request with the information already contained in the detailed reference schedule 4 and/or the logbook 5.
• a request indicating a geo-position which the train has already passed can be filtered out if the logbook 5 contains entries for geo-positions already further down the route (such outdated requests may be still processed on the basis of the logbook 5 and, for example, the latest real-time delay contained in the logbook 5 may be returned).
• a request indicated a future geo-position which the train cannot have already reached by taking into account the entries of the logbook 5 may be filtered out as well (similarly, in response to such requests, the latest real-time delay information may nevertheless be returned).
• the geo-position indicated by the request is determined to be not relating to the current position of the train, such a request may be treated similar to a time-based request, i.e. the geo-position is considered to be absent and real-time information may be returned by utilizing the logbook 5.
• the server 47 executes the position-based delay determination (shown at the right-hand side of Figure 9b).
• this process includes: determining the current leg at 41 by querying the timetable 3 using the geo-position included in the user device's request;
• the server 47 returns the resulting real-time delay information such as next arrival station, estimated actual arrival time and calculated real-time delay to the user device 1 at 40.
• the user device 1 updates its own cache with these information at 46 and presents the information to the user via its graphical user interface. The process terminates at 48.
• the data flow in case (ii) is as follows: If the unavailability of the mobile communication link is determined already at the outset at 21 , the user device 1 checks whether cached information relating to the transportation means indicated by the user is available at 22. If this is affirmative, delay determination is possible locally at the user device 1 at 23. Provided that the cached data includes the detailed reference schedule data concerning the user's transportation means, a position-based request is generated and processed internally by the user device 1 in a similar manner as it would have been processed by the server 47 in case the mobile communication link would have been available. The only basic difference is that updating the logbook 5 as it would be performed by the server at 45 is impossible for the user device 1 without a mobile communication link.
• the user device 1 buffers the relevant data in a local logbook for updating the server- side logbook 5 at a later time, when the mobile communication link becomes available again (this activity is not shown in Figure 9a).
• the delay information calculated locally by the user device 1 is presented to the user and the process ends at 24.
• the time-based delay determination is performed.
• the process starts again at the user device 1 with steps 19 to 21, 29 and 30 as described above with reference to data flow case (i).
• the user device 1 determines that a GPS signal is not available.
• the presence of the mobile communication link is then re-verified at 25.
• delay determination is then generally possible locally at steps 22 and 23 because the cache has been updated before at steps 29 and 30 and the necessary reference and logbook data should be present locally in the cache.
• the local delay determination will either correspond to the time-based delay determination as it would have been performed by the server 47 (as described subsequently with reference to Figure 9b), provided that logbook data is available.
• no logbook data is cached (for example, because there have not been any position-based requests concerning the current travel of the transportation means beforehand), at least the reference data contained in the timetable 3 can be displayed to the user. In this branch, the process then terminates at 24.
• the user device 1 If the re-verification at 25 confirms that the mobile communication link is still present or available, the user device 1 generates a time-based request at 26.
• the request includes the PNR identification and the time-stamp of the current time (as stated above, it is also possible that the time-stamp is only added later by the server 47 when it receives the request).
• steps 31 and 32 are executed as described before.
• the determination at 33 shows that the request does not include a geo-position, i.e. that it is a time-based request.
• server 47 performs the time-based delay determination, visualized on the left-hand of Figure 9b.
• the server 47 checks whether the transportation means indicated by the PNR identification is present in the logbook 5. If this is not the case, the server at least tries to retrieve the timetable information at steps 35 and 37 and returns, for example, the next arrival station and the scheduled arrival to the user device 1 at 39. A warning or remark might be included emphasizing that this is only the scheduled, but not the actual arrival time. If even the scheduled information contained in the timetable 3 is not accessible for some reason, an error message will be returned to the user device 1 at 38.
• the time-based delay calculation is performed at 36.
• the entries in the logbook 5 pertaining to the current leg of the transportation means are retrieved by applying the constraint realTime ⁇ time-stamp ⁇ realArr.
• the parameters "realTime” and “realArr” are part of the logbook entries (cf. Figure 8).
• the "realTime” values correspond to the time-stamps of the previous position-based requests which have been led to the entries of the logbook 5.
• the “realArr” values refer to the actual arrival at the next station which was estimated by the previous real-time delay determinations.
• logbook entries having values of "realTime” lower than or equal to the value of the time-stamp associated with the current time-based request contain results of previous delay determinations.
• Logbook entries having values of "realArr” equal to or greater than the value of the time-stamp associated with the current time-based request are presumably referring to the current leg on which the user's transportation means is located. If "realArr" is, however, lower than the time-stamp of the request, it can be assumed that the respective entry refers to a previous leg and the transportation means has already reached the next arrival station. This could be an indication that the delay indicated by this entry is not up- to-date anymore.
• the way of calculating the real-time delay depends on the number logbook entries and their time values. For example, if the logbook 5 contains one entry referring to the current leg of the transportation means, the next arrival station ("stArr"), the estimate arrival time (“realArr") and the delay value ("delay") of that logbook entry are retrieved at 36 and returned to the user device 1 at 40. If, on the other hand, no logbook entry fulfils the above condition (i.e. realTime ⁇ time-stamp ⁇ realArr), only an error message may be returned at 38. Alternatively, at least the scheduled information (next arrival station, scheduled arrival) may be retrieved from the timetable 3 and returned to the user device 1. If the logbook 5 contains several entries which, however, only pertain to previous legs (i.e.
• local time-based delay determination may be possible if logbook data has been cached previously, or at least timetable data may be presented to the user. In this case, it can be referred to the description of steps 22 and 23 which has been given above with reference to case (ii). If no logbook and/or timetable data is available in the cache and the check at 22 is therefore unsuccessful, the process terminates at 24.
• FIG. 10 present a high-level overview of a possible architecture for the present delay determination system.
• the user device 1 includes a position determination function in the form of a GPS transceiver 50.
• a certain portion of the user device's memory (either a volatile RAM or a non-volatile memory such as a flash memory) is utilized as a cache 53.
• the client-related functions of the present delay determination are implemented by a delay determination mobile application 51.
• Communication with the user/passenger is possible via a graphical user interface such as a touchscreen.
• the graphical user interface is, inter alia, used by the user for entering his/her itinerary information such as a PNR number or transportation means connection information and for displaying the real-time delay information.
• a server side 47 provides web services to the user devices 1. It comprises infrastructure which maintains the underlying data, in particular the timetables 3, the detailed reference schedules 4 and the logbooks 5.
• the server-side infrastructure comprises a Rail Distribution Platform 54 (RDP), a RaillT server 55 and a database 56.
• Figures 1 1 and 12 visualize an example of a graphical user interface of an exemplary smartphone 1 by means of which the software installed on the smartphone 1 displays the determined real-time delay information to the user.
• the main screen as depicted by Figure 11 shows the identification information of the transportation means ("Intercity 12345"), the next planned stop (“Pisa”), scheduled information related to this next station ("Scheduled arrival 19/10/2011 at 20:10), the estimated actual arrival at that station (“Actual arrival 19/10/2011 at 20:15) and the delay (“Delay: 5 min”). Further below, the actual position of the transportation means and certain important stops (“Napoli", “Roma”, “Torino”) are indicated. Those stations at which the transportation means was on time may be specifically highlighted, for example by green background colour.
• FIG. 12 is a diagrammatic representation of the internal structure of a user device 1.
• the user device 1 is arranged to execute a set of instructions, to cause it 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 (such as a Wi-Fi and/or Bluetooth interface) and/or a 2G/3G/4G mobile network interface device (not shown), all of which communicate with each other via a bus 124. It further includes a static memory 125, e.g. nonremovable flash or solid state drive or a removable Micro or Mini SD card, which permanently stores the software enabling the user device 1 to execute the local delay determination functions and to communicate with the server-side infrastructure 47.
• a static memory 125 e.g. nonremovable flash or solid state drive or a removable Micro or Mini SD card
• the wireless network interface device 123 connects the user device 1 to server-side infrastructure 47.
• An optional GPS transceiver 126 provides for location determination.
• a set of instructions (i.e. software) 130 embodying any one, or all, of the methodologies described above, resides completely, or at least partially, in the static memory 125. When being executed, respective instructions and/or data reside in the main memory 122 and/or the processor 121.
• the software 130 may further be transmitted or received as a propagated signal 132 through the wireless network interface device 123 or the 2G/3G/4G mobile network interface from/to the a server within the server- side infrastructure depicted by Figure 10 or the Internet.
• the server-side infrastructure 47 is constructed in a similar way with the exception that some or all of these components may not have any wireless network interfaces and GPS modules.

Landscapes

• Engineering & Computer Science (AREA)
• Business, Economics & Management (AREA)
• General Physics & Mathematics (AREA)
• Economics (AREA)
• Physics & Mathematics (AREA)
• Tourism & Hospitality (AREA)
• Theoretical Computer Science (AREA)
• Operations Research (AREA)
• Quality & Reliability (AREA)
• Strategic Management (AREA)
• Human Resources & Organizations (AREA)
• Entrepreneurship & Innovation (AREA)
• General Business, Economics & Management (AREA)
• Development Economics (AREA)
• Marketing (AREA)
• Radar, Positioning & Navigation (AREA)
• Remote Sensing (AREA)
• Mechanical Engineering (AREA)
• Management, Administration, Business Operations System, And Electronic Commerce (AREA)
• Navigation (AREA)
• Traffic Control Systems (AREA)
• Train Traffic Observation, Control, And Security (AREA)

Priority Applications (7)

Applications Claiming Priority (4)

Publications (1)

Family

ID=49943304

Family Applications (1)

Country Status (8)

Cited By (3)

Families Citing this family (5)

Citations (3)

Family Cites Families (4)

• 2013
  • 2013-12-16 AU AU2013362167A patent/AU2013362167B2/en active Active
  • 2013-12-16 WO PCT/EP2013/003800 patent/WO2014095029A1/en active Application Filing
  • 2013-12-16 CN CN201380057919.8A patent/CN104769618B/zh active Active
  • 2013-12-16 IN IN2407DEN2015 patent/IN2015DN02407A/en unknown
  • 2013-12-16 JP JP2015548276A patent/JP6184516B2/ja active Active
  • 2013-12-16 KR KR1020157010055A patent/KR20150100619A/ko not_active Ceased
  • 2013-12-16 SG SG11201502709UA patent/SG11201502709UA/en unknown
  • 2013-12-16 CA CA2885611A patent/CA2885611C/en active Active

Patent Citations (3)

Also Published As

Similar Documents

Legal Events