EP3920149A1 - Method for determining a toll charge, vehicle device and toll system - Google Patents

Abstract

A computer-implemented method for determining a toll charge is disclosed. The method comprises the following steps: acquiring route data; Detecting the end of the journey, the end of the journey being signaled by a user input; after the end of the journey has been recorded, the route data is sent to a central data processing device; and calculating a toll on the basis of the route data in the central data processing device, the calculation being prioritized over other route data already available in the central data processing device. Furthermore, a vehicle device and a toll system are disclosed.

Description

The disclosure relates to a method for determining a toll fee, a vehicle device and a toll system.

background

A known method for collecting tolls is based on a satellite-based system. A toll road network is divided into several sections, each section being assigned a tariff that determines the amount of the toll. The mapping of the toll road network to the sections forms part of the operating data of the toll system and is stored in a control center.

With an on-board device arranged in a vehicle, the position of the vehicle is determined at regular time intervals while driving with the aid of a global navigation satellite system (GNSS). The determined positions are recorded in a so-called lane file. The lane file has a certain capacity. The lane file is transmitted to the control center when the lane file is completely filled with positions. If the complete lane file cannot be sent immediately, it will be saved in the on-board unit for later sending. The lane file is evaluated in the control center and the toll to be paid is calculated. As a rule, it is difficult to assign the calculated toll to a specific route, since the lane file is only overruled in exceptional cases with a single, completed journey. In particular, daily or route-specific billing of the toll is not possible.

The document WO 95/20801 A1 discloses a decentralized method and an arrangement for determining usage fees for traffic routes. With the help of a device located in a vehicle, usage fees are calculated on the basis of position data and tariff data. The usage fees are transmitted from the facility to a central office via a data transmission system. In one embodiment, the transmission to the central office takes place when the calculated and totaled usage fees reach a predetermined amount.

The document WO 02/061691 A1 describes a road toll collection system with a vehicle device for the decentralized, vehicle-autonomous determination of a road toll for a vehicle within a usage billing area. If necessary, data that are required to determine the road toll are transmitted from an operator control center to the vehicle device by means of a communication device. The On-Board Unit continuously calculates the partial usage fees incurred for the route sections traveled and the total usage fee for a trip by adding up the individual partial usage charges. When predetermined criteria are reached, the vehicle device transmits the total usage fee determined up to this point in time via the communication device to the operator control center for billing. The total usage fee can be transmitted when a threshold value is reached or exceeded, the threshold value corresponding to a specific amount of money and / or a specific time span and / or a specific distance traveled from the last point in time of the data transmission. Furthermore, the transfer can take place when the data is requested from the operator control center or when the data transfer is triggered manually by a user. In addition, the data transmission can be triggered when the vehicle drives over predetermined positions in the road network, for example when leaving a toll road.

The document DE 10 2004 013 807 A1 discloses an electronic toll system for traffic routes, which is based on commercially available GSM / UMTS cell phones or comparable devices such as PDA, car phone etc. with GSM function, and a method for its operation. In every mobile radio network, data from the respective radio cell is transmitted to the radio telephone via an organization channel. This information supplied by the base stations is used to record the radio cells passed through by the toll customer in the mobile phone. This collected data is transmitted to a toll center. On the basis of the sequence of the radio cells passed through, which is transmitted by the toll payer's mobile phone, a comparison with databases of existing traffic routes can be used to derive with high accuracy which toll route the vehicle has used.

The document EP 3 002 734 A1 discloses a vehicle device for a vehicle subject to a toll, comprising a decentralized computing device which is communicatively coupled to a decentralized communication device. The decentralized computing device is set up to send identification data and / or position data and / or toll data via the decentralized communication device to a toll center in order to enable or confirm the collection of a toll related to the vehicle subject to the toll for the use of a toll traffic area. The decentralized computing device is also set up to monitor the proper functioning of the vehicle device and / or the decentralized communication device and / or a position-determining device that is communicatively coupled to the decentralized computing device. The decentralized computing device is set up to generate a failure message in response to an ascertained deficiency in the proper functioning of the vehicle device and / or the decentralized communication device and / or the position determination device and to send it to a toll center in order to use a method for registering at least one in the toll center to initiate usage authorization related to the toll vehicle for use of a toll traffic area lying ahead of the toll vehicle.

The document EP 2 665 044 A1 discloses a method for measuring the performance of a road toll system operating on a plurality of vehicle-based, each determining their position Onboard units are based, which can wirelessly communicate with geographically distributed radio stations in order to collect position-related toll transactions in a toll center connected to them. The method comprises the following steps: sending a data collection order with a start location and a stop location from the toll center via a cellular network to a group of onboard units; in each onboard unit of the group: if one's own position comes in the specified proximity to the start location, starting a recording of one's own positions or data derived therefrom or of radio communications with DSRC radio beacons and, if one's own position comes in the specified proximity to the stop location , Stopping the recording and sending the recording to the toll office via the cellular network; in the toll center: comparison of the records received from all onboard units of the group with the toll transactions collected by these onboard units in relation to positions between the start and stop locations and calculation of a performance measure of the road toll system based on the Comparison.

The document US 2009/0259528 A1 discloses technology to ensure data protection in toll transactions. A filter unit is used to determine on the basis of position data whether a toll route is being traveled. The toll fee is then calculated on a toll server.

summary

The task is to make the calculation of a toll fee more flexible. In particular, a timely calculation of the toll should be made possible.

A method according to claim 1, a vehicle device according to claim 6 and a toll system according to claim 8 are disclosed. Further embodiments are the subject of the dependent claims.

• Erfassen von Streckendaten,
• Erfassen eines Fahrtendes, wobei das Fahrtende durch eine Nutzereingabe signalisiert wird,
• nach dem Erfassen des Fahrtendes, Senden der Streckendaten an eine zentrale Datenverarbeitungseinrichtung, und
• Berechnen einer Mautgebühr anhand der Streckendaten in der zentralen Datenverarbeitungseinrichtung, wobei das Berechnen priorisiert gegenüber anderen in der zentralen Datenverarbeitungseinrichtung bereits vorhandenen Streckendaten erfolgt.

According to a first aspect, a computer-implemented method for determining a toll fee is provided. The process consists of the following steps:

• Acquisition of route data,
• Detection of the end of the journey, whereby the end of the journey is signaled by a user input,
• after the end of the journey has been recorded, the route data is sent to a central data processing device, and
• Calculating a toll on the basis of the route data in the central data processing device, the calculation being prioritized over other route data already available in the central data processing device.

• Streckendaten zu erfassen und in dem Speicher abzulegen, und
• die in dem Speicher abgelegten Streckendaten an eine zentrale Datenverarbeitungseinrichtung zu senden, wobei das Senden ausgelöst wird, wenn
  1. a) eine vorbestimmte Kapazität des Speichers mit Streckendaten belegt ist oder
  2. b) ein Fahrtende durch eine Nutzereingabe signalisiert wird.

Das Fahrzeuggerät ist eingerichtet, beide das Senden der Streckendaten auslösende Optionen a) und b) bereitzustellen. Zusätzlich zu dem bereits bekannten Versand der Streckendaten bei Erreichen einer vorbestimmten Speicherkapazität besteht nun die Möglichkeit, einen Versand der Streckendaten manuell am Fahrzeuggerät auszulösen.According to a second aspect, a vehicle device for a toll system is disclosed. The On-Board Unit has a memory and is set up:

• To acquire route data and to store them in the memory, and
• to send the route data stored in the memory to a central data processing device, the sending being triggered when
  1. a) a predetermined capacity of the memory is occupied with route data or
  2. b) the end of the journey is signaled by a user input.

The vehicle device is set up to provide both options a) and b) that trigger the transmission of the route data. In addition to the already known dispatch of route data when a predetermined storage capacity is reached, there is now the option of manually triggering dispatch of route data on the vehicle device.

• Streckendaten zu erfassen und in einem Speicher des Fahrzeuggeräts abzulegen, und
• die in dem Speicher abgelegten Streckendaten an die zentrale Datenverarbeitungseinrichtung zu senden, wobei das Senden ausgelöst wird, wenn
  1. a) eine vorbestimmte Kapazität des Speichers mit Streckendaten belegt ist oder
  2. b) ein Fahrtende durch eine Nutzereingabe signalisiert wird.

Das Fahrzeuggerät ist eingerichtet, beide das Senden der Streckendaten auslösende Optionen a) und b) bereitzustellen.
Die zentrale Datenverarbeitungseinrichtung ist eingerichtet anhand der Streckendaten eine Mautgebühr zu berechnen, wobei das Berechnen der Mautgebühr gemäß der folgenden Kriterien erfolgt:

• für Streckendaten, die gemäß Option a) vom Fahrzeuggerät an die zentrale Datenverarbeitungseinrichtung übermittelt werden, wird die Mautgebühr in der Reihenfolge des Eintreffens der Streckendaten in der zentralen Datenverarbeitungseinrichtung berechnet,
• für Streckendaten, die gemäß Option b) vom Fahrzeuggerät an die zentrale Datenverarbeitungseinrichtung übermittelt werden, wird die Mautgebühr priorisiert gegenüber anderen in der zentralen Datenverarbeitungseinrichtung bereits vorhandenen Streckendaten berechnet.

According to a third aspect, a toll system for determining a toll fee is disclosed. The toll system comprises a vehicle device and a central data processing device. The On-Board Unit is set up:

• To record route data and to store it in a memory of the on-board device, and
• to send the route data stored in the memory to the central data processing device, the sending being triggered when
  1. a) a predetermined capacity of the memory is occupied with route data or
  2. b) the end of the journey is signaled by a user input.

The vehicle device is set up to provide both options a) and b) that trigger the transmission of the route data.
The central data processing device is set up to calculate a toll fee based on the route data, the toll fee being calculated according to the following criteria:

• for route data that is transmitted from the vehicle device to the central data processing device according to option a), the toll is calculated in the order in which the route data arrives in the central data processing device,
• for route data that are transmitted from the vehicle device to the central data processing device according to option b), the toll charge is calculated with priority over other route data already available in the central data processing device.

The vehicle device can also be set up, in addition to options a) and b), to send the route data stored in the memory to a central data processing device when a predetermined time in which route data was recorded has expired (option c)).

The central data processing device can also be set up to calculate the toll in the order in which the route data arrive in the central data processing device for route data that are transmitted from the vehicle device to the central data processing device in accordance with option c).

Route data that are sent in the event of predetermined events (a capacity of the memory has been reached or, if applicable, a time has expired, options a) and c)) are referred to as regular route data in the context of the disclosure. Route data after the end of the journey has been signaled a user input (option b)) are sent here as unscheduled route data. Provision can be made for the unscheduled route data to be sent to the central data processing device immediately after the end of the journey has been recorded, that is to say without a time delay.

The central data processing device is also referred to as a center in a space-saving manner in the context of the disclosure. The control center can have a processor and a memory that are data-coupled to one another.

The method can be carried out by the vehicle device. The vehicle device can have a processor which is data-technically coupled to the memory. The vehicle device is assigned to a vehicle; it can be permanently installed in the vehicle (e.g. in a DIN slot), arranged in the vehicle (e.g. with a suction cup on the windshield) or otherwise attached to the vehicle. The recorded route data are stored in the memory of the vehicle device. After the route data has been sent, if necessary after receipt of a confirmation of receipt from the control center, the stored route data can be deleted from the memory of the On-Board Unit. The vehicle device can have a position detection unit or be coupled to a position detection unit. The position detection unit can be designed as a GNSS receiver.

The vehicle device and the control center can each have a communication unit. With the communication units, the vehicle device and the control center can communicate with one another bidirectionally, for example transmit signals and / or data. Communication can take place via a cellular network.

With the method, the end of the journey is determined by means of a user input. The route data is then transmitted to the control center. In the headquarters, the toll fee is prioritized based on the transmitted route data and is thus made available promptly. A driver or another user of the toll system (e.g. a freight forwarder) can thus be quickly informed of the toll charges incurred for the completed journey. It can be provided that the calculated toll is sent from the control center to the vehicle device. As an alternative or in addition, the toll fee can also be sent from the control center to another device, for example to a mobile device, a smartphone, a tablet or a desktop PC. The vehicle device and / or the other device can be set up to output the toll fee, for example to show it on a display device.

The route data contain position data which indicate the position of the vehicle device and thus the position of the vehicle (to which the vehicle device is assigned) so that the route covered by the vehicle can be determined on the basis of the route data. In one embodiment, the position data includes the longitude and the latitude. Optionally, the position data can also include the height above sea level. The route data can still use the Include the direction of travel and / or the speed of the vehicle. The route data can be determined using GNSS, gyro (gyrocompass) and / or speedometer signals. Optionally, the route data can contain further data, for example a vehicle device identification and / or vehicle-specific information such as the license plate number of the vehicle, the number of axles, the type of drive and / or the weight of the vehicle. The vehicle device identification is a unique identifier for the vehicle device; it can be implemented as an alphanumeric character. The vehicle device identification enables route data to be assigned to a specific vehicle device and thus to a specific vehicle. The further data can be stored in a header of the route data. The route data does not contain any information on the amount of the toll that has to be paid for the route traveled. In other words: the route data is free of charge information. The toll fee is only calculated at the head office.

Provision can be made for the route data to be recorded at recording times, with the recording times forming a regular interval, for example with a time cycle of 1 s, 2 s or 5 s, and with a position (e.g. longitude and latitude, optionally height) at each recording time ) is recorded. The position is then saved in the route data at each acquisition time.

The end of the journey is signaled by a user input. In one embodiment it is provided that the driver executes the user input, e.g. operating a button or operating a switching device, at the end of the journey, for example when the vehicle is stationary with the ignition still on, and thus signals the end of the journey. The route data is then sent to the control center, preferably immediately after the user input has been made. The completion of the dispatch can be signaled to the driver, for example with an optical signal and / or with an acoustic signal. The driver can then switch off the ignition and thus switch off the vehicle and the on-board unit.

The toll fee is calculated in the headquarters based on the route data. This means that the route data is evaluated and a check is carried out for the items contained in the route data to determine whether they correspond to a route subject to tolls. If so, the toll due will be calculated.

The unscheduled route data are processed in the head office with priority. The prioritization is explained in more detail below. The toll system can comprise several vehicle devices and a control center. The control center usually receives route data from many (for example thousands or hundreds of thousands) vehicle devices. The regular route data are transmitted from the vehicle devices to the control center when predetermined parameters are met. The regular route data are processed in the control center in the order in which they arrive. For this purpose, they can be arranged in a queue, for example. The unscheduled route data are being processed preferred to the regular route data. In the case of a queue, the unscheduled route data is placed at the beginning of the queue when it arrives at the head office, so that it is processed as quickly as possible and the corresponding toll fee is calculated. This ensures that the calculated toll can then be promptly transmitted to a user (e.g. the driver and / or the shipping company). This can make it easier for the user to invoice a customer.

The sum of the regular route data and the unscheduled route data form the entirety of all route data. The proportion of regular route data in relation to the totality of route data is significantly higher than the proportion of unscheduled route data. The regular route data can form a ratio of 100: 1 or 1000: 1 to the unscheduled route data. The unscheduled route data can make up less than 1 per thousand of the total route data.

The distinction between the regular route data and the unscheduled route data can be made, for example, by checking whether the capacity of the route data is fully utilized (regular route data) or not (unscheduled route data). The control center can be set up to carry out such a check after the route data has arrived. Alternatively or in addition, it can be provided that the unscheduled route data are marked for prioritized processing. For example, the route data can have a bit which indicates whether the processing in the control center should be prioritized or not. The bit would have to be set for unscheduled route data, while it would not be set for regular route data. The control center can be set up to evaluate such a bit.

• reguläre Streckendaten, also Streckendaten, die gemäß Option a) (und ggf. Option c)) vom Fahrzeuggerät an die zentrale Datenverarbeitungseinrichtung übermittelt werden, werden an dem Ende der Warteschlange angeordnet,
• außerplanmäßige Streckendaten, also Streckendaten, die gemäß Option b) vom Fahrzeuggerät an die zentrale Datenverarbeitungseinrichtung übermittelt werden, werden an dem Anfang der Warteschlange angeordnet.

Die Warteschlange dient als Puffer zur Zwischenspeicherung der Streckendaten in einer Reihenfolge, bevor aus den Streckendaten die Mautgebühr berechnet wird. Die Streckendaten bilden Elemente der Warteschlange. Das erste Element, welches sich am Anfang der Warteschlange befindet, wird aus der Warteschlange entfernt und zur Berechnung der Mautgebühr verarbeitet. Die regulären Streckendaten werden nach ihrem Eintreffen in der Zentrale am Ende der Warteschlange angeordnet (FIFO-Prinzip, first in, first out). Die außerplanmäßigen Streckendaten werden dagegen als erstes Element an den Anfang der Warteschlange gesetzt, sodass sie ohne Wartezeit in der Warteschlange zur BerechnungAs already mentioned, the central data processing device can comprise a queue for route data, in which the route data are arranged until the toll fee is calculated. The queue has a beginning and an end. Incoming route data is queued according to the following criteria:

• Regular route data, i.e. route data that are transmitted from the vehicle device to the central data processing device according to option a) (and possibly option c)), are arranged at the end of the queue,
• Unscheduled route data, that is route data that are transmitted from the vehicle device to the central data processing device according to option b), are arranged at the beginning of the queue.

The queue serves as a buffer for the intermediate storage of the route data in a sequence before the toll fee is calculated from the route data. The route data form elements of the queue. The first element, which is at the beginning of the queue, is removed from the queue and processed to calculate the toll fee. The regular route data are arranged at the end of the queue after they arrive at the control center (FIFO principle, first in, first out). The unscheduled route data, on the other hand, is placed at the top of the queue as the first element so that it can be queued for calculation without waiting

the toll can be processed. In this case, the element that was previously at the beginning and all other elements in the queue are moved one position back.

The central data processing device can comprise several queues for route data. The multiple queues can be processed in parallel. Here, too, the regular route data are arranged in the order in which they arrive at the control center at the ends of the queues. Unscheduled route data are always placed at the beginning of a queue. Care can be taken to ensure that a newly arrived unscheduled route data does not displace a previously arrived unscheduled route data that is already at the beginning of a queue. Rather, it is preferable to arrange unscheduled route data at the beginning of a queue in which there is a regular route data as the first element.

According to a further aspect, a computer-implemented method for collecting data for a vehicle subject to a toll, for example while the vehicle is in use, is provided. The method comprises the following steps: acquisition of route data, acquisition of the end of the journey and, after the acquisition of the end of the journey, transmission of the acquired route data to a central data processing device (control center). Route data that is sent to the control center after the end of the journey has been recorded can be processed in the control center with priority over other route data already available in the control center; in particular, the toll fee can be calculated using the route data.

According to yet another aspect, a system with a vehicle device and a central data processing device is disclosed. The vehicle device is set up to record route data, to record the end of the journey and to send the recorded route data to the central data processing device when the end of the journey has been recorded. The control center can be set up to process route data, which are sent to the control center after the end of the journey has been recorded, with priority over other route data already available in the control center; in particular, the toll fee can be calculated using the route data in a prioritized manner.

The end of the journey can be determined by evaluating previously recorded route data. The end of the journey can be recorded if the current route data correspond to a journey end object. A trip termination object can, for example, correspond to the location of a shipping company at which the vehicle regularly stops.

A trip termination object can be generated, for example, by a user input on the vehicle device. When the vehicle is in a position where it regularly stops and which should act as a trip end, the driver can generate a trip end object by means of a user input (e.g. pressing a button on the vehicle device). The trip termination object is then saved in the On-Board Unit. In addition, it can be provided that the trip termination object is transmitted to the control center. When the vehicle returns to this position at a later date reached, the trip termination object is recognized by the On-Board Unit. This records the end of the journey and the existing route data is transmitted to the control center without the driver having to take any action.

It can also be provided that the trip termination object is generated by means of a data processing device and transmitted to the vehicle device or to the control center. When the trip termination object is transmitted from the data processing device to the control center, the trip completion object is then transmitted from the control center to the vehicle device. For example, a user can use a suitable data processing device (e.g. computer, tablet or smartphone) to enter an address which is intended to mark the end of the journey. The address is transmitted to the control center. The control center uses the address to create a trip termination object and sends this to the on-board unit.

A trip termination object can also be generated from an evaluation of previously determined route data. Certain rules can be used to identify which positions correspond to the end of the journey. For this purpose, a trip end object is generated so that the end of the trip is then recognized and the route data is sent to the control center without delay. The rules are explained in more detail below.

Provision can also be made for the end of the journey to be recorded when the route data indicate leaving a toll route network, for example driving off a toll route (e.g. motorway or federal highway) or crossing a state border. Based on the position, it can be determined whether the national territory is being left, which means that the toll is no longer required.

The end of the journey can also be determined by evaluating a driving maneuver. The driving maneuver can include one or more steering movements and / or one or more speed changes within a specific time period.

The end of the trip can also be detected as a combination of the detection of a trip end object and a driving maneuver. This can be used, for example, to record a parking process on the premises of a haulage company.

The route data can be encrypted. Encrypted route data is decrypted in the control center before processing.

It can be provided that the start of a journey is recorded before the journey begins. The start of the journey can be recorded by a user input, for example by the driver making a user input before the start of the journey. This embodiment can be combined with all embodiments for detecting the end of the journey, in particular with the detection of the end of the journey by means of a user input. The inputs for the start of the journey and the end of the journey can be assigned to one another. For example, they can relate to one another using an identification number. Recording the start and end of a journey makes it even easier to assign route data to a specific route. This makes the display of the toll fee even clearer.

In all of the embodiments disclosed here, the following steps can be carried out before the route data are sent to the control center. The On-Board Unit sends a signal or a message to the control center that route data is ready for collection (after the end of the journey has been recorded). The control center then sends a command to the on-board unit to transmit the available route data. Only then does the On-Board Unit transmit the route data to the control center. This ensures that the control center has sufficient capacity to receive route data.

Features that are disclosed in connection with the method can be applied in an analogous manner to the vehicle device and / or the system and vice versa.

Description of exemplary embodiments

Fig. 1

eine schematische Darstellung eines ersten Systems,

Fig. 2

eine schematische Darstellung eines zweiten Systems,

Fig. 3

eine erste Ausführungsform eines Verfahrens zum Sammeln von Streckendaten,

Fig. 4

eine zweite Ausführungsform eines Verfahrens zum Sammeln von Streckendaten,

Fig. 4a

eine Ausführungsform eines Verfahrens zum Sammeln von Streckendaten und priorisierter Verarbeitung der Streckendaten,

Fig. 5

eine Ausführungsform eines Verfahrens zum Verarbeiten von Streckendaten,

Fig. 6

eine Ausführungsform eines Verfahrens zum priorisierten Verarbeiten von Streckendaten,

Fig. 7 und 8

eine weitere Ausführungsform eines Verfahrens zum priorisierten Verarbeiten von Streckendaten,

Fig. 9 bis 12

weitere Ausführungsformen eines Verfahrens zum Sammeln und Verarbeiten von Streckendaten,

Fig. 13 und 14

schematische Darstellungen einer Straße mit einem Erkennungsobjekt,

Fig. 15

eine schematische Darstellung zum Bestimmen einer Durchfahrt durch ein Erkennungstor,

Fig. 16

ein Verfahren zum Erzeugen eines Fahrtbeendigungsobjekts und

Fig. 17

eine schematische Darstellung zum Erfassen eines Fahrtendes anhand eines Fahrmanövers.

Exemplary embodiments are explained in more detail below with reference to figures. Show it:

Fig. 1

a schematic representation of a first system,

Fig. 2

a schematic representation of a second system,

Fig. 3

a first embodiment of a method for collecting route data,

Fig. 4

a second embodiment of a method for collecting route data,

Figure 4a

an embodiment of a method for collecting route data and prioritized processing of route data,

Fig. 5

an embodiment of a method for processing route data,

Fig. 6

an embodiment of a method for the prioritized processing of route data,

Figures 7 and 8

another embodiment of a method for the prioritized processing of route data,

Figures 9 to 12

further embodiments of a method for collecting and processing route data,

Figures 13 and 14

schematic representations of a road with a recognition object,

Fig. 15

a schematic representation for determining a passage through an identification gate,

Fig. 16

a method for generating a trip termination object and

Fig. 17

a schematic representation for detecting the end of a journey based on a driving maneuver.

In the following, the same reference symbols are used for the same components / method steps.

Fig. 1 Figure 3 shows a schematic view of a first system. The system comprises a vehicle device 1 and a central data processing device 10. The vehicle device 1 is also referred to as an OBU (OBU - on-board unit). The central data processing device 10 is also referred to as a control center.

The vehicle device 1 has a processor 2, a memory 3, a GNSS receiver 4 (for example GPS - global positioning system) and a communication unit 5. The vehicle device 1 is assigned to a vehicle; it is installed in the vehicle or detachably arranged in the vehicle. The processor 1 is set up to carry out steps of the method disclosed in the present application, including recording route data, recording the end of a journey and sending the recorded route data to the control center. The steps are explained in more detail below in connection with embodiments of the method. The memory 3 is set up to store route data. The position of the vehicle device 1 and thus also the position of the assigned vehicle is determined with the GNSS receiver 4. In the embodiment shown, the GNSS receiver 4 is integrated into the vehicle device 1. It can also be designed separately from the vehicle device 1 and coupled to the vehicle device 1 (not shown). The communication unit 5 is set up to exchange signals and / or data with the control center 10.

A voltage supply for the vehicle device is usually provided by the vehicle. The vehicle device can furthermore comprise a DSRC communication module (DSRC - dedicated short range communication) and / or sensors for determining direction and / or speed (not shown). The vehicle device can furthermore have a user interface, for example comprising one or more buttons, a display device and / or an acoustic output element (e.g. piezo beeper).

The control center 10 has a processor 11, a memory 12 and a communication unit 13. The processor 11 is set up to carry out steps of the method disclosed in the present application, including receiving route data, sending an acknowledgment of receipt to the vehicle device and processing the received route data to calculate the toll. The steps are explained in more detail below in connection with embodiments of the method. The memory 12 is set up to store received route data. The communication unit 13 is set up to exchange signals and / or data with the vehicle device 1.

A communication connection for the bidirectional exchange of signals and / or data between communication unit 5 of vehicle device 1 and communication unit 13 of control center 10 can be established with a cellular connection (e.g. 2G, 3G, 4G or 5G).

Fig. 2 shows a schematic representation of a further system. The further system comprises, in addition to the vehicle device 1 and the control center 10, a further data processing device 20. For the vehicle device 1 and the control center 10, those in connection with apply Fig. 1 made statements.

The further data processing device 20 is also referred to as an external device. The external device 20 has a processor 21, a memory 22 and a communication unit 23. Optionally, the external device 20 can have a display device or be coupled to a display device (not shown). The communication unit 23 of the external device 20 is set up to exchange signals and / or data with the control center 10. The external device 20 can be, for example, a smartphone, a laptop, a desktop PC or a tablet. The external device 20 can be used by the driver of the vehicle or a freight forwarder.

A communication connection for the unidirectional or bidirectional exchange of signals and / or data between the communication unit 23 of the external device 20 and the communication unit 13 of the control center 10 can be established with a cellular connection (e.g. 2G, 3G, 4G or 5G).

The control center 10 can use its communication unit 13 to transmit information on a processing status of the route data and / or the toll determined from the route data to the vehicle device 1 and / or to the external device 20.

A first embodiment of the method is shown in FIG Fig. 3 shown. Route data are recorded with the vehicle device 1 (step 100). Specifically, the position of the vehicle device is determined by means of the GNSS receiver 4 at regular time intervals of 1 s. Each specific position is stored in the memory 3 of the vehicle device 1. In step 110, the end of the journey is detected, for example with the aid of the processor 2 of the vehicle device 1. After the end of the journey has been recorded, the recorded and stored route data are transmitted to the control center 10 using the communication unit 5 (step 120).

Fig. 4 shows a second embodiment of the method. Steps 100, 110 and 120 correspond to those in connection with FIG Fig. 3 described steps. After the control center 10 has received the route data from the vehicle device 1, the route data are processed in the control center 10 with priority in order to calculate the amount of the toll on the basis of the route data (step 130). This ensures that the driver and / or the freight forwarder can receive an invoice for the toll promptly after the journey has been completed. The toll billing can then be transmitted from the control center 10 to the vehicle device 1 and / or to the external device 20 (not shown). The toll charges can thus be passed on to a customer in a timely manner.

Another embodiment of the method is shown schematically in FIG Figure 4a shown. Route data are recorded during the journey, in particular the position of the vehicle (step 100). The route data are stored in the memory 3 of the vehicle device 1. The end of the journey is recorded on the basis of a user input (step 115). The driver triggers a user input by operating a control element on the vehicle device. The route data are then transmitted to the control center (step 120). In the control center, using the route data transmitted, the toll charge is calculated with priority over other route data that is already available (step 130).

The route data contain position data which indicate the position of the vehicle device and thus the position of the vehicle. In addition to the position data, the route data include a vehicle device identification which uniquely identifies the vehicle device.

The control center usually contains route data from several vehicle devices at one point in time. Each route data includes an on-board device identification. The On-Board Unit is set up to provide at least two options for sending the route data to the control center. According to a first option (option a)), the route data are sent to the control center when they reach a predetermined size, that is to say when a predetermined capacity of the memory 3 of the vehicle device 1 is occupied with route data. As already stated, route data transmitted in this way are called regular route data. The regular route data are arranged in a queue in the control center in the order in which they arrive and then processed in sequence (FIFO principle, first in - first out). According to a second option (option b)), route data are sent to the control center when the end of the journey is recorded on the basis of a manually triggered user input (unscheduled route data).

A schematic example of a queue 500 is shown in FIG Fig. 5 shown. Regular route data 510-514 received previously are arranged in the queue 500 in the order in which they arrive at the control center. This defines the order in which the route data is processed. In the embodiment shown, the route data 510 is processed next and the toll is calculated from this. This is indicated by arrow 520. A regular route data 530 newly arrived at the control center is placed at the end of the queue 500 after the route data 514, as is shown by the arrow 540. Several queues can also be formed so that the regular route data can be processed in parallel. In this case, the regular route data are distributed to the multiple queues in the order in which they arrive at the control center (not shown).

If unscheduled route data arrive at the control center, they are placed in the first place in the queue and the route data previously placed in the queue are shifted one position back. This is in Fig. 6 shown. If an unscheduled route data 550 arrives at the control center, it is placed at the beginning of the queue 500, that is to say in front of the position of the route data 510. This is shown by the arrow 560. As a result, the unscheduled route data 550 is processed next and the toll fee is calculated therefrom. The route data 510-514 already present in the queue 500 are shifted one position back and processed accordingly later.

If several unscheduled route data from different on-board units arrive at the control center, these are placed in the front of the queue in the order in which they arrive and the existing regular route data is shifted back accordingly. This guarantees prioritized processing of all unscheduled route data. Prioritized processing in several queues is also possible for unscheduled route data (not shown). For example, unscheduled route data can be placed at the top of several queues so that regular route data previously available there are shifted backwards.

It can happen that several route data from the regular route data available in the control center belong to a vehicle device, for example if the associated vehicle has driven a lot. In such a case, the prioritized processing can include searching for all route data transmitted by the vehicle device and placing them in the front position in the queue in the order in which they arrive at the control center. The processing of the route data is therefore prioritized in the correct chronological order. This enables the driver / freight forwarder to better understand the calculation of the toll. Such a case is exemplified in Figures 7 and 8 shown.

The queue 500 comprises eight regular route data 510, 511a, 511b, 512, 513, 514, 515 and 516. The route data 511a and 511b were recorded by the same vehicle device and transmitted to the control center. The route data 511a is in the second position of the queue 500 (counting from the bottom) and the route data 511b is in the sixth position. The unscheduled route date 570 has now arrived at the headquarters; it comes from the same vehicle device as route data 511a and 511b. For the prioritized processing of route data all route data sent by the same vehicle device are now searched for (here route data 511a, 511b and 570) and arranged in the order in which they arrive at the control center at the front end of queue 500. The other route data 510, 512, 513, 514, 515 and 516 are shifted backward, respectively. This is in Fig. 8 shown.

The prioritized processing of the route data in the control center can be carried out for each embodiment of the detection of the end of the journey described here.

A third embodiment of the method is shown in FIG Fig. 9 shown. Steps 100, 110 and 120 correspond to those in connection with FIG Fig. 3 described steps. The center 10 receives the route data and checks whether the transmission was successful (step 140). The check can be carried out with a cyclic redundancy check (CRC). If the route data have been successfully transmitted, the control center 10 sends an acknowledgment of receipt to the vehicle device 1 by means of its communication unit 13 (step 150). After receipt of the confirmation of receipt, the route data previously sent in the memory 3 of the vehicle device 1 are deleted. The prioritized processing of the route data takes place in the control center (step 130), as already in connection with Figures 4-8 described.

The check of the transmitted route data with subsequent deletion of the route data in the vehicle device (if the check was successful) can be carried out for each embodiment of the detection of the end of the journey described here.

Another embodiment of the method is shown schematically in FIG Fig. 10 shown. Route data are recorded during the journey, in particular the position of the vehicle (step 100). The route data are stored in the memory 3 of the vehicle device 1. The end of the journey is recorded on the basis of a user input (step 115). For example, the vehicle can be parked with the engine running (i.e. with the ignition switched on). The driver triggers a user input by operating a control element on the vehicle device. Using one or more keys, he can select a cost center in a menu or enter a new cost center. After an optional confirmation of the cost center, the route data are transmitted to the control center (step 120). The ongoing transmission of route data to the control center is signaled on the vehicle device, for example by means of an optical display device. The center receives the route data and checks whether the transmission was successful (step 140). If the result of the check is positive, the control center sends an acknowledgment of receipt to the vehicle device (step 150). The vehicle device signals that the transmission was successful (step 155), for example by the optical display device going out or its display (for example symbol or color) changing. The route data in the memory 3 of the vehicle device 1 are then deleted (step 160). After the successful data transfer has been signaled, the driver can switch off the ignition and thus also the on-board unit. Prioritized processing of the received route data for calculating the toll fee takes place in the control center (step 130), as already in connection with Figures 4-8 described.

Fig. 11 shows a further embodiment of the method. In step 100, route data are recorded during the journey and stored in the vehicle device. The route data recorded is evaluated in order, if necessary, to determine the end of the journey therefrom (step 116). The route data can be used to determine when a toll route is left, for example when leaving a motorway or when crossing a state border. If you leave a national territory, the toll expires. The route data accumulated until leaving the national territory is transmitted to the control center (step 120). In the control center, prioritized processing of the route data can optionally take place, as already in connection with Figures 4-8 described.

Fig. 12 shows a further embodiment of the method. In step 100, route data are recorded during the journey and stored in the vehicle device. The recorded route data is evaluated. When a travel termination object is recognized, an end of travel is determined (step 117). The trip termination object can, for example, indicate the location of a freight forwarding company. The route data are transmitted to the control center (step 120). In the control center, prioritized processing of the route data can optionally take place, as already in connection with Figures 4-8 described.

A user (e.g. a driver or a freight forwarder) can specify an area in which the vehicle is regularly parked. The area can be specified as coordinates (longitude and latitude) or as an address. The coordinates or the address are referred to as area data in the following. The area data can be specified by means of a data processing device, for example by means of the external device 20. The area data are transmitted from the data processing device to the control center. The control center uses the area data to determine a trip termination object. The trip termination object is transmitted from the control center to the on-board unit. If the On-Board Unit detects a match when comparing the recorded route data with the trip end object, the end of the trip is detected and the route data is transmitted to the control center.

Alternatively, a trip termination object can be created with a user input. When the driver reaches his destination, he triggers the creation of the trip termination object with a user input. The coordinates of the current position are transmitted to the control center. A trip termination object is generated in the control center from the transmitted coordinates. The generated trip termination object is transmitted from the control center to the vehicle device and stored in the memory of the vehicle device. In addition, the end of the journey is recorded with the user input and the route data is sent to the control center. If you stop at this destination later, the end of the journey is recorded based on the object of the end of the journey and the route data is transmitted to the control center without the driver having to take any action.

In all of the embodiments disclosed here, the trip termination object can be a recognition gate or a recognition circle. In the Figures 13 and 14 exemplary embodiments are shown for this. A parking lot 210 is located close to a toll road 200. An exit 205 leads from the road 200 to the parking lot 210. When the vehicle takes the exit and passes through a detection gate 220, the end of the journey is detected ( Fig. 13 ). At the in Fig. 14 In the embodiment shown, the vehicle enters a recognition circle 230 when it takes the exit 205 to the parking lot 210. In this case, too, the end of the journey is recorded. In both cases, the route data is transmitted to the control center after the end of the journey has been recorded. The use of a detection circle can be advantageous if the parking lot (or more generally the destination) has several entrances.

The passage through an identification gate is shown schematically in Fig. 15 shown. The vehicle moves along a route 270 from left to right, which is symbolized by arrow 271. The recognition gate 220 is defined by a first gate coordinate 250 and a second gate coordinate 251. A first position 260 in front of the detection gate 220 and a second position 261 behind the detection gate 220 lie on a first straight line, the lane straight line 265. The gate coordinates 250, 251 lie on a second straight line, the gate straight line (corresponds to the illustration in FIG Fig. 15 the straight line that also forms the detection gate 220). The recognition gate 220 is passed when the straight line of the gate and the straight lane line 265 have an intersection point 280 between the gate coordinates 250, 251. The entry into a detection circle is recorded in the same way.

The travel termination object can be determined from the route data. An evaluation of the route data can include older route data from previous journeys. Using the route data, the On-Board Unit or the control center can create a trip termination object. The creation of the trip termination object is based on rules based on the route data and, if necessary, time leaps. A time jump in the route data, i.e. little or no change in the position of the vehicle between two points in time that are quite far apart (e.g. a few hours), indicates that the vehicle is stationary for the duration between the points in time. A trip termination can be derived from this. The following criteria can be taken into account in the evaluation: number of standstills in a defined radius in a defined period and / or number of circles to end the journey).

One embodiment for creating a trip termination object is shown in FIG Fig. 16 shown schematically and will be explained in more detail below.

The vehicle device 1 is set up to independently recognize at configurable intervals i whether there is a regular (more than n times, n = 2, 3, 4,...) Pause (of more than m seconds, e.g. m = 6000 s or m = 3600 s or m = 21000 s) comes into an area with a certain size. The area can, for example, be a circle with a predetermined diameter g, for example g = 5 m, 10 m, 20 m or 50 m. If this is the case, the vehicle device creates a trip end object at this point, for example a recognition circle. The trip termination object is included in a list of such objects for a specific validity t (e.g. t = 2 weeks or t = 4 weeks). When the vehicle later drives into the area of the trip termination object, the On-Board Unit terminates the currently open file with the route data. The route data are then transmitted to the headquarters. In addition, the On-Board Unit extends the validity of the trip termination object by the period t. The set of rules for recognizing a trip termination object can be configured with regard to the parameters i, n, m, g and t.

The validity of the trip termination objects can be set differently according to the frequency with which the objects are visited. The more frequently a travel pattern is recognized, the longer the validity of the respective travel termination object can be established. The number of trip termination objects can be restricted, among other things, according to the frequency of use and / or the validity. A user has the option of manually defining the trip termination objects (as already described), changing them or permanently excluding them via a smartphone app.

In reference to Fig. 16 The creation and evaluation of a trip termination object comprises the following steps. Route data is recorded which includes the position of the vehicle (step 300). The route data is saved (step 310). A check is carried out to determine whether the vehicle is stationary (standstill detection) in connection with time jumps (step 350). The set of rules explained above for creating a trip termination object is executed (step 360). If a trip termination object is to be created on the basis of the rules, this is done in step 370. The trip termination objects are then updated (step 380). Furthermore, it is checked whether the current route data correspond to a trip termination object (for example a recognition circle) (step 320). In the positive case, the route data are transmitted to the control center (step 340). The route data is processed to determine the toll (step 350).

In one embodiment, steps 300, 310, 320, 330, 350, 360, 370 and 380 are carried out by vehicle device 1 and step 340 is carried out by control center 10. In another specific embodiment, steps 300, 310, 320, 330 and 380 are carried out by vehicle device 1; steps 340, 350, 360 and 370 are carried out by the control center 10.

Fig. 17 shows an example of a driving maneuver that indicates the end of a journey. A road 400 (for example a motorway) has an exit 410 which leads to a parking lot 420. A lane 430 of a vehicle is also shown, the arrow 435 indicating the direction of travel. Before entering the exit 410, there is a first braking maneuver 440 with which the speed of the vehicle is reduced. To enter the exit 410, a right-hand pivot 450 is carried out. This is followed by a left pivot 460 and then a second braking maneuver 470, with which the vehicle almost comes to a standstill (e.g. a speed of less than 10 km / h). Optionally, in addition to the aforementioned driving maneuvers, a maneuvering maneuver can be evaluated in order to determine the end of the journey. A maneuvering maneuver is characterized by a strong angular dispersion at low speed.

The features disclosed in the description, the claims and the figures can be relevant for the implementation of embodiments both individually and in any combination with one another.

Claims (12)

Computer-implemented method for determining a toll fee, with the following steps: - Acquisition of route data, - Detection of the end of the journey, whereby the end of the journey is signaled by a user input, - After the end of the journey has been recorded, the route data is sent to a central data processing device, and Calculating a toll on the basis of the route data in the central data processing device, the calculation being carried out with priority over other route data already available in the central data processing device. Method according to claim 1, wherein the central data processing device comprises a queue for route data, in which the route data are arranged up to the calculation of the toll, the queue having a beginning and an end, and the route data sent after the end of the journey being detected at the beginning be placed in the queue. The method of claim 1 or 2, further comprising: - Sending the calculated toll from the central data processing device to the vehicle device. Method according to one of the preceding claims, wherein the route data is free of information on the amount of a toll fee. Method according to one of the preceding claims, wherein the route data are recorded at recording times, the recording times forming a regular interval, and wherein a position is recorded at each recording time. Vehicle device for a toll system, wherein the vehicle device has a memory and wherein the vehicle device is set up: - to record route data and to store them in the memory, and to send the route data stored in the memory to a central data processing device, the sending being triggered when a) a predetermined capacity of the memory is occupied with route data or b) the end of the journey is signaled by a user input, wherein the vehicle device is further set up to provide both options a) and b) that trigger the transmission of the route data. Vehicle device according to claim 6, wherein the vehicle device is further set up, in addition to options a) and b), to send the route data stored in the memory to a central data processing device when a predetermined time in which route data was recorded has expired. Toll system for determining a toll fee with a vehicle device and a central data processing device,
where the vehicle device is set up: - to record route data and store them in a memory of the On-Board Unit, and to send the route data stored in the memory to the central data processing device, the sending being triggered when a) a predetermined capacity of the memory is occupied with route data or b) the end of the journey is signaled by a user input, wherein the vehicle device is further set up to provide both options a) and b) that trigger the transmission of the route data, and
wherein the central data processing device is set up to calculate a toll fee based on the route data, the toll fee being calculated according to the following criteria: - for route data that is transmitted from the vehicle device to the central data processing device according to option a), the toll is calculated in the order in which the route data arrives in the central data processing device, - For route data that are transmitted from the vehicle device to the central data processing device according to option b), the toll is calculated with priority over other route data already available in the central data processing device. Toll system according to claim 8, wherein the vehicle device is further set up, in addition to options a) and b), to send the route data stored in the memory to a central data processing device when a predetermined time in which route data was recorded has expired (option c )), and
wherein the central data processing device is further set up to calculate the toll in the order in which the route data arrives in the central data processing device for route data that are transmitted from the vehicle device to the central data processing device in accordance with option c). System according to claim 8 or 9, wherein the central data processing device comprises a queue for route data, in which the route data are arranged up to the calculation of the toll, the queue having a beginning and an end, the incoming route data in the queue according to the following criteria to be ordered: - Route data that are transmitted from the vehicle device to the central data processing device in accordance with option a) and, if applicable, option c) are placed at the end of the queue, Route data that are transmitted from the vehicle device to the central data processing device according to option b) are arranged at the beginning of the queue. The system of claim 10, wherein the central data processing facility comprises multiple queues for route data. System according to one of claims 8 to 11, wherein the central data processing device is further set up to send the calculated toll fee to the vehicle device.

Images