EP3358532A1 - Procédé de détermination automatique de l'utilisation de véhicules - Google Patents

Procédé de détermination automatique de l'utilisation de véhicules Download PDF

Info

Publication number
EP3358532A1
EP3358532A1 EP17154545.2A EP17154545A EP3358532A1 EP 3358532 A1 EP3358532 A1 EP 3358532A1 EP 17154545 A EP17154545 A EP 17154545A EP 3358532 A1 EP3358532 A1 EP 3358532A1
Authority
EP
European Patent Office
Prior art keywords
vehicle
data
mobile terminal
terminal
central computer
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.)
Pending
Application number
EP17154545.2A
Other languages
German (de)
English (en)
Inventor
Manfred Feiter
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.)
Scheidt and Bachmann GmbH
Original Assignee
Scheidt and Bachmann GmbH
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 Scheidt and Bachmann GmbH filed Critical Scheidt and Bachmann GmbH
Priority to EP17154545.2A priority Critical patent/EP3358532A1/fr
Publication of EP3358532A1 publication Critical patent/EP3358532A1/fr
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B15/00—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points
    • G07B15/02—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points taking into account a variable factor such as distance or time, e.g. for passenger transport, parking systems or car rental systems

Definitions

  • the present invention relates to a method for automatically determining the use of vehicles. Essentially, it is about the automatic determination of the use of chargeable means of transport as a basis for the settlement of the fare. It is assumed that it is concluded from the presence of a mobile terminal in the vehicle on the use of the vehicle by a user. For several years, there are different approaches in the prior art to perform a fare accounting based on the technically detected presence of passengers in a vehicle. For this purpose, data is periodically and wirelessly exchanged between a vehicle infrastructure and a user terminal. This data can be recorded in the user terminal against a (previously loaded) driving value, or the data is transmitted to a central computer, and there the journey is determined and calculated the fare. These methods are known under the keyword "Be-In / Be-Out", in short "BIBO".
  • the disadvantage of the unidirectional BIBO method is that on the part of the vehicle infrastructure is not or at least not immediately known which user media are currently present in the vehicle; the drawback of BIBO bidirectional methods is that data message back-and-forth means a significant incidence of radio traffic in the vehicle, and that the transmission and reception operations of the vehicle infrastructure must be extensively synchronized to avoid signal collisions leading to data loss in relevant data Extent can lead.
  • BIBO methods can in principle be carried out with various types of user terminals. It is possible to use dedicated devices which are specifically set up to receive data telegrams from the vehicle infrastructure and possibly also to return data telegrams to the vehicle infrastructure. In any case, the user terminals must be able to communicate wirelessly with the vehicle infrastructure over a radio interface over a few meters distance. This assumes that the user terminals have their own power supply. Now, if dedicated user terminals are used, they must not only be specially manufactured for this purpose and distributed to the users, but it must also be ensured that the user terminals either have a sophisticated energy management, so that their power supply - usually over A battery - sufficient for a long time, or the user terminals must have a battery that needs to be recharged by the users.
  • Another advantage of using mass-market-available mobile terminals as a BIBO user terminal is that these terminals have a plurality of radio-based data interfaces that can be used for BIBO methods.
  • Another difficulty of all BIBO systems is that of securely determining that a user with a user terminal - be it a dedicated device for a ticketing system or a mass market-available mobile terminal - has made a particular trip. For this purpose, it must be determined with certainty that the user has been with his terminal over a sequence of times in a particular vehicle. The sequence of points in time represents the journey time. The route that the vehicle has covered is the route, which is generally the basis of the fare calculation.
  • a critical aspect is the possibility that vehicles - e.g. Buses, trams - at bus stoves, traffic lights or when driving side by side have such a small distance that a user terminal receives data telegrams from multiple vehicles at the same time.
  • the prior art discloses a number of methods for this purpose. So will in the EP 1 669 935 proposed a method in which a user terminal which receives data messages from multiple vehicles, determined based on the temporal change in the signal strength of the data telegrams, which data telegrams are "valid", ie derived from a vehicle in which the user really miter. This teaches the EP 1 669 935 determining the used vehicle by the user terminal in real time, that is while driving.
  • a BIBO method is proposed with mass-market-available mobile devices, in which with the use of sensors that is present in such devices, the whereabouts of the terminal - so eg the vehicle used - can be determined without the mobile terminal vehicle-specific data telegrams need to receive, ie it does not need to be built for a specific vehicle infrastructure.
  • This teaches the EP 2 658 291 A1 determining the vehicle being used by a central computer and thus not necessarily in real time.
  • the determination of the vehicle used without the terminal receives vehicle-specific data telegrams, not very accurate and therefore quite doubtable as the basis for a fare account.
  • the object of the invention is therefore to propose a robust method which makes it possible to determine the location of a mobile terminal in a vehicle and to ensure the authenticity of the data telegrams used for this purpose, even if the user terminals use open interfaces for the method.
  • At least one vehicle transmitter and at least one vehicle receiver are installed in a vehicle.
  • the at least one vehicle transmitter is set up to transmit on-board data telegrams wirelessly, which data telegrams uniquely identify the vehicle.
  • Data telegrams are modulated radio signals that contain digital data.
  • Vehicle data telegrams are those data telegrams whose digital data contain at least one unambiguous system-wide identifier of the vehicle whose vehicle transmitter has sent the telegrams.
  • External data telegrams are data telegrams whose digital data contain an identification of a vehicle but which are received in another vehicle.
  • a data telegram in the vehicle in which it was sent a vehicle data telegram, but if it is receivable in another vehicle, then it is a foreign data telegram.
  • foreign data telegrams can arise because data frames that are not belonging to this vehicle are abusively sent within a vehicle.
  • vehicle data telegrams may contain further data, such as e.g. Date / time stamp, random numbers and / or location data of the vehicle.
  • the at least one vehicle receiver is configured according to the invention to receive the vehicle's own and external data telegrams wirelessly and to further process the data contained therein and forward it to a vehicle-side communication device, which in turn is set up to exchange data with a central computer.
  • the vehicle-side communication device of the on-board computer of a vehicle so for example, the on-board computer of a bus, a tram, a subway, a train, a ship, a taxi or a comparable vehicle.
  • the vehicle-side communication device is known for the inventive method, the location of the vehicle;
  • the existing vehicle infrastructure is used to determine the location of the vehicle, which provides location data for the vehicle.
  • Location data may be latitude and longitude, distance kilometer for a journey, cell data from mobile communication networks in which the on-board communication device operates, tariff zones or other data sets whose geographical resolution is sufficiently fine to map the tariff system for the fare calculation.
  • Location data can thus be determined from global navigation satellite systems (such as GPS, Galileo, etc.), from vehicle range indicators, from beacons or beacons along the driveway, from triangulation data from mobile communication networks, or any other suitable method of locating.
  • the data communication between the vehicle-side communication device and the central computer can be permanently active or periodically activated or activated depending on the location of the vehicle or the number of received data telegrams.
  • the data communication can be based on one digital cellular network (GSM, GPRS, UMTS, LTE), a Wi-Fi connection, a Bluetooth pairing, an infrared connection or any other suitable wired or wireless data connection.
  • GSM digital cellular network
  • GPRS Globalstar
  • UMTS Long Term Evolution
  • LTE wireless Term Evolution
  • Wi-Fi connection Wireless Fidelity
  • Mobile terminals within the meaning of the invention are portable units with at least one digital data processor, a digital data memory, a power supply and communication means. Mobile terminals are set up to receive on-board and off-board data telegrams wirelessly, further processing the digital data contained therein and forwarding them to the central computer. Mobile terminals may be specifically designed and manufactured for the purpose of the method of the invention, or, in a preferred embodiment, may be mass-market mobile terminals such as smartphones, tablet computers, game consoles, laptop computers, netbooks, data glasses, smart watches, or the like other body-worn devices, etc.
  • the data communication between a mobile terminal and the central computer can be permanently active or periodically activated or activated depending on the location of the terminal or the number of received data telegrams.
  • the data communication can be based on a digital mobile radio network (GSM, GPRS, UMTS, LTE) or on a local radio data network such as a WLAN, Bluetooth or Bluetooth Low Energy (BLE) connection (via a vehicle relay station, which in turn communicates with the Central computer communicates) or on any other suitable wireless data connection.
  • GSM digital mobile radio network
  • GPRS Global System for Mobile Communications
  • UMTS Long Term Evolution
  • LTE local radio data network
  • BLE Bluetooth Low Energy
  • the further processing of the received data by the at least one vehicle receiver and the mobile terminals may include the following: the data remains unchanged, the data is supplemented with device-specific or other data received or generated by the device (eg user of the device, telephone number of the device, Time, location, checksum, counter readings), encrypting the data, masking the data (so-called "hash"), saving the data or applying other data processing mechanisms commonly used in information technology to the data, and any combination of such manipulations.
  • Non-vehicle transmitters that transmit foreign data telegrams.
  • These third-party transmitters can be present in the vehicle itself, for example by trying to deceive users to bother or sabotage the BIBO system.
  • the vehicle-external transmitter can also be present outside of the vehicle, for example caused by two buses that are equipped with the BIBO system according to the invention, stand side by side at a traffic light or drive on two lanes side by side. It is essential to the process that the foreign data telegrams can be received in the same way by the mobile terminals and the at least one vehicle receiver. It may be the case that the foreign data telegrams contain digital foreign data that can be handled by the mobile terminals and the at least one vehicle receiver in the same way as the digital vehicle data.
  • the mobile terminals can also receive foreign data telegrams and do not need to "know” and also do not need to "know” that these signals are foreign to the vehicle because the mobile terminals "do not know” in which vehicle they are.
  • At least one vehicle transmitter repeatedly transmits vehicle data telegrams in a vehicle. These vehicle data telegrams are at least partially received by the at least one vehicle receiver, ie at least one vehicle receiver receives at least one complete vehicle data telegram. From the received vehicle data telegrams, the vehicle receiver reads out the digital vehicle data contained therein.
  • the digital vehicle data from the vehicle data telegrams contain a time specification (eg date and time) or they are supplemented by the vehicle receiver or the on-board computer with a current time specification. Furthermore, the vehicle receiver or the on-board computer supplements the data with a system-wide unique identifier of the own vehicle and the location of the vehicle.
  • the Vehicle receiver or the on-board computer forwards the digital vehicle reference data records to the vehicle-side communication device.
  • the vehicle receiver and the vehicle-side communication device are networked with regard to data technology. This networking preferably uses an existing on-board network of the vehicle and may be, for example, a wired LAN, a data bus, a CAN bus, a WLAN, or any other suitable wired or wireless data connection within the vehicle.
  • vehicle receiver and / or vehicle-side communication device can also be components of the on-board computer.
  • a "vehicle” within the meaning of the invention may also be a segment of a means of transport, such as e.g. a wagon having at least one vehicle transmitter and at least one vehicle receiver. A train of several wagons is thus several "vehicles" within the meaning of the invention.
  • the transmission of the vehicle data telegrams by the vehicle transmitter takes place wirelessly in a data radio network for which the mobile terminals are also set up, for example: Bluetooth, Bluetooth Low Energy, WLAN, ANT, WiMax, WPAN, ZigBee or Z-Wave.
  • the frequency with which the at least one vehicle transmitter transmits vehicle data telegrams determines the amount of data resulting from the execution of the method according to the invention and thus also the network load in all networks involved in the method.
  • more data telegrams do not necessarily lead to a better BIBO method (ie to better determine the residence of users in a vehicle). This is especially the case if nobody can get on or off anyway.
  • the at least one vehicle transmitter may emit data messages less frequently, whereas in situations where passengers may currently be getting on or off or may just be getting in or out, more frequent transmission of vehicle data messages is particularly meaningful.
  • the repeated transmission of vehicle data telegrams by the at least one vehicle transmitter within the meaning of the invention can mean: transmission with constant time intervals between two Transmissions, emitting at variable time intervals between two transmissions, transmitting at time intervals that are dependent on at least one of the following exemplary criteria: travel speed, location of the vehicle within the fare area of a fare system, vehicle fare levels reaching or exceeding fare zone boundaries, state of the vehicle doors ("on” or “to” or just closed, where "just closed” means a time of a few seconds after closing the last vehicle door, typically up to 5 seconds) and a combination of such and / or other criteria.
  • the on-board communication device sends the obtained digital vehicle reference data records to the central computer. This can be done in real time, ie immediately after the vehicle-side communication device has received a vehicle reference data record from one of the vehicle receivers, in quasi real-time, which is to be understood here as meaning that between receiving a data telegram and sending the vehicle reference data record up to X. Minutes to pass. Furthermore, the transmission of a vehicle reference data record by the vehicle-side communication device can take place with a time delay, which is to be understood here as meaning that more than X minutes elapse between receiving a data telegram and transmitting the vehicle reference data record.
  • the vehicle-side communication device can buffer the vehicle reference data records and thus send a plurality of vehicle reference data records bundled to the central computer.
  • the vehicle reference data records which the central computer receives from the vehicle-side communication device are stored there in at least one database.
  • the central computer receives from a variety of vehicles corresponding vehicle reference data sets.
  • the vehicle receiver processes the received foreign data telegrams in exactly the same way as the received vehicle data telegrams:
  • the digital external data from the foreign data telegrams contain a time indication (eg date and time) or they become supplemented by the vehicle receiver or the on-board computer with a current time.
  • a time indication eg date and time
  • the vehicle receiver or the on-board computer adds the data with the unique identifier of the own vehicle and the location of the own vehicle. From a received foreign data telegram is thus a digital foreign data set, but in any case provided with the identifier of the own vehicle, so that vehicle in which the vehicle receiver is installed.
  • vehicle reference data sets have been created from the received foreign data telegrams, which in turn are sent to the central computer in the manner described above and stored there in the at least one database.
  • vehicle receivers If several vehicle receivers are present in a vehicle, they will almost always receive identical data telegrams (vehicle-own and non-vehicle). Exceptions are based on such data telegrams, which were receivable as for a vehicle receiver, for another vehicle receiver in the same vehicle but not. Thus, a plurality of vehicle receivers in a vehicle will generate a large number of identical vehicle reference records ("doublets") for forwarding to the central computer. According to the invention, it is therefore proposed to first save the data sets of all the vehicle receivers installed in a vehicle to reduce the data volume and the network load in the on-board computer of the vehicle, to delete duplicates and then to send the remaining data records as described to the central computer.
  • At least one vehicle transmitter repeatedly transmits vehicle data telegrams.
  • vehicle data messages are at least partially received by a mobile terminal of a user, ie the mobile terminal receives at least a complete vehicle data message.
  • the mobile terminal reads out the digital vehicle data contained therein.
  • the digital vehicle data from the vehicle data telegrams contain a time specification (eg date and time) or they are supplemented by the mobile terminal with a current time specification; Further, the digital vehicle data may include the vehicle location.
  • the mobile terminal complements the data with its system-wide unique identifier. From the data of a received vehicle data telegram is thus created a digital terminal record.
  • the system-wide unique identifier of the mobile terminal may be a mobile telephone number, a mobile telephone ID, an International Mobile Station Equipment Identity (IMEI) number, a Media Access Control Address (also known as an Ethernet ID) , Airport ID or WiFi ID), a Bluetooth MAC address, a user ID, under which a user leads his user account in the fare management system, a user ID, under which a user uses his BIBO app, with which the method according to the invention is carried out. registered, a user ID under which the BIBO app was acquired, or any other system-wide unique identifier that allows the mobile terminal to be identified.
  • IMEI International Mobile Station Equipment Identity
  • a Media Access Control Address also known as an Ethernet ID
  • Airport ID or WiFi ID Wireless Fidelity
  • Bluetooth MAC address a Bluetooth MAC address
  • the mobile terminal can supplement the digital vehicle data record with its own location data in order to support the subsequent trip reconstruction in the central computer with these data.
  • This supplement of the digital vehicle data records can be made by the mobile terminal for each data record or only for a part of the data records, for example when switching on the BIBO app or when receiving a first data message with a new vehicle identifier or periodically, for example every 5 minutes, or periodically after a certain number of received data telegrams, for example every tenth data telegram.
  • Location data of the mobile terminal may be longitude and latitude, or cell data from mobile communication networks in which the mobile terminal is operated, or other location data, as can be determined from the equipment of the mobile terminal.
  • Location data may thus be determined from global navigation satellite systems (such as GPS, Galileo, etc.), from triangulation data from mobile communication networks, from field strength data and / or access points from mobile communication networks, from access points or SSID information from WLAN or Bluetooth networks, or anyone other location method available in the mobile terminal.
  • global navigation satellite systems such as GPS, Galileo, etc.
  • the mobile terminal sends the terminal records to the central computer. This can be done in real time, ie immediately after the mobile terminal has received a data telegram, in quasi-real time, which is to be understood here, that between the reception of a data telegram and the transmission of the terminal record up to X minutes elapse time. Furthermore, the transmission of a terminal record by the mobile terminal can be done with a time delay, This is to be understood here as meaning that more than X minutes elapse between receiving a data telegram and sending the terminal data record.
  • the mobile terminal may cache the terminal records and thus send a plurality of terminal records bundled to the host. This is the case in particular when the data connection between the mobile terminal and the central computer is not permanently active.
  • the terminal records that the central computer receives from the mobile terminal are stored there in the at least one database.
  • the central computer receives from a variety of mobile devices corresponding terminal data sets.
  • the mobile terminal processes the received foreign data telegrams in exactly the same way as the received vehicle data telegrams:
  • the digital foreign data from the foreign data telegrams contain or be timed (eg date and time) supplemented by the mobile terminal with a current time.
  • the mobile terminal complements the data with its unique identifier. From the received foreign data telegrams so digital terminal records are created, provided with the identifier of the mobile terminal, which in turn sent in the manner described above to the central computer and stored there in the at least one database.
  • a mobile terminal and a vehicle receiver in the same vehicle will not always receive exactly the same data telegrams; However, they will receive so many identical data telegrams that it can be inferred in the central computer (based on the terminal data sets and the vehicle reference records) safe on the presence of the mobile terminal in the vehicle.
  • the central computer receives vehicle reference data records from all vehicles involved in the method as soon as their vehicle-side communication units send data records and the data records can be received by the external vehicle data network for the central computer. Furthermore, the central computer receives terminal data sets from all the mobile terminals involved in the method as soon as these mobile terminals send data records and transmit the data records via the mobile data network for the mobile terminal Central computer are receivable.
  • the central computer it is now determined for each mobile terminal in which vehicle it drove when and where.
  • the concatenation of temporally successive locations of a mobile terminal in a moving vehicle thus represents a ride that can be billed.
  • the billing can be done, for example, against a run on the central computer fare account or a permanent ticket stored there, or the ride is charged to the user. Details of the actual fare statement are not the subject of the invention.
  • the central computer in the sense of the method according to the invention can physically consist of one or more computer units (servers) and databases which are set up in one location or at several geographical locations and connected to each other in terms of data network.
  • the at least one geographical location of the central computer is not relevant according to the method;
  • the central computer and its at least one database can be part of at least one data center.
  • the central computer and its at least one database can be set up as a virtual server.
  • the central computer and its at least one database can be addressed via Internet interfaces and set up as "cloud" implementation.
  • At least one database of the central computer there is in the at least one database of the central computer, a plurality of terminal data records that come from a variety of mobile terminals. Further, in the at least one database of the central computer, there are a plurality of vehicle reference data sets originating from a plurality of vehicles.
  • a time sequence of locations at which the terminal has most probably lingered is now reconstructed by comparing the associated terminal data records with all available vehicle reference data records. For each terminal record is determined whether there is a simultaneous vehicle reference record and whether both records come from the same received data message. Each match indicates that a vehicle receiver and the mobile terminal could "hear" the same data telegram at the same time. It is irrelevant whether the data telegram in question originated from the vehicle itself or was foreign to the vehicle.
  • This comparison is performed with all stored in the at least one database, not yet a trip associated terminal records of a mobile terminal and has the result of a temporal sequence of identical data telegrams that a vehicle receiver and the mobile terminal at the same time the same data telegram "hear " could. From a plurality of matches, it is clear that the mobile terminal has raced in a certain vehicle, and from the timestamps and the sequence of vehicle locations (from the vehicle reference datasets) it can be concretely determined when the mobile terminal has traveled from where to where , This is a concrete ride for a specific terminal reconstructed and can be billed.
  • the comparison of the data sets of the terminals and the vehicle reference data records can be carried out, for example, via correlation, regression and / or feature analyzes / vectors and corresponding classifiers such as Bayes classifier, maximum likelihood methods and / or via artificial neural networks.
  • the inventive trip reconstruction on the central computer for each mobile device used is thus in a special way "robust" and insensitive to possible external data telegrams that a terminal potentially receives because the vehicle reference data records the central computer is known, which - including non-vehicle - data telegrams to the include reconstructed ride.
  • the central computer may begin to reconstruct the terminal by reconciling the records. If the terminal data sets and vehicle reference data records are sent to the central computer in "real time", that is to say while driving, then the latter can detect the stay of the mobile terminal in the vehicle while driving and a look-up table to the mobile terminal send at least once.
  • the look-up table can contain data about the current journey from a computer-aided operations control system, which is executed in the central computer. From this, the app can extract current travel information on the mobile terminal and display it to the user on the mobile terminal.
  • the look-up table may contain, for example, data on the sequence of breakpoints in the current journey, the names of the breakpoints, expected arrival times of the vehicle at the breakpoints, achievable connection connections, weather data, warning data on weather or road conditions, etc. These data are the user of the app can be displayed as trip information.
  • the data in the look-up table can be static (for example from the timetable) or dynamic (on the current operational data of the operations control system) or a combination of static and dynamic data.
  • the look-up table can be sent to the mobile Be sent once during a trip or be updated several times. Updates may be made by sending a complete updated look-up table to the mobile device or by incrementally updating parts of the look-up table. In particular, the look-up table may be updated if the trip reconstruction on the background system determines that the mobile terminal has switched from one vehicle to another.
  • vehicle data telegrams contain in their digital data a system-wide unambiguous identifier of the vehicle whose vehicle transmitter has sent the telegrams.
  • these digital data contain a code.
  • This code can be a numeric number, a combination of letters, a mixture of numbers and letters, or any data content that is otherwise suitable for data transmission, or a combination of ASCII characters.
  • the code can originate from a random number generator and can be regenerated time-dependently (for example every X minutes) or after a certain number X of data telegrams, possibly individually for each data telegram.
  • the code may be generated from state data, for example from the current location data of the vehicle, e.g. as a hash value from the latitude and longitude of the vehicle location or from the route.
  • the code may be generated from a date / time stamp, e.g. as a hash value from it.
  • This code is used to verify the authenticity of the vehicle data telegrams received from the mobile terminals and the at least one vehicle receiver in the central computer. This prevents misplaced transmitters from transmitting false data telegrams, which may not be recognized as such by the central computer.
  • the central computer checks the received terminal data records and vehicle reference data records for the presence of the correct code, and the positively checked data records are regarded as authentic and used for the trip reconstruction described above. Negatively checked records are neglected for trip reconstruction.
  • the authenticity check according to the invention becomes particularly secure when the codes are changed frequently.
  • the authenticity check is then based not on the coincidence of one or a few codes in a plurality of terminal and vehicle reference data sets, but on a succession of frequently varied codes, so that good procedural security is achieved even with relatively short codes.
  • Bluetooth transmitters which are set up in a particularly preferred embodiment as so-called Bluetooth low energy beacons (“BLE beacons”) are used as the vehicle transmitter for the method according to the invention.
  • BLE beacons have the advantage of being inexpensive and available on the mass market.
  • this entails the disadvantage that BLE beacons may be improperly introduced into a vehicle by third parties and send out nonauthentic data telegrams. This disadvantage is counteracted in the manner described above by a code in the data contents of the data telegrams.
  • BLE beacons can be divided into two types: first BLE beacons, whose data telegrams are receivable for a mobile terminal with a standard operating system in all operating modes, and second BLE beacons, for which a mobile terminal first has to be configured to receive it Can receive data telegrams.
  • commercially available operating systems are at least to be understood as meaning Apple iOS, Google Android, Microsoft Windows Mobile, Microsoft Mobile Phone, Blackberry OS, Symbian OS, Firefox OS, Tizen, Aliyun OS and their respective successors and advancements.
  • receiving data telegrams sent in the Bluetooth wireless network presupposes that the Bluetooth function is activated (activated) at the respective mobile terminal.
  • the data of the at least one first beacon identifies a UUID of the second vehicle transmitter, which is also implemented as a BLE beacon.
  • the UUID of the second vehicle transmitter may be formed as a function of a hash value of the variable data of the first vehicle data message.
  • At least one second BLE beacon as the second vehicle transmitter, repeatedly transmits via the BLE data protocol second vehicle data telegrams which are then receivable for mobile terminals if they have previously received at least one associated first vehicle data telegram.
  • the second vehicle data telegrams contain at least one code.
  • This code can be a numeric number, a combination of letters, a mixture of numbers and letters, or any other code or combination of ASCII characters.
  • the code can come from a random number generator and be re-generated time-dependently (eg every X minutes) or after a certain number X of data telegrams, if necessary individually for each data telegram.
  • the code can be generated from state data, for example from the current location data of the vehicle, for example as a hash value from the latitude and longitude of the vehicle location or from the route.
  • the code may be generated from a date / time stamp, eg as a hash value therefrom.
  • the second vehicle data telegrams may contain data about the traveled distance of the vehicle, such as a travel counter. When the maximum counter value is exceeded, the counter is restarted at the value 0.
  • the second vehicle data telegrams can contain any combination of data which can be used for the secure performance of the method according to the invention and which can be displayed within the available data volume in the BLE radio data signal.
  • both vehicle transmitters ie both BLE beacons
  • the on-board computer of the vehicle which performs the modification of the data contents for both the first and second vehicle data telegrams and dynamically configures the UUID of the second vehicle transmitter to be of a method according to the method App can be taken from the first vehicle data telegrams.
  • the app also receives non-vehicle first data telegrams and searches in the sequence for non-vehicle second data telegrams.
  • the app of the mobile terminal writes a log file in which the sequence of the extracted data from the received data telegrams, provided with a time stamp, is logged.
  • the app of the mobile device forwards this data from the log file (in-vehicle as well as non-vehicle data) as terminal data records in the manner described above to the central computer.
  • a vehicle receiver installed in the vehicle may extract the data from received first and second vehicle data plots, log it with timestamp, and pass it to the central computer as vehicle reference records as described above.
  • the invention further proposes that the data of the at least one first beacon be varied according to the method in each case. If this were not the case, an attack on the system could be started by a perpetrator listening to the (in this case, constant) data content of a first beacon and replicating a system according to the invention with forged beacons and - for example - generating trips under a wrong operator number.
  • the data of the at least one first beacon is varied, the logical link between the first and second beacons is always recreated (coordinated by the on-board computer).
  • the data of the at least one first beacon included as above mentioned - data for driving record such as the operator number (a systemic connoisseur for the transport company), the vehicle number, a reference to the look-up table, the journey number (eg bus, train number, etc), direction of travel, the number of the next breakpoint ,
  • these data are static, eg only the operator number and the vehicle number, because, for example, the vehicle infrastructure does not provide dynamic driving data.
  • it is proposed to vary the data of the at least one first beacon eg with a time-variable random number or the hash of a date / time stamp or the like.
  • the invention provides a method and a system with which the presence of a terminal and thus of the terminal equipped user in a vehicle can be determined automatically. It can thus be determined automatically in a simple manner, the use of the means of transport in relation to the mobile station and its users and then the required processing for color price calculation and the like are performed. Further advantages and features of the description will become apparent from the following description with reference to FIGS.
  • FIG. 1 an example is given of a system 100 in which the method according to the invention is applied.
  • the example describes the embodiment with BLE beacons.
  • Installed in a bus 101 with the vehicle number "4711" are: a first vehicle transmitter 102, a second vehicle transmitter 103, and a vehicle receiver 104.
  • the two vehicle transmitters 102, 103 are each configured as BLE beacons; the vehicle receiver 104 is configured to receive radio signals from both vehicle transmitters.
  • the first vehicle transmitter 102 is embodied as a so-called iBeacon, whose radio signals for a mobile terminal with the iOS operating system are receivable by default and without special configuration as soon as the Bluetooth network is switched on at the terminal. That the mobile terminal is in the so-called "monitoring" mode for iBeacons when its Bluetooth network is switched on.
  • the second vehicle transmitter 103 is a so-called travel beacon whose radio signals for a mobile terminal can only be received if the terminal has been configured accordingly.
  • the two vehicle transmitters 102, 103 and the vehicle receiver 104 are connected in terms of data network with an on-board computer 105, which in turn is connected to a vehicle-side communication unit 106 in terms of data network.
  • the on-board computer 105 is connected to a GPS receiver 107 in terms of data network, so that in the on-board computer 105 the current location of the bus 101 is known as location data (longitude and latitude).
  • the on-vehicle communication unit 106 is connected to a central computer 109 via a external vehicle data network 108 data network connected, in this example via a digital mobile network.
  • the vehicle contains mobile terminals 110 of users whose journey is to be recorded and billed later.
  • the mobile terminals 110 are network connected to the central computer 109 via a mobile data network 111.
  • the mobile data network 111 may be the same data network as the external vehicle data network 108.
  • the mobile terminals 110 are operated with the iOS operating system.
  • the first vehicle transmitter 102 periodically transmits a first vehicle data telegram 301.1 as an iBeacon radio signal (the content of this first vehicle data telegram is shown in FIG Fig. 2 illustrated).
  • a mobile terminal 110 receives at least a first vehicle data message and starts a pre-installed app to participate in the automated BIBO procedure.
  • the mobile terminal 110 After receiving the first vehicle data telegram 301.1, the mobile terminal 110 is configured to search for second vehicle data telegrams such that the app on the mobile terminal continuously scans for second vehicle data telegrams.
  • the second vehicle transmitter 103 periodically transmits a second vehicle data telegram 302.1 (the content of this second vehicle data telegram is in FIG Fig. 2 illustrated).
  • a mobile terminal 110 receives this second vehicle data telegram 302.1 and further of the periodically transmitted second vehicle data telegrams 302.1.
  • the mobile terminal continues to "monitor" the periodically transmitted first vehicle data telegram 301.1, ie after iBeacon radio signals, and also receives these.
  • the further bus 201 has in the same way a first vehicle transmitter 202 and a second vehicle transmitter 203. These transmit in the same way periodically vehicle data telegrams, which for the driving detection in bus 101 "vehicle " are. These foreign data telegrams 301.2, 302.2 are received by the mobile terminal in exactly the same way as the vehicle data telegrams 301.1, 302.1.
  • the app of the mobile terminal 110 extracts data from the received vehicle data telegrams 301.1, 302.1 and the foreign data telegrams 301.2, 302.2. From the extracted data, the app writes a first log file in which the sequence of digital data from the received data telegrams 301.1, 302.1, 301.2, 302.2 is logged. The app of the terminal 110 forwards this data from the first log file (in-vehicle and non-vehicle data) as terminal data records 400 via the mobile data network 111 to the central computer 109. The app does this as soon as 100 data telegrams 302.1, 302.2 of the second vehicle transmitter 103, 203 have been received, but at the latest every ten minutes.
  • the app sends only those terminal records 400 to the central computer 109, which have not yet been sent.
  • each record sent to the central computer 109 is marked with a connoisseur, so that it is not sent a second time.
  • the content of the terminal records 400 is stored in Fig. 4 illustrated).
  • the vehicle receiver 104 receives the vehicle data telegrams 301.1, 302.1 and foreign data telegrams 301.2, 302.2. It extracts data from the received data telegrams and forwards them to the on-board computer 105.
  • the on-board computer 105 writes with these data a second log file in which the sequence of digital data from the received data telegrams 301.1, 302.1, 301.2, 302.2 is logged.
  • the second log file is stored and managed in the on-board computer 105.
  • the on-board computer 105 provides each entry in the second log file with the current location of the vehicle, which is determined via a GPS receiver 107.
  • the on-board computer causes the vehicle-side communication unit 106 to forward this data from the second log file (in-vehicle and non-vehicle data) to the central computer 109 as vehicle reference data records 500 via the external vehicle data network 108.
  • the on-board computer 105 does this as soon as 100 data telegrams 302.1, 302.2 of the second vehicle transmitter 103, 203 are received but not later than every ten minutes. In this case, the on-board computer 105 sends only the data contents of such data telegrams to the central computer 109, which have not yet been sent.
  • each record sent to the central computer 109 is marked with a connoisseur, so that it is not sent a second time. (The content of the vehicle reference records 500 is displayed in Fig. 5 illustrated).
  • the central computer 109 Once the central computer 109 has received terminal records 400 and vehicle reference records 500, it begins the trip reconstruction for the terminal 110 by reconciling the records 400, 500.
  • the terminal records 400 and vehicle reference records 500 are sent in real-time to the host 109 so that it detects the stay of the terminal 110 in bus 101 while still driving and sends a look-up table 600 to the mobile terminal 110.
  • the look-up table contains data about the current trip from a computer-aided operational control system, which is executed in the central computer 109. From this, the app extracts trip information on the mobile device and displays it to the user on the mobile device.
  • FIG. 2 describes the structure of a first and a second vehicle data telegram for the embodiment.
  • the first vehicle data telegram 301 originates from an iBeacon. It is therefore receivable for mobile devices with the iOS operating system, without them having to be specially configured for this; only the Bluetooth radio network must be activated at the respective terminal.
  • the first vehicle data telegram 301 contains a UUID 303 according to the iBeacon standard (16-byte data length) and so-called major and minor data 304 according to the iBeacon standard (4-byte data length).
  • the UUID data 303 is selected so that a mobile terminal recognizes first vehicle data telegrams 301 as originating from an iBeacon, i. they comply with the iBeacon standard.
  • the major and minor data 304 are freely configurable, and the iBeacon receives this data through a data network connection from the on-board computer of the bus.
  • the major and minor data 304 identifies the service UUID 305 of the second vehicle transmitter.
  • the serviceUUID 305 of the second vehicle transmitter is formed as a function of a hash value from the major and minor data 304.
  • the on-board computer which generates the major and minor data 304 for the first vehicle transmitter (the iBeacon), also configures the second vehicle transmitter (the travel beacon), after whose second data telegrams 302 the app searches via a data network connection.
  • the second vehicle data telegram 302 includes a service UUID 305 formed from the major and minor data 304 according to the function of the hash value; the second vehicle data telegrams 302 can thus be found and received by the app in accordance with what has been said above.
  • the second vehicle data telegrams 302 contain as user data for the driver recognition a GeoLog 306 of 4 bytes in length and a RunCounter of 2 bytes in length.
  • GeoLog 306 is formed from a hash value of the current location of the vehicle.
  • GeoLog 306 represents the code contained in the vehicle data message in the sense of the above description; in the embodiment, the code is thus location-dependent.
  • RunCounter 307 maps the travel path of the bus in multiples of 100 meters. When the maximum counter value is exceeded, the RunCounter is restarted at the value 0. The app on the mobile device also extracts this data; They also become part of the data the app writes in the first log file.
  • the vehicle receiver also receives first and second data telegrams 301, 302. It also extracts from the major and minor values 304, from the GeoLog 306 and from the RunCounter 307 data for driving registration; These become part of the data that the on-board computer writes to the second log file.
  • FIG. 3 describes the exemplary reception of a sequence of 9 vehicle data messages by a mobile terminal and by the vehicle receiver.
  • the mobile terminal is located in bus "4711"; the vehicle receiver is that of the bus "4711".
  • the vehicle receiver is that of the bus "4711”.
  • Fig. 3 the mobile terminal first receives a first data telegram 301.1 from the iBeacon of the bus "4711”. It now scans for associated travel beacons and receives two second data telegrams 302.1 of the bus "4711". (Data telegrams # 1 - 3 off FIG. 3 ).
  • the on-board computer of the bus changes the random number in the major and minor values of the iBeacon and the associated ServiceUUID of the Travelbeacon.
  • the data telegrams of the iBeacon change.
  • the mobile terminal receives such a modified first data telegram 301.1 and then two further second data telegrams 302.1. (Data telegrams # 4 - 6 off FIG. 3 )
  • Bus “0815” comes close to the used bus "4711", and its data telegrams are receivable in bus "4711".
  • the mobile terminal receives a first data telegram 301.2 from the iBeacon of the bus "0815”. It now scans for associated travel beacons and receives a second data telegram 302.2 of the bus "0815”. (Data telegrams # 7 - 8 off FIG. 3 ).
  • the mobile terminal again receives a first data telegram 301.1 from the iBeacon of the bus "4711”. It now scans again for associated Travelbeacons from bus "4711". (Data telegram # 9 off FIG. 3 ).
  • the mobile terminal searches for associated second data telegrams 302 (from Travel Beacons). Conversely, no second data telegram 302 from a Travelbeacon are received, if not before the associated first data telegram 301 has been received from an iBeacon.
  • the mobile terminal for first data telegrams 301 of iBeacons is always ready to receive according to the Bluetooth standard for the iOS operating system, provided, of course, that its Bluetooth radio network is switched on.
  • the vehicle receiver in the exemplary embodiment receives these nine data telegrams.
  • FIG. 4 shows the exemplary data content of five terminal records 400 for the embodiment.
  • the mobile terminal has received a total of nine data telegrams, namely four first data telegrams (from an iBeacon) and five second data telegrams from a Travelbeacon.
  • the data required for the trip reconstruction were partly contained in the first data telegrams and partly in the second data telegrams.
  • This means that a mobile terminal can only create and send to the central computer 400 as many terminal data records as it has received second data telegrams, because only the receipt of a second data telegram provides the database for a complete terminal record 400.
  • the mobile terminal From the in Fig. 3 received data telegrams, the mobile terminal now creates the terminal records 400 according to Fig. 4 ,
  • the terminal record 400 consists partly of received data 401 and partly of own data of the terminal 402.
  • the mobile terminal app extracts, according to the example, the data of received GeoLog 403, received RunCounter 404 and received vehicle number 405 (all shown in decimal notation). This data is supplemented with data which the mobile terminal attaches, here the device number 406 (in the example: the telephone number) and a date / time stamp 407. According to the exemplary embodiment, this data represents the core of the data content of the terminal data sets 400 It will be apparent to those skilled in the art that terminal data sets may in practice contain other, additional or fewer data fields.
  • the terminal record 499 is from the last received second data message (from the adjacent bus "0815"). Therefore, the value of RunCounter 404 jumps at record 499 compared to the other values, and the receiving vehicle number 405 is different at record 499 than in the other records.
  • FIG. 5 shows the exemplary data content of five vehicle reference records 500 for the embodiment.
  • an on-board computer of a vehicle can only create as many vehicle reference data sets 500 and send it to the central computer as it has received second data telegrams.
  • the vehicle reference data record 500 consists partly of received data 501 and partly of own data of the vehicle 502.
  • the on-board computer extracts, according to the example, the data of received GeoLog 503, received RunCounter 504, and received vehicle number 505 (all shown in decimal notation). This data is supplemented with data attached by the on-board computer, here the own GeoLog 506, the own RunCounter 507, the own vehicle number 508 (all shown in decimal notation), the own location data 509 and a date / time stamp 510.
  • vehicle reference data sets may in practice include other, additional or fewer data fields.
  • the vehicle receiver receives exactly the same data telegrams as a mobile terminal, then the received data 501 in the vehicle reference data sets 500 is equal to the received data 401 in the terminal data sets 400.
  • Vehicle reference record 599 is from the last received second data message (from adjacent bus "0815"). That's why the dodge RunCounter 504 and the received vehicle number 505 are received from the respective own data of the vehicle 507, 508.
EP17154545.2A 2017-02-03 2017-02-03 Procédé de détermination automatique de l'utilisation de véhicules Pending EP3358532A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP17154545.2A EP3358532A1 (fr) 2017-02-03 2017-02-03 Procédé de détermination automatique de l'utilisation de véhicules

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP17154545.2A EP3358532A1 (fr) 2017-02-03 2017-02-03 Procédé de détermination automatique de l'utilisation de véhicules

Publications (1)

Publication Number Publication Date
EP3358532A1 true EP3358532A1 (fr) 2018-08-08

Family

ID=58158770

Family Applications (1)

Application Number Title Priority Date Filing Date
EP17154545.2A Pending EP3358532A1 (fr) 2017-02-03 2017-02-03 Procédé de détermination automatique de l'utilisation de véhicules

Country Status (1)

Country Link
EP (1) EP3358532A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4120212A1 (fr) * 2021-07-16 2023-01-18 Deutsche Telekom AG Procédé de détection de la présence et/ou de l'enregistrement d'événement dans un lieu ou dans une zone spatiale, système de détection de la présence et/ou de l'enregistrement d'événement, module radio courte portée fixe ou module radio courte portée mobile, programme informatique, support lisible par ordinateur

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19957660A1 (de) 1998-11-30 2000-07-20 Albrecht Joachim Verfahren zur Abrechnung des Fahrpreises bei der Benutzung öffentlicher Verkehrsmittel
EP1667074A1 (fr) 2004-12-02 2006-06-07 mcity GmbH Méthode automatique de détecter l'utilisation des vehicules payants et de facturer le prix du voyage
DE102012101638A1 (de) * 2012-02-29 2013-08-29 Rainer Söllner Verfahren und System zur Übermittlung von Verkehrsmittel-/Fahrstreckendaten in einem Verkehrsmittel an ein Mobilfunkgerät und zur Ermittlung von abrechnungsrelevanten Daten
EP2658291A1 (fr) 2012-04-24 2013-10-30 Scheidt & Bachmann GmbH Procédé de détermination automatique du lieu de résidence d'une personne
EP2657900A1 (fr) 2012-04-24 2013-10-30 Scheidt & Bachmann GmbH Procédé de détermination automatique d'informations utiles
EP2811444A1 (fr) * 2013-06-07 2014-12-10 Scheidt & Bachmann GmbH Procédé et dispositif de détermination de l'utilisation d'un service d'un moyen de transport public
US20150235477A1 (en) * 2014-02-19 2015-08-20 Swyft Technologies Inc. Automatic Wireless Transportation Monitoring and Transactions for Mobile Devices
US20150348334A1 (en) * 2014-05-29 2015-12-03 Mastercard International Incorporated Travel data of transport system users

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19957660A1 (de) 1998-11-30 2000-07-20 Albrecht Joachim Verfahren zur Abrechnung des Fahrpreises bei der Benutzung öffentlicher Verkehrsmittel
EP1667074A1 (fr) 2004-12-02 2006-06-07 mcity GmbH Méthode automatique de détecter l'utilisation des vehicules payants et de facturer le prix du voyage
EP1669935A1 (fr) 2004-12-02 2006-06-14 mcity GmbH Méthode automatique de détecter l'utilisation des vehicules payants et de facturer le prix du voyage
DE102012101638A1 (de) * 2012-02-29 2013-08-29 Rainer Söllner Verfahren und System zur Übermittlung von Verkehrsmittel-/Fahrstreckendaten in einem Verkehrsmittel an ein Mobilfunkgerät und zur Ermittlung von abrechnungsrelevanten Daten
EP2658291A1 (fr) 2012-04-24 2013-10-30 Scheidt & Bachmann GmbH Procédé de détermination automatique du lieu de résidence d'une personne
EP2657900A1 (fr) 2012-04-24 2013-10-30 Scheidt & Bachmann GmbH Procédé de détermination automatique d'informations utiles
EP2811444A1 (fr) * 2013-06-07 2014-12-10 Scheidt & Bachmann GmbH Procédé et dispositif de détermination de l'utilisation d'un service d'un moyen de transport public
US20150235477A1 (en) * 2014-02-19 2015-08-20 Swyft Technologies Inc. Automatic Wireless Transportation Monitoring and Transactions for Mobile Devices
US20150348334A1 (en) * 2014-05-29 2015-12-03 Mastercard International Incorporated Travel data of transport system users

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4120212A1 (fr) * 2021-07-16 2023-01-18 Deutsche Telekom AG Procédé de détection de la présence et/ou de l'enregistrement d'événement dans un lieu ou dans une zone spatiale, système de détection de la présence et/ou de l'enregistrement d'événement, module radio courte portée fixe ou module radio courte portée mobile, programme informatique, support lisible par ordinateur

Similar Documents

Publication Publication Date Title
EP2624233B1 (fr) Procédé de contrôle dans un système de péage routier
DE102017217297B4 (de) System zur Erzeugung und/oder Aktualisierung eines digitalen Modells einer digitalen Karte
EP0860954A1 (fr) Méthode pour le transfert d'information entre des objets en mouvement et dispositif de communication utilisant ladite méthode
EP2347279A1 (fr) Amélioration et validation d'une détermination de position
EP2924662B1 (fr) Unité embarquée et procédé de surveillance du fonctionnement dans un système de péage routier
EP2325807B2 (fr) Procédé et dispositifs de production d'informations de péage dans un système de péage routier
EP3138304B1 (fr) Génération d'un horodatage sans signal gnss
DE102007042877A1 (de) Kraftfahrzeug und System zur Vermittlung von Fahrbahneigenschaftsinformationen
DE102018221933A1 (de) Verteiltes Datenaustauschsystem für ein Fahrzeug
DE102012101638A1 (de) Verfahren und System zur Übermittlung von Verkehrsmittel-/Fahrstreckendaten in einem Verkehrsmittel an ein Mobilfunkgerät und zur Ermittlung von abrechnungsrelevanten Daten
EP2500869B1 (fr) Procédé de mise à disposition de services de données en fonction du lieu
EP3687879B1 (fr) Localisation de véhicule ferroviaire
EP3358532A1 (fr) Procédé de détermination automatique de l'utilisation de véhicules
CN204801823U (zh) 列控设备动态监测系统
WO2017167568A1 (fr) Procédé et système de détection de la présence et/ou de détermination du prix de transport d'un passager d'un véhicule
DE102013226532A1 (de) Verfahren zur Vorbereitung und Durchführung einer Fahrt einer Mehrzahl zu einem Verbund zusammengeschlossener Fahrzeuge und Kommunikationssystem
EP2490183A1 (fr) Appareil de véhicule, réseau ad hoc et procédé pour un système de péage routier
EP3358533B1 (fr) Procédé de détermination automatique de l'utilisation de véhicules
DE112019003236T5 (de) Fahrzeug-zu-Fahrzeug-Kommunikationssystem und Fahrzeugkommunikationsvorrichtung
EP4099182A1 (fr) Procédé de création et de mise à jour d'une banque de données pour dispositif de charge et véhicule automobile
DE102014207768A1 (de) System zum Austausch von Daten zwischen Akteuren des Strassenverkehrs
DE102020121114A1 (de) Verfahren und System zum Aufbauen einer digitalen Umgebungskarte für Verkehrsteilnehmer sowie Kraftfahrzeug für das System
EP3817406B1 (fr) Procédé de fonctionnement d'une application de service installée sur un dispositif terminal mobile
EP3211605B1 (fr) Dispositif de véhicule, système, dispositif coté route et procédé d'exécution d'au moins une transaction
DE102014207093A1 (de) Car2X-Kommunikation in USA und Europa mit einheitlichem Transmitter

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

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20171222

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

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: 20210520

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

Free format text: STATUS: EXAMINATION IS IN PROGRESS

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230525