EP4310801A1 - Système et procédé de calcul d'un montant de péage - Google Patents

Système et procédé de calcul d'un montant de péage Download PDF

Info

Publication number
EP4310801A1
EP4310801A1 EP22186180.0A EP22186180A EP4310801A1 EP 4310801 A1 EP4310801 A1 EP 4310801A1 EP 22186180 A EP22186180 A EP 22186180A EP 4310801 A1 EP4310801 A1 EP 4310801A1
Authority
EP
European Patent Office
Prior art keywords
route data
vehicle device
vehicle
toll
request
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
EP22186180.0A
Other languages
German (de)
English (en)
Inventor
Burkhard Mende
Nico Henke
Volker Nitzschke
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.)
Toll Collect GmbH
Original Assignee
Toll Collect 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 Toll Collect GmbH filed Critical Toll Collect GmbH
Priority to EP22186180.0A priority Critical patent/EP4310801A1/fr
Publication of EP4310801A1 publication Critical patent/EP4310801A1/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/06—Arrangements for road pricing or congestion charging of vehicles or vehicle users, e.g. automatic toll systems
    • G07B15/063—Arrangements for road pricing or congestion charging of vehicles or vehicle users, e.g. automatic toll systems using wireless information transmission between the vehicle and a fixed station

Definitions

  • the disclosure relates to a system and a method for calculating a toll fee for a toll motor vehicle.
  • a well-known method for collecting tolls is based on a satellite-based system.
  • a toll road network is divided into several sections, with each section 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 central location.
  • the position of the vehicle is determined at regular intervals while driving using a global navigation satellite system (GNSS).
  • GNSS global navigation satellite system
  • the specific positions are recorded in a so-called lane file.
  • the lane file has a certain capacity.
  • the lane file is transmitted to the headquarters when the lane file is completely filled with positions. If the complete lane file cannot be sent immediately, it will be stored in the vehicle device for later sending.
  • the lane file is evaluated at the headquarters and the toll to be paid is calculated.
  • it is difficult to assign the calculated toll to a specific route as the filling of the lane file only corresponds to a complete journey in exceptional cases. In particular, daily toll billing is not possible.
  • the document WO 95/20801 A1 discloses a decentralized procedure and an arrangement for determining usage fees for traffic routes. Using a device located in a vehicle, usage fees are calculated based on position data and tariff data. The usage fees are transferred from the facility to a central office via a data transmission system. In one embodiment, the transfer to the central office occurs 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 is needed to determine the road toll is transmitted from an operator control center using a communication device to the vehicle device.
  • the on-board device continuously determines partial usage fees for traveled route sections and the total usage fee for a trip by adding up the individual partial usage fees.
  • the vehicle device transmits When specified criteria are reached, the total usage fee determined up to this point is sent via the communication device to the operator center for billing.
  • the transfer of the total usage fee can occur when a threshold value is reached or exceeded, the threshold value corresponding to a certain amount of money and/or a certain period of time and/or a certain distance traveled from the last time of data transfer.
  • the transmission can take place when the data is requested from the operator's control center, or when the data transmission is triggered manually by a user.
  • data transmission can be triggered when the vehicle passes predetermined positions in the road network, for example when leaving a toll road.
  • the document EP 3 920 149 A1 discloses a method and a system for determining a toll fee.
  • the method includes the following steps: collecting route data; Detecting an end of journey, the end of the journey being signaled by a user input; after recording the end of the journey, sending the route data to a central data processing device; and calculating a toll fee based on the route data in the central data processing device, the calculation being prioritized over other route data already present in the central data processing device.
  • the aim is to make the billing of a toll route more flexible and to increase user-friendliness.
  • a system according to claim 1 and a method according to claim 14 are provided. Further embodiments are the subject of dependent claims.
  • a system for calculating a toll fee for a toll motor vehicle includes a central data processing device, several vehicle devices and an external device. Each of the several vehicle devices is uniquely assigned to a motor vehicle.
  • the selected vehicle device is set up to transmit all route data present in the memory of the selected vehicle device to the central data processing device in response to the request for the unscheduled transfer of route data.
  • the central data processing device is also referred to (to save space) as the central office within the scope of the disclosure.
  • the control center can have a processor and a memory that are linked to one another in terms of data technology.
  • the multiple vehicle devices can each have a processor that is coupled to the memory for data technology.
  • each vehicle device is uniquely assigned to a motor vehicle.
  • the vehicle devices may be permanently installed in the motor vehicle (e.g. in a DIN slot or mounted on the dashboard), arranged in the motor vehicle (e.g. with a suction cup on the windshield) or otherwise mounted in or on the motor vehicle be.
  • the multiple vehicle devices and the control center can each have a communication unit.
  • the vehicle devices and the control center can communicate with each other bidirectionally wirelessly, for example transmit signals and/or data. Communication can take place via a mobile phone network.
  • the communication unit of the control center can also be set up to communicate bidirectionally wirelessly with the external terminal (e.g. via a mobile radio network), for example to transmit signals and/or data. Communication between the vehicle devices and the external device is not provided. Different devices can make a request for the same vehicle device.
  • the vehicle devices record route data and store it in a memory.
  • a predetermined storage capacity is occupied with route data, the route data is provided as route data ready for dispatch.
  • the ready-to-ship route data is also referred to as regular route data.
  • the predetermined storage capacity is usually reached while the motor vehicle is traveling.
  • the route data ready for dispatch is then provided and further route data is recorded and saved.
  • the memories of the vehicle devices can each have two memory areas.
  • a first memory area stores the route data recorded while driving, also called current route data. As long as the current route data has not reached the predetermined storage capacity, it is not provided as route data ready for dispatch and remains in the first memory area.
  • a second memory area records the (regular) route data ready for dispatch until it is transmitted to the headquarters.
  • the control center and each of the multiple vehicle devices are set up for a standard process.
  • the standard process only route data that is ready for dispatch is transmitted to the headquarters. Any current route data that may be present remains in the vehicle device, for example in the first memory area.
  • the control center collects the regular route data from several (for example thousands or tens of thousands) vehicle devices and uses the route data received to calculate the toll fee due for the vehicle devices and the assigned motor vehicles.
  • the route data is processed in the order in which it arrives at the headquarters (FIFO principle, first in - first out). For this purpose, the route data can be arranged in a queue in the order in which they arrive at the headquarters.
  • the calculation of the toll fee in the standard process usually takes a few hours, possibly even 1 to 2 days. It is therefore not possible for a user (e.g. driver or freight forwarder) to bill the toll fee to a customer in a timely manner. It is also very difficult to assign the calculated toll fee to a specific route.
  • the route data ready for dispatch After the route data ready for dispatch has been sent, if necessary after receipt of a confirmation of receipt from the headquarters, the route data ready for dispatch can be deleted from the memory of the vehicle devices.
  • the external device can be a mobile device (e.g. a smartphone or a tablet) or it can be a stationary device such as a desktop PC.
  • the external terminal is set up to send the request for an unscheduled toll calculation to the headquarters for a selected vehicle device from the several vehicle devices (i.e. for a selected motor vehicle).
  • the control center sends a request to the selected vehicle device for unscheduled transmission of all route data present in the memory of the selected vehicle device.
  • the selected vehicle device then transmits all route data available in the memory to the control center, i.e.
  • route data that may be available and ready for dispatch (e.g. from the second memory area) as well as current route data (e.g. from the first memory area).
  • route data requested with an unscheduled toll calculation request is also referred to as unscheduled route data.
  • the control center then calculates the toll fee for the unscheduled route data of the selected vehicle device. This calculation is prioritized over other (regular) route data from other vehicle devices that are already available in the control center, for example within a few seconds to a few minutes. For this purpose, the unscheduled route data of the selected vehicle device can be placed at the beginning of the queue.
  • the unscheduled toll fee is transmitted from the control center to the external terminal and output there, for example displayed on a display device of the external terminal.
  • the user thus receives a result for the toll fee within a short time after making the request and can bill the toll to his customer promptly.
  • each of the multiple vehicle devices has a unique vehicle device identification, and that the route data includes the respective vehicle device identification of the vehicle device that captures the route data.
  • the route data may include the vehicle device identification in a header.
  • the vehicle device identification is a unique identifier for the vehicle device; it can be implemented as an alphanumeric character string. Based on the vehicle device identification, a vehicle device and the route data associated with this vehicle device can be identified.
  • the vehicle device identification therefore enables route data to be assigned to a specific vehicle device and thus to a specific motor vehicle.
  • the request from the external terminal for the unscheduled transmission of route data may include the vehicle device identification of the selected vehicle device.
  • the control center can be set up to identify the route data of the selected vehicle device based on the vehicle device identification of the selected vehicle device and to use it for toll calculation.
  • the route data includes position data, wherein the position data indicates a position of the vehicle device (and thus the position of the motor vehicle).
  • the multiple vehicle devices can each be set up to record the position data at regular time intervals, for example with a time interval of 1 s, 2 s or 5 s, and to store the recorded position data together with a timestamp in the route data, the timestamp being the time of recording of the respective position date.
  • the position data includes longitude and latitude.
  • the position data can also include the height above sea level.
  • the position data can be provided as GNSS coordinates.
  • the route data can further include the direction of travel and/or the speed of the motor vehicle.
  • Such route data can be determined using a GNSS receiver, a gyro (gyro compass) and/or based on speedometer signals from the motor vehicle.
  • the route data can contain further data, for example vehicle-specific information such as the license plate number of the motor vehicle, the number of axles, the type of drive and/or the weight of the motor vehicle.
  • the further data can be stored in a header of the route data.
  • the route data does not contain information about tolls to be paid for the route traveled. In other words: the route data is free of fee information.
  • the toll fee is calculated exclusively at the headquarters.
  • the route data includes event data, wherein the event data indicates an event recorded by the vehicle device, and that the plurality of vehicle devices are each set up to record an event and store the recorded event in the route data.
  • the multiple vehicle devices can each be set up to store the recorded event together with a timestamp in the route data, the timestamp indicating the time at which the respective event was recorded.
  • the event can be an ignition change of the motor vehicle assigned to the vehicle device. The ignition change can be starting the vehicle (changing from “ignition off” to “ignition on”) or switching off the vehicle (changing from “ignition on” to “ignition off”).
  • the vehicle devices are permanently installed in the assigned motor vehicles and are at least partially coupled to components of the motor vehicles, for example with the ignition and/or with the speedometer.
  • the vehicle devices can therefore detect the starting of the motor vehicles and note this event (if necessary together with a time stamp) in the route data.
  • the vehicle devices can detect a shutdown of the assigned motor vehicle and also store this event (if necessary together with a time stamp) in the route data.
  • the vehicle devices can have an energy supply, for example a secondary battery, which is charged by the motor vehicle while driving.
  • the multiple vehicle devices are each set up to send information to the central data processing device in response to the detection of an event as to whether there is route data ready for dispatch in the memory of the respective vehicle device.
  • information is sent from the vehicle device to the control center as to whether route data ready for dispatch is available in the memory of the vehicle device.
  • the headquarters can send a request to the vehicle device to transmit the route data ready for dispatch to the headquarters. The route data ready for dispatch is then transmitted from the vehicle device to the headquarters in response to the request.
  • the route data is processed using the standard process.
  • the central data processing device can be further set up to send the request for transmitting the route data ready for dispatch to the several vehicle devices at regular intervals.
  • the vehicle devices transmit any route data that may be available and ready for dispatch to the headquarters, which processes this in the standard toll calculation process.
  • any existing route data remains in the memory of the vehicle device.
  • the request for an unscheduled toll calculation for a selected vehicle device includes one event or several events, and that the central data processing device is set up to select the route data corresponding to the event or events from the route data of the selected vehicle device, for which to calculate the toll fee using selected route data and to transmit the calculated toll fee to the external device.
  • the request for unscheduled toll calculation can include two ignition changes, in particular the start of the motor vehicle ("ignition on”) at the beginning the journey and switching off the vehicle (“ignition off”) at the end of the journey.
  • a user can use the external terminal to send a request to the headquarters for an unscheduled toll calculation for the route data between the two "ignition change" events.
  • the control center sends the request for the unscheduled transmission of route data to the selected vehicle device and receives all existing (regular and current) route data from the selected vehicle device.
  • the control center searches the route data of the selected vehicle device for the events specified in the query. Based on the route data specified by the events, the toll fee is calculated in a prioritized manner and then transmitted to the external device.
  • the user thus promptly receives the toll fee for a journey, which is determined by the two ignition changes at the beginning of the journey and at the end of the journey. Any additional route data from the selected vehicle device that has no relation to the specified events remains in the headquarters and is processed as part of the standard process to calculate the toll fee.
  • the request for an unscheduled toll calculation for a selected vehicle device includes one or more time specifications, and that the central data processing device is set up to select the route data corresponding to the time specification or the time specifications from the route data of the selected vehicle device, for which to calculate the toll fee using selected route data and to transmit the calculated toll fee to the external device.
  • the central data processing device is set up to select the route data corresponding to the time specification or the time specifications from the route data of the selected vehicle device, for which to calculate the toll fee using selected route data and to transmit the calculated toll fee to the external device.
  • all route data available in the memory of the selected vehicle device is also transmitted to the headquarters.
  • the route data corresponding to the time specification or the time specifications are selected at the control center.
  • the toll fee is calculated in a prioritized manner for the selected route data and then transmitted to the external device.
  • time specifications can, for example, indicate the start and end of a trip. This can be advantageous if the motor vehicle stops while driving, for example for a break or to refuel. In this case, switching off the ignition at a rest stop or gas station would not correspond to the end of the journey, so an event-based query with two ignition changes for unscheduled toll calculation would produce incorrect results.
  • the user could adapt the event-based request and take into account the ignition changes when stopping at the rest area/gas station. However, depending on the number of stops during the journey, this could lead to a complicated request. On the other hand, a request with a time specification that specifies the start and end of the journey is more convenient to handle.
  • a combination of one or more events and one or more time specifications is also possible in the request for an unscheduled toll calculation.
  • the headquarters can evaluate the specifications, select the relevant route data and process it to calculate the toll fee.
  • the multiple vehicle devices are set up to encrypt the route data ready for dispatch in their respective memory.
  • the control center has a corresponding key to decrypt the route data after receipt and then carry out the toll calculation.
  • the plurality of vehicle devices are each set up to inform the central data processing device when route data ready for dispatch is available, and that the central data processing device is set up, in response to such information, to send a request to transmit the route data ready for dispatch to the corresponding vehicle devices to send.
  • the vehicle devices generally wait for a request from the headquarters to transmit ready-to-ship (regular) route data for toll calculation in the standard process and/or current route data for unscheduled toll calculation to the headquarters.
  • the headquarters is informed about route data ready for toll calculation and can request this specifically from the vehicle devices. This allows the utilization of the headquarters to be controlled in the standard process.
  • the function for requesting an unscheduled toll calculation must be activated in advance.
  • a user can submit a request to activate the function for a selected vehicle device, for example electronically using the external device.
  • the unscheduled toll calculation is activated so that the headquarters accepts and processes corresponding requests from the external device to the selected vehicle device.
  • the function for unscheduled toll calculation is basically activated for all vehicle devices.
  • the external terminal can have an app that carries out the functions mentioned here, in particular communication with the headquarters and/or issuing the calculated toll fee.
  • Fig. 1 shows a schematic view of a system.
  • the system includes a vehicle device 1, a central data processing device 10 and an external terminal 20.
  • the system usually has several vehicle devices. For simplicity's sake, in Fig. 1 Only a single vehicle device is shown and only one vehicle device is described in detail below. The explanations apply analogously to all vehicle devices in the system.
  • the vehicle device 1 can also be referred to as an OBU (OBU - on-board unit).
  • OBU OBU - on-board unit
  • the central data processing device 10 is referred to here (to save space) as the central office.
  • the vehicle device 1 has a processor 2, a memory 3, a GNSS receiver 4 and a communication unit 5.
  • the vehicle device 1 is uniquely assigned to a motor vehicle; it is installed in the motor vehicle or detachably arranged in the motor vehicle.
  • the processor 2 is set up to carry out steps of the methods disclosed in the present application. The steps are explained in more detail below.
  • the memory 3 is set up to store route data.
  • the GNSS receiver 4 determines the position of the vehicle device 1 and thus also the position of the associated motor vehicle.
  • the GNSS receiver 4 is integrated into the vehicle device 1 in the embodiment shown. 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 power supply for the vehicle device 1 is usually provided by the motor vehicle.
  • the vehicle device 1 can also have an accumulator, which is charged while the motor vehicle is traveling.
  • the vehicle device 1 can further include a DSRC communication module (DSRC - dedicated short range communication) and/or sensors for determining direction and/or speed (e.g. a gyro sensor, not shown).
  • the vehicle device 1 can further have a user interface, for example comprising one or more buttons, a display device and/or an acoustic output element (e.g. a 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 methods disclosed in the present application. The steps are explained in more detail below.
  • 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 and with the external terminal 20.
  • the external terminal 20 has a processor 21, a memory 22 and a communication unit 23.
  • the external terminal 20 can have a display device or be coupled to a display device (not shown).
  • the processor 21 is set up to carry out steps of the methods disclosed in the present application. The steps are explained in more detail below.
  • the communication unit 23 of the external terminal 20 is set up to exchange signals and/or data with the control center 10.
  • the external terminal 20 can be, for example, a smartphone, a laptop, a desktop PC or a tablet.
  • the external terminal 20 can be used, for example, by the driver of the motor vehicle or by a freight forwarder.
  • a communication connection for the bidirectional exchange of signals and/or data between the communication unit 5 of the vehicle device 1 and the communication unit 13 of the control center 10 can be established using a mobile radio connection (e.g. 2G, 3G, 4G or 5G).
  • a communication connection for the bidirectional exchange of signals and/or data between the communication unit 23 of the external terminal 20 and the communication unit 13 of the control center 10 can be established with a mobile radio connection (e.g. 2G, 3G, 4G or 5G). Communication between the vehicle device 1 and the external terminal 20 is not provided and does not take place.
  • the processor 2 of the vehicle device 1 is set up to record position data at regular intervals, for example every second, using the GNSS receiver 4 and to store it in the route data.
  • the position data includes a longitude and a latitude.
  • the route data also includes a vehicle device identification in a header, which uniquely identifies the vehicle device 1.
  • the processor 2 is further set up to store the recorded route data in the memory 3 of the vehicle device 1 and, when a predetermined storage capacity is reached, to provide the stored route data as ready-to-ship (regular) route data in the memory 3 of the vehicle device 1.
  • the route data can also include events. For example, an ignition change of the motor vehicle assigned to the vehicle device can be documented in the route data.
  • the route data can have time stamps, with the time stamps indicating the time at which the position data was recorded and/or the time at which the ignition change was recorded.
  • the memory 3 of the vehicle device 1 can have two memory areas (not shown).
  • a first memory area stores the route data recorded during the ongoing journey, which, as already mentioned, are referred to as current route data.
  • the current route data As long as the current route data has not reached the predetermined storage capacity, it remains in the first memory area and is not provided as route data ready for dispatch. Only when the current route data reaches the predetermined storage capacity are they made available as (regular) route data ready for dispatch and stored in a second memory area of the memory 3 until they are transmitted to the headquarters.
  • the processor 2 can also be set up to send information to the control center 10 by means of the communication unit 5 that route data ready for dispatch is available in the memory 3 of the vehicle device 1.
  • the processor 2 is also set up to transmit the route data ready for dispatch (e.g. from the second memory area) to the central office 10 by means of the communication unit 5 in response to a request from the central office 10.
  • the processor 2 is set up, in response to a request from the control center 10 for the unscheduled transfer of route data, to transmit to the control center 10 all the route data present in the memory 3 of the vehicle device 1, i.e. the current route data (e.g. from the first memory area) and, if applicable, route data that is ready for dispatch (e.g. from the second memory area).
  • the processor 11 of the control center 10 is set up to use the communication unit 13 to send a request for transmitting route data ready for dispatch to the vehicle device 1 and to receive the route data ready for dispatch that is then transmitted.
  • the processor 11 is further set up to calculate a toll fee for the motor vehicle assigned to the vehicle device 1 based on the regular route data received. If the system includes several (many, e.g. several thousand) vehicle devices and regular route data arrives at the headquarters 10 from several vehicle devices, the toll fee is calculated in the order in which the route data arrives at the headquarters 10. This corresponds to what has already been mentioned Standard process.
  • the processor 11 of the control center 10 is further set up to send a request for an unscheduled transmission of route data to the vehicle device 1 in response to a request from the external terminal 20 for an unscheduled toll calculation.
  • the vehicle device 1 transmits all route data present in the memory 3 of the vehicle device 1 to the control center 10.
  • the processor 11 is further set up to calculate a toll fee for the vehicle device 1 based on the unscheduled route data received. The calculation is prioritized over other regular route data present in the memory 12 of the control center 10.
  • the processor 11 of the control center 10 is set up to transmit the calculated toll fee to the external terminal 20 by means of the communication unit 13.
  • the processor 21 of the external terminal 20 is set up to send a request for an unscheduled toll calculation for the vehicle device 1 to the control center 10 by means of the communication unit 23.
  • the request can be triggered, for example, with a user input.
  • the processor 21 is further set up to output a toll fee received in response to the request from the central office 10, for example by displaying it on a display device.
  • the vehicle device records position data, in particular the longitude and latitude, at regular intervals (step 200).
  • the position data is stored as route data in the memory of the on-board device (step 210).
  • the stored route data is provided as route data ready for dispatch in the memory of the vehicle device (step 220).
  • the vehicle device sends information to the headquarters that route data is ready for dispatch (step 230).
  • the center sends a request to transmit the route data ready for dispatch to the vehicle device (step 240).
  • the vehicle device transmits the route data ready for dispatch to the headquarters (step 250).
  • the control center receives the route data ready for dispatch from the vehicle device (step 260).
  • the control center uses the route data received to calculate the toll fee for the motor vehicle assigned to the vehicle device (step 270).
  • the toll fee can then be invoiced to the user, for example by post or via an internet portal.
  • step 230 is optional.
  • Information from the vehicle device to the headquarters that route data ready for dispatch is available in the memory is a preferred embodiment, but is not absolutely necessary.
  • the control center can send the request to transmit the route data ready for dispatch to the vehicle device without being previously informed by the vehicle device.
  • the control center sends the request to transmit the route data ready for dispatch to the vehicle device at regular intervals.
  • the system includes several, usually several thousand, vehicle devices.
  • the control center therefore receives route data from many vehicle devices.
  • the toll fee is calculated in the order in which the route data arrives at the headquarters.
  • the regular route data are arranged in a queue in the control center 10 in the order in which they arrive and then processed in sequence (FIFO principle, first in - first out).
  • a schematic example of such a queue 500 is shown in Fig. 3 shown.
  • Previously received regular route data 510 - 514 are arranged in the queue 500 in the order in which they arrive at the headquarters 10. This determines the order in which the route data is processed.
  • the route data 510 is processed next and the toll is calculated from this. This is indicated by arrow 520.
  • a regular route datum 530 newly arrived at headquarters is placed at the end of the queue 500 behind the route datum 514, as shown by arrow 540.
  • Multiple queues can also be formed so that parallel processing of the regular route data is possible.
  • the regular route data is distributed among the multiple queues in the order in which it arrives at the control center 10 (not shown).
  • Fig. 4 shows a flowchart for a procedure for unscheduled toll calculation.
  • the user uses his smartphone to send a request for an unscheduled toll calculation for his motor vehicle to the headquarters (step 100). To do this, he selects the vehicle device assigned to the motor vehicle, which can be clearly identified based on the vehicle device identification.
  • the center sends a request for unscheduled transmission of route data to the selected vehicle device (step 110).
  • the vehicle device then transmits all route data present in the memory of the vehicle device, i.e. current route data and any regular route data that may be present, to the control center (step 120).
  • the control center calculates the toll fee based on the route data of the selected vehicle device (step 130).
  • the control center transmits the calculated toll fee to the user's smartphone (step 140).
  • the smartphone displays the toll fee on its screen (step 150). The user is therefore promptly informed about the toll fee incurred and can invoice his customer for this.
  • route data arrives at the headquarters 10, which was transmitted due to a request for an unscheduled toll calculation (unscheduled route data), it is placed at the top of the queue 500 and the route data previously arranged in the queue 500 is moved back one position. This is in Fig. 5 shown.
  • an unscheduled route data 550 arrives at the control center 10, it is placed at the beginning of the queue 500, i.e. in front of the position of the already existing route data 510. This is shown by the arrow 560. Consequently, the unscheduled route date 550 is processed next.
  • the route data 510 - 514 already present in the queue 500 is moved back one position and processed accordingly later.
  • unscheduled route data from various vehicle devices arrive at the control center 10, they are placed at the front of the queue 500 in the order in which they arrive and the existing regular route data is moved to the back accordingly. This ensures 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.
  • Fig. 6 Another embodiment of a method for unscheduled toll calculation is shown. Some steps are the same as in Fig. 4 procedures presented. The starting point is the following situation. The user drove his vehicle continuously and without a break. He is now interested in the toll fee incurred for this journey.
  • the request for unscheduled toll calculation made in step 100 includes the indication that the toll fee should be calculated for the distance traveled between the last two ignition changes. The last two ignition changes indicate the start of the journey (ignition on) and the end of the journey (ignition off).
  • the control center then sends the request to transmit all route data to the vehicle device (Step 110) and the vehicle device transmits all route data to the control center (Step 120). All route data belonging to the vehicle device is now available at the control center.
  • the control center selects the route data that lies between the last two ignition changes (step 125).
  • the toll fee is calculated in a prioritized manner (step 130), transmitted to the smartphone (step 140) and displayed there (step 150).
  • the method shown can be modified as follows for another application.
  • the user drove between 9:00 a.m. and 5:00 p.m. He stopped twice during the journey, once to refuel and once to eat.
  • a request for an unscheduled calculation of the toll fee based on ignition changes would be quite cumbersome, as several ignition changes have taken place. Instead, the user starts a time-based request.
  • the request for unscheduled toll calculation now includes the statement that the toll fee should be calculated for the period between 9:00 a.m. and 5:00 p.m. (step 100).
  • the control center then sends the request to transmit all route data to the vehicle device (step 110) and the vehicle device transmits all route data to the control center (step 120).
  • step 125 the route data that lies within the specified period of time is now selected at the headquarters.
  • the toll fee is then calculated in a prioritized manner (step 130), transmitted to the smartphone (step 140) and displayed there (step 150).
  • the user can also specify other times for calculating the toll fee.
  • a driver has to deliver to a construction site during his shift. He starts his vehicle and drives to his destination. There he switches off the vehicle and opens the app on his smartphone to claim the toll amount from his customer. He can choose between "1. Amount between the last two ignition changes" and "2. Set a period of time". For the sake of simplicity, he chooses option 1.
  • the route data is then transferred from the vehicle device to the control center and tariffed at the control center. The total is sent to the app on the smartphone and displayed to the driver. He reads the total and invoices it to his customer.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
EP22186180.0A 2022-07-21 2022-07-21 Système et procédé de calcul d'un montant de péage Pending EP4310801A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP22186180.0A EP4310801A1 (fr) 2022-07-21 2022-07-21 Système et procédé de calcul d'un montant de péage

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP22186180.0A EP4310801A1 (fr) 2022-07-21 2022-07-21 Système et procédé de calcul d'un montant de péage

Publications (1)

Publication Number Publication Date
EP4310801A1 true EP4310801A1 (fr) 2024-01-24

Family

ID=82656369

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22186180.0A Pending EP4310801A1 (fr) 2022-07-21 2022-07-21 Système et procédé de calcul d'un montant de péage

Country Status (1)

Country Link
EP (1) EP4310801A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1995020801A1 (fr) 1994-01-28 1995-08-03 Detemobil Deutsche Telekom Mobilnet Gmbh Procede et dispositif permettant de determiner les droits de peage a encaisser pour des voies et/ou des zones de circulation empruntees par des vehicules
WO2002061691A1 (fr) 2001-01-31 2002-08-08 Daimlerchrysler Ag Systeme de collecte de droits de peage
EP3920149A1 (fr) 2020-06-04 2021-12-08 Toll Collect GmbH Procédé de détermination d'un péage, appareil de véhicule et système de péage
DE202021106013U1 (de) * 2021-10-08 2022-01-19 Toll Collect Gmbh System zur Mauterhebung für ein Kraftfahrzeug

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1995020801A1 (fr) 1994-01-28 1995-08-03 Detemobil Deutsche Telekom Mobilnet Gmbh Procede et dispositif permettant de determiner les droits de peage a encaisser pour des voies et/ou des zones de circulation empruntees par des vehicules
WO2002061691A1 (fr) 2001-01-31 2002-08-08 Daimlerchrysler Ag Systeme de collecte de droits de peage
EP3920149A1 (fr) 2020-06-04 2021-12-08 Toll Collect GmbH Procédé de détermination d'un péage, appareil de véhicule et système de péage
DE202021106013U1 (de) * 2021-10-08 2022-01-19 Toll Collect Gmbh System zur Mauterhebung für ein Kraftfahrzeug

Similar Documents

Publication Publication Date Title
DE69635093T2 (de) Mobiles Endgerät
EP2909815B1 (fr) Procédé et installations de soulèvement de péage conditionné par le trafic
DE102004013807B4 (de) Elektronisches Mautsystem für Verkehrswege und Verfahren zu dessen Betrieb
EP1162559A2 (fr) Procédé de planification électronique de rendez-vous et planificateur électronique de rendez-vous correspondant
EP1708144A2 (fr) Dispositif et procédé destinés à l'échange de données de péage dans des systèmes d'identification par radiofréquence
EP1512128B1 (fr) Systeme de navigation pour vehicule
EP2184717B1 (fr) Procédé, dispositif et système de préparation de places de stationnement disponibles en utilisant une unité de rehaussement de paiement ou de télématique existante dans un véhicule
DE102022125933A1 (de) System und Verfahren zur Mauterhebung für ein Kraftfahrzeug
EP1466140B1 (fr) Procede de determination d'un temps de trajet
EP2690601B1 (fr) Procédé de contrôle de péage et installations de contrôle de péage ainsi que le système de péage doté des installations de contrôle de péage de ce type
DE102010022707A1 (de) Verfahren und Fahrzeug zum Erfassen und Bereitstellen von Informationen und Informationssystem dazu
EP2131152B1 (fr) Système de navigation et procédé de fonctionnement d'un système de navigation
EP1921588A2 (fr) Système de détection de trafic
EP3920149A1 (fr) Procédé de détermination d'un péage, appareil de véhicule et système de péage
EP4310801A1 (fr) Système et procédé de calcul d'un montant de péage
DE102007007730B4 (de) Verfahren und Vorrichtung zur Durchführung einer Verkehrsflusssteuerung zur Reduzierung des Energie- Kraftstoffverbrauchs, des CO2- Ausstoßes sowie der Unfallzahlen im Straßenverkehr
DE102012202973A1 (de) Erfassen und Auswerten von Fahrzeuggeschwindigkeitsdaten
WO2019063672A2 (fr) Assistant personnel intelligent pour le ravitaillement en carburant
DE102007014684B4 (de) Verfahren und Vorrichtung zur Durchführung einer Verkehrsflusssteuerung zur Reduzierung des Energie-Kraftstoffverbrauchs, des CO2-Ausstoßes sowie der Unfallzahlen im Straßenverkehr
EP1184241A1 (fr) Méthode pour le contrôle automatique d'une opération de remplissage d'un réservoir de véhicule
EP1659369A2 (fr) Dispositif de navigation et système de navigation
EP3113119B1 (fr) Procede de suivi de vehicules soumis a peage dans un systeme de peage
EP3709278B1 (fr) Dispositif de collecte embarqué d'ensembles de données concernant l'emplacement
DE4416125A1 (de) Einrichtung zur Erhebung der Autobahnmaut
DE102015007490A1 (de) Verfahren zum Betreiben eines Fahrzeugs und Fahrzeug

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: THE APPLICATION HAS BEEN PUBLISHED

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