EP2747005A1 - Bestimmung der Echtzeitverzögerung von Transportmitteln - Google Patents

Bestimmung der Echtzeitverzögerung von Transportmitteln Download PDF

Info

Publication number
EP2747005A1
EP2747005A1 EP12290452.7A EP12290452A EP2747005A1 EP 2747005 A1 EP2747005 A1 EP 2747005A1 EP 12290452 A EP12290452 A EP 12290452A EP 2747005 A1 EP2747005 A1 EP 2747005A1
Authority
EP
European Patent Office
Prior art keywords
transportation means
time
real
request
time delay
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP12290452.7A
Other languages
English (en)
French (fr)
Inventor
Vincenzo Marafloti
Joel Cordesses
Richard Savornin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Amadeus SAS
Original Assignee
Amadeus SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Amadeus SAS filed Critical Amadeus SAS
Priority to EP12290452.7A priority Critical patent/EP2747005A1/de
Priority to PCT/EP2013/003800 priority patent/WO2014095029A1/en
Priority to SG11201502709UA priority patent/SG11201502709UA/en
Priority to KR1020157010055A priority patent/KR20150100619A/ko
Priority to CA2885611A priority patent/CA2885611C/en
Priority to JP2015548276A priority patent/JP6184516B2/ja
Priority to CN201380057919.8A priority patent/CN104769618B/zh
Priority to IN2407DEN2015 priority patent/IN2015DN02407A/en
Priority to AU2013362167A priority patent/AU2013362167B2/en
Publication of EP2747005A1 publication Critical patent/EP2747005A1/de
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/14—Following schedules
    • 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
    • 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/133—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 within the vehicle ; Indicators inside the vehicles or at stops

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.
  • 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.
  • those operator timetables merely contain target times regarding the stops or stations of a transportation means.
  • 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.
  • One possibility to supplement the operator timetables is to assume linear progression of the transportation means between the intermediate stations and, accordingly, to "fill in” the timetables by linear interpolation.
  • 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.
  • detailed reference schedule data will exist for each connection to be covered by the present delay determination.
  • the present delay determination method utilizes a logbook 5 in which real-time 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. Next, 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 determination 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.
  • 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. If this happens, the locally calculated delay information will also be buffered locally at the user device 1, in a local logbook. When a radio link is again available at a later point of time, 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. If feasible in view of available buffer space at the user device 1 and communication link bandwidth available to the user device 1, even more or all detailed reference schedules data which may become relevant to the passenger in future is transferred to the user device 1 and stored there for local position-based delay determination. Furthermore, in response to the first position-based request by the user device 1, also 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.11. 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 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.
  • 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 Tr1 is St1 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. Tr1, Tr2), a legID, a time-stamp and a position (lat, lng).
  • train Tr1 is supposed to be at coordinates 43,56 degrees lat, 7,11 degrees lng at 7:35, at 43,57 degrees lat, 7,11 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 11. 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.
  • the determination whether that particular Tr1 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 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
  • train Tr1 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 Tr1 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 Tr1 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. Tr1, 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"]).
  • the delay calculation 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 real-time 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 Tr1 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 Tr1 was still on its first leg between St1 and St. A delay of 10 minutes was detected. Later on, as Tr1 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.
  • 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 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.
  • 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 ). As explained in detail already above with reference to Figure 2 , this process includes:
  • 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.
  • 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.
  • the process returns to the user device 1 ( Figure 9c ). If feasible (i.e. if real-time delay information was provided by the server 47), the user device 1 updates its cache at 46 and the process terminates at 48.
  • time-based delay determination should be possible at 22 and 23. This is similar to the time-based delay determination by the server which has been described in detail before with reference to case (iii). In this case, the process likewise terminates at 24.
  • Figure 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 RailIT server 55 and a database 56.
  • Figures 11 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”).
  • 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.
  • Stations at which the transportation means was or is probably going to be delayed may be highlighted in a different fashion, for example by red background colour.
  • a button for example labelled "schedule details" leads the user to a table-like overview of the scheduled and calculated arrival/departure times for the major stations (shown by Figure 12 ). Additionally or alternatively, a full list of legs and upcoming arrival stations along with the scheduled arrival/departure times and the calculated ones is presented.
  • FIG. 13 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. non-removable 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. non-removable 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)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Economics (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • Human Resources & Organizations (AREA)
  • Development Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Mechanical Engineering (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Strategic Management (AREA)
  • Tourism & Hospitality (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Train Traffic Observation, Control, And Security (AREA)
  • Navigation (AREA)
EP12290452.7A 2012-12-20 2012-12-20 Bestimmung der Echtzeitverzögerung von Transportmitteln Withdrawn EP2747005A1 (de)

Priority Applications (9)

Application Number Priority Date Filing Date Title
EP12290452.7A EP2747005A1 (de) 2012-12-20 2012-12-20 Bestimmung der Echtzeitverzögerung von Transportmitteln
PCT/EP2013/003800 WO2014095029A1 (en) 2012-12-20 2013-12-16 Determining real-time delay of transportation means
SG11201502709UA SG11201502709UA (en) 2012-12-20 2013-12-16 Determining real-time delay of transportation means
KR1020157010055A KR20150100619A (ko) 2012-12-20 2013-12-16 운송 수단의 실시간 지연 판단
CA2885611A CA2885611C (en) 2012-12-20 2013-12-16 Determining real-time delay of transportation means
JP2015548276A JP6184516B2 (ja) 2012-12-20 2013-12-16 輸送手段の実時間遅延の決定
CN201380057919.8A CN104769618B (zh) 2012-12-20 2013-12-16 确定运输工具的实时延迟
IN2407DEN2015 IN2015DN02407A (de) 2012-12-20 2013-12-16
AU2013362167A AU2013362167B2 (en) 2012-12-20 2013-12-16 Determining real-time delay of transportation means

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP12290452.7A EP2747005A1 (de) 2012-12-20 2012-12-20 Bestimmung der Echtzeitverzögerung von Transportmitteln

Publications (1)

Publication Number Publication Date
EP2747005A1 true EP2747005A1 (de) 2014-06-25

Family

ID=47559215

Family Applications (1)

Application Number Title Priority Date Filing Date
EP12290452.7A Withdrawn EP2747005A1 (de) 2012-12-20 2012-12-20 Bestimmung der Echtzeitverzögerung von Transportmitteln

Country Status (1)

Country Link
EP (1) EP2747005A1 (de)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017155581A1 (en) * 2016-03-08 2017-09-14 Google Inc. Verification of pickup times in real-time ride-sharing feeds
CN107358302A (zh) * 2017-06-30 2017-11-17 上海爱优威软件开发有限公司 出行计划的管理方法
CN110979407A (zh) * 2019-12-26 2020-04-10 天津津航计算技术研究所 一种城轨列车时刻表群调整方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0644495A (ja) 1992-07-24 1994-02-18 Matsushita Electric Ind Co Ltd 到着時間表示装置
EP2065867A1 (de) * 2007-11-15 2009-06-03 Vodafone Holding GmbH Verfahren zur Bereitstellung von Transportzeitplaninformationen, mobiles Endgerät und Zentraleinheit
JP2010231303A (ja) * 2009-03-26 2010-10-14 Nec Corp 乗り換え案内システム
JP2012008957A (ja) * 2010-06-28 2012-01-12 Navitime Japan Co Ltd 位置特定システム、サーバ装置、端末装置、位置特定方法、および、プログラム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0644495A (ja) 1992-07-24 1994-02-18 Matsushita Electric Ind Co Ltd 到着時間表示装置
EP2065867A1 (de) * 2007-11-15 2009-06-03 Vodafone Holding GmbH Verfahren zur Bereitstellung von Transportzeitplaninformationen, mobiles Endgerät und Zentraleinheit
JP2010231303A (ja) * 2009-03-26 2010-10-14 Nec Corp 乗り換え案内システム
JP2012008957A (ja) * 2010-06-28 2012-01-12 Navitime Japan Co Ltd 位置特定システム、サーバ装置、端末装置、位置特定方法、および、プログラム

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017155581A1 (en) * 2016-03-08 2017-09-14 Google Inc. Verification of pickup times in real-time ride-sharing feeds
CN108701413A (zh) * 2016-03-08 2018-10-23 谷歌有限责任公司 在实时合乘馈送中验证接取时间
CN107358302A (zh) * 2017-06-30 2017-11-17 上海爱优威软件开发有限公司 出行计划的管理方法
CN110979407A (zh) * 2019-12-26 2020-04-10 天津津航计算技术研究所 一种城轨列车时刻表群调整方法
CN110979407B (zh) * 2019-12-26 2022-02-11 天津津航计算技术研究所 一种城轨列车时刻表群调整方法

Similar Documents

Publication Publication Date Title
AU2013362167B2 (en) Determining real-time delay of transportation means
US9024752B2 (en) Traveler hurry status monitor
CN102903256B (zh) 车辆导航方法和车辆导航系统
US20180040245A1 (en) Public transportation navigator
JP5438111B2 (ja) 運転者を少なくとも１人の同乗する人と自動的かつ直接的に接触させるための方法およびシステム
US8467957B2 (en) Method and apparatus for generating routes using real-time public transportation information
JP2019074990A (ja) 車両乗合支援システム
US20200034755A1 (en) Vehicle reservation system, vehicle reservation method, and non-transitory storage medium storing program
EP2747005A1 (de) Bestimmung der Echtzeitverzögerung von Transportmitteln
US9098995B2 (en) Determining real-time delay of transport
JP2006195673A (ja) 予約処理システム、予約処理方法、およびコンピュータプログラム
KR20140041124A (ko) 도착예정정보 자동 통보 장치 및 방법
CN108463390B (zh) 用于向车辆中的信息系统提供信息的系统和方法
KR101626235B1 (ko) 여행자 긴급 상태 모니터
JP2002234442A (ja) 行先ルート案内装置およびシステム
CN108473149B (zh) 用于在车辆的乘客车厢中显示消息的显示系统和方法
Shalaik et al. Delivering real-time bus tracking information on mobile devices
US20230343215A1 (en) Information transmission apparatus, information transmission method, and non-transitory computer-readable medium
CN117341773A (zh) 列车信息提示方法、装置、电子设备和存储介质
KR20120030755A (ko) 네비게이션 장치, 네비게이션 장치의 동작 방법 및 실시간 교통정보를 이용한 통합 스케쥴 안내 시스템

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20121220

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

RIN1 Information on inventor provided before grant (corrected)

Inventor name: MARAFIOTI, VINCENZO

Inventor name: SAVORNIN, RICHARD

Inventor name: CORDESSES, JOEL

R17P Request for examination filed (corrected)

Effective date: 20141126

RBV Designated contracting states (corrected)

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20180511

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20190822