EP3174015B1 - Reconnaissance d'erreurs dans une unité embarquée à bord d'une véhicule d'un système de péage - Google Patents

Reconnaissance d'erreurs dans une unité embarquée à bord d'une véhicule d'un système de péage Download PDF

Info

Publication number
EP3174015B1
EP3174015B1 EP15003424.7A EP15003424A EP3174015B1 EP 3174015 B1 EP3174015 B1 EP 3174015B1 EP 15003424 A EP15003424 A EP 15003424A EP 3174015 B1 EP3174015 B1 EP 3174015B1
Authority
EP
European Patent Office
Prior art keywords
vehicle
data
vehicle device
status
event
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.)
Active
Application number
EP15003424.7A
Other languages
German (de)
English (en)
Other versions
EP3174015A1 (fr
Inventor
Thomas Lohfelder
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 EP15003424.7A priority Critical patent/EP3174015B1/fr
Publication of EP3174015A1 publication Critical patent/EP3174015A1/fr
Application granted granted Critical
Publication of EP3174015B1 publication Critical patent/EP3174015B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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 invention relates to a toll system, a vehicle device and a method for detecting errors in a vehicle device of a toll system carried by a vehicle according to the preambles of the independent claims.
  • Vehicle devices used for toll collection and carried in a vehicle for this purpose are accordingly designed to record position data of positions of the vehicle and, depending on several state variables of the vehicle device, to process the position data and/or data derived from the position data for the purpose of collecting a toll fee related to the vehicle, which is to be charged for the use of a traffic area by the vehicle that is identifiable on the basis of the recorded position data.
  • either the vehicle device itself can, depending on several state variables of the vehicle device and identifying at least one tollable traffic area used by the vehicle on the basis of the position data and/or data derived from the position data, levy a vehicle-related toll fee for the use of the identified traffic area by the vehicle, or a central data processing device of the toll system, which has received the position data and/or data derived from the position data from the vehicle device as a result of processing the position data and/or data derived from the position data, can levy a vehicle-related toll fee for the use of the identified traffic area by the vehicle on the basis of the recorded position data and/or data derived from the position data.
  • the state variables of the vehicle equipment are such that they influence the processing of the position data or the data derived from the position data—for example, they enable or prevent it—in the sense that the result of the processing depends on the state variables.
  • a state variable can, for example, be a registered identifier of the vehicle equipment or the vehicle, which is required to assign a toll fee to the vehicle using the toll road.
  • Another state variable can be a registered operational readiness state of the vehicle equipment, for which, in the event of a lack of operational readiness, the specific processing of the position data or data derived from the position data is prevented.
  • Vehicle devices used to collect tolls typically have a large number of state variables that influence toll collection.
  • the values of these state variables are stored in the vehicle device's memory in the form of output data, which are generated based on received or generated input data.
  • input data can be supplied to the vehicle device via an interface or generated by the vehicle device itself.
  • the vehicle equipment When the vehicle equipment is put into operation, the input data is received, which generates output data that enables the vehicle equipment to operate as intended. Even during operation, the vehicle equipment can receive input data, the processing of which then changes the output data, resulting in a changed value of the affected state variables being stored in the vehicle equipment. Furthermore, the vehicle equipment can, during operation itself, Generate input data, the processing of which then also results in a change in the output data with the result that a changed value of the affected state variables is stored in the vehicle equipment.
  • a specific value of a state variable can result in a toll no longer being collected at all, being collected incorrectly, or not being assigned to the correct vehicle. Such a specific value may be correct. However, due to the complex processing of input data, unforeseen conditions that cannot be remedied may result in such a specific value being incorrect.
  • Changing the value of a state variable without the necessary prerequisites – as well as maintaining a value of a state variable that has become invalid due to changed boundary conditions or input data – represents an unjustified influence on toll collection – in other words, an error.
  • a vehicle device determines a toll fee based on the vehicle's position data and on at least one state variable of the vehicle device in the form of vehicle-specific parameters. Values of the state variables are stored as initial data for the declaration, along with a time point, in a status protocol of the vehicle device known as a logbook.
  • EP 1870302 A1 relates to a method, an on-board unit, and a personalization system for personalizing an on-board unit.
  • the personalization process takes place decentrally within the on-board unit after personalization software and data relevant for personalization have been provided for the on-board unit. This is carried out by means of data transmission via an additional personalization interface of the on-board unit. Personalization can thus also be performed decentrally by the user and does not require specialist personnel.
  • the present invention has set itself the task of detecting such erroneous values of a state variable of a vehicle device of a toll system.
  • Feature (g) i) corresponds to a protocol check according to the invention with the search for one or more results in the form of output data in the status log, which are to be expected (i.e. expected) and/or not to be expected (i.e. prohibited) by one or more triggers in the form of the input data to be checked in the event log according to the rule set, and is referred to briefly as "forward search".
  • Feature (g) ii) corresponds to a protocol check according to the invention for one or more triggers in the form of input data in the event log, which cause one or more results to be expected according to the rule set in the form of the output data to be checked in the status log according to the rule set (and are thus to be expected for the existence of the output data to be checked) or are not likely to cause one or more results (and are thus prohibited if the output data to be checked is present), and is referred to briefly as "backward search".
  • Expected input or output data can be both required input or output data of a single event message or status information that must occur according to the rules, as well as permissible input or output data of multiple event messages or status information, of which input or output data of at least one event message or status message is required input or output data.
  • Feature (d) describes the desired state of the vehicle device according to the invention.
  • the feature (h) describes, with the result that can result from the forward and/or backward search, the reportable faulty actual state of the vehicle device according to the invention.
  • a predefined time range (short: time range) around the respective time value of the event message or status information to be checked does not necessarily require that the respective time value of the event message or status information to be checked must be contained within the predefined time range (this condition only applies to the time value of the status information(s) or event message(s) that are searched for within the scope of the test).
  • time ranges for searching for forbidden input or output data may be different from the time ranges for searching for expected input or output data.
  • the time range for the search for prohibited input or output data can be arranged after the respective time value of the status information or event message to be checked because, based on the event messages or status information to be checked, certain subsequent event messages or status information should not occur, and the time range for the search for expected input or output data can be arranged before the respective time value of the status information or event message to be checked because the existence of the status information or event messages to be checked requires the presence of certain input or output data of preceding event messages or status information.
  • the time range for searching for prohibited input or output data can also be arranged before the respective time value of the status information or event message to be checked, because, based on the event messages or status information to be checked, certain preceding event messages or status information must not occur, whose prohibited input data would have generated different output data than that of the status information to be checked, or whose prohibited output data would have generated different input data than that of the event message to be checked.
  • the time range for searching for expected input or output data can be arranged after the respective time value of the status information or event message to be checked, because, based on the event messages or status information to be checked, certain subsequent event messages or status information should occur.
  • the temporal subordination or precedence of the time range does not exclude the possibility that the respective time value of the status information or event message to be checked forms a lower or upper limit of the relevant time range.
  • the toll system can be designed to (g) determine, based on at least one set of rules stored in the toll system, whether i) for at least one event message of the event protocol to be checked in the status protocol, expected and/or prohibited output data are contained in at least one item of status information according to at least one set of rules stored in the toll system, the status time value of which lies within a predetermined time interval after the event time value of the event message to be checked, and/or whether ii) for at least one item of status information of the status protocol to be checked in the event protocol, expected and/or prohibited input data are contained in at least one item of status information according to at least one set of rules stored in the toll system, the event time value of which lies within a predetermined time interval before the status time value of the status information to be checked, and (h) upon detection of a lack of output data and/or input data to be expected according to the at least one set of rules and/or upon detection of the presence of output data and/or input data prohibited according to the at least one set of
  • the set of rules comprises a database in which input data of one or more event messages are linked to output data of one or more status information items, wherein for a forward search, the output data linked to the input data of one or more event messages to be checked are expected output data and for a backward search, the input data linked to the output data of one or more status information to be checked are expected input data.
  • Such a database provides combinations of compatible input and output data.
  • input data of one or more event messages are linked to output data of one or more status information items, wherein for a forward search, the output data linked to the input data of one or more event messages to be checked are forbidden output data and for a backward search, the input data linked to the output data of one or more status information to be checked are forbidden input data.
  • Such a database provides combinations of incompatible input and output data.
  • the duration of said time range or said time interval is one hour or less than one hour. More preferably, the duration of said time range or said time interval is less than one minute.
  • the duration of said time range or said time interval can depend on the status information to be checked or the event message(s) to be checked.
  • the duration of said time range or said time interval can also be dependent on a status time value of status information other than that of the status information to be checked or, in addition to the status time value of the status information to be checked, also on the status time value of status information other than that of the status information to be checked.
  • the toll system can be designed to select from the status protocol a first status information item and a second status information item entered directly thereafter in the status protocol with regard to one and the same status variables, first output data of the first status information item and second output data of the second To check status information for a change in the value of the state variable, to determine whether the event log contains input data of at least one event message to be expected according to at least one set of rules stored in the toll system, the processing of which according to the processing instructions would trigger a corresponding change in the value of the state variable and whose event time value lies between the first status time value of the first status information and the second status time value of the second status information and to generate the error message if it is determined that no input data to be expected according to the set of rules is contained in the event log.
  • This form of backward search determines whether the input data relevant for a specific change in the value of a state variable from a first value to a second value is present.
  • the vehicle device can be configured to generate output data from input data at predetermined intervals or upon receipt of a corresponding instruction and to write this and/or previously generated output data to a status log.
  • This status log may have already been stored in the vehicle device prior to the writing act, so that status information written to the status log is added to the status information already present in the status log or replaces it with respect to the same status variables. In the latter case, previous values of state variables in the status log are lost.
  • a comparison in the sense of the previously described backward search remains possible if a first status protocol written at a first point in time, each containing first status information relating to a state variable, is first sent by the vehicle device via a mobile radio communication device included in the vehicle device to a central data processing device arranged outside - in particular away from - the vehicle, and later a second status protocol written at a second point in time, each containing second status information relating to a state variable, is sent by the vehicle device via the mobile radio communication device included in the vehicle device to the central data processing device, which prevents a possible overwriting of the first status protocol by the second.
  • the vehicle device can be designed to simultaneously store a plurality of status protocols that were generated at different times with respect to the same state variable.
  • the toll system can be designed to select a first item of status information from a first status log written at a first point in time and a second item of status information from a second status log written at a second point in time relating to one and the same status variable as the first status information, to check first output data of the first status information and second output data of the second status information for a change in the value of the state variable, to determine whether the event log contains input data of at least one event message which are to be expected according to at least one set of rules stored in the toll system, the processing of which according to the processing instructions would trigger a corresponding change in the value of the state variable and whose event time value lies between the first status time value of the first status information and the second status time value of the second status information, and to generate the error message if it is determined that no input data which are to be expected according to the set of rules is contained in the event log.
  • the toll system can also be designed to select input data of a first event message and input data of a second event message from the event log, to determine whether in the status log according to at least output data to be expected from a set of rules stored in the toll system are contained in at least one item of status information which would result from the consecutive processing of the input data of the first event message and the input data of the second event message by the vehicle device and whose status time value lies within a predetermined time interval after the event time value of the second event message, and upon determination that no output data to be expected according to the set of rules is contained in the event protocol, to generate the error message.
  • This form of forward search determines whether, for a specific pair of events, the output data expected from the processing of their input data is present in a status information of the status protocol.
  • a corresponding backward search for the input data of two event messages is possible in an analogous manner starting from a status information to be checked.
  • the toll system can also be designed to select input data of an event message to be checked from the event log, to determine whether the status log contains expected output data of at least one first status information item and expected output data of at least one second status information item according to at least one set of rules stored in the toll system, which would result from the consecutive processing of the input data of the event message to be checked by the vehicle device and whose status time value is in each case within a predetermined time interval after the event time value of the second event message to be checked, and to generate the error message if it is determined that no output data to be expected according to the set of rules is contained in the event log.
  • This form of forward search determines whether expected output data from several status information resulting from the processing of their input data are present in the status log for a specific event.
  • a corresponding backward search for the input data of an event message is possible in an analogous manner based on several status information items to be checked.
  • the toll system is designed to collect a toll fee related to the vehicle for the use of the identified traffic area by the vehicle, depending on several state variables of the vehicle device and identifying at least one toll-paying traffic area used by the vehicle on the basis of the recorded position data.
  • the toll system comprises a central data processing device arranged outside the vehicle and the vehicle device comprises a wireless communication device at least for sending data to the central data processing device.
  • the central data processing device is located away from the vehicle.
  • the vehicle device can thus send position data to the central data processing device, which can be designed to receive the position data and, by identifying at least one toll-paying traffic area used by the vehicle on the basis of the recorded position data, to collect a toll fee related to the vehicle for the use of the identified traffic area by the vehicle.
  • the central data processing device can be designed to receive the position data and, by identifying at least one toll-paying traffic area used by the vehicle on the basis of the recorded position data, to collect a toll fee related to the vehicle for the use of the identified traffic area by the vehicle.
  • the vehicle device can transmit data derived from the position data - for example, the identifier of a traffic area identified by the vehicle device on the basis of the position data or the identifier of a toll fee related to the vehicle, which the vehicle device has determined by identifying at least one toll-paying traffic area used by the vehicle on the basis of the recorded position data - to the central Send data processing device. If an identifier of an identified traffic area is transmitted, the central data processing device determines a toll fee based on the identifier of the identified traffic area.
  • the toll fee received by the central data processing device or alternatively/optionally determined is assigned by the central data processing device to a user account, for which the central data processing device sends a request to debit the toll fee and credit it to a toll operator's account to an account management data processing device.
  • the vehicle device sends an identifier of the vehicle device, the vehicle, or the user together with the position data and/or the data derived from the position data to the central data processing device.
  • the identifier of the vehicle device or the vehicle serves the central data processing device to relate the collected toll fee to the vehicle from which the position data originated in order to charge a toll fee to the user who actually drove through the identified traffic area.
  • the identifier of the vehicle device, the vehicle, or the user is stored in the central data processing device in linkage with the user's account data.
  • the central data processing device can assign the position data, the identifier of the identified traffic area, and/or the toll fee to the user account.
  • the identifier of the vehicle device, the vehicle, or the user is a possible state variable of the vehicle device.
  • the position data processing process with which the vehicle device processes the position data and/or data derived from the position data for the purpose of collecting a vehicle-related toll fee to be levied for the use of a traffic area by the vehicle that is identifiable based on the recorded position data, is dependent on the identifier of the vehicle device, the vehicle, or the user, in that the position data processing involves linking the position data and/or the data derived from the position data with the identifier of the vehicle device, the vehicle, or the user.
  • the vehicle device is designed to process the position data and/or data derived from the position data in a position data processing process only when the vehicle device is ready for operation for the purpose of collecting a toll fee related to the vehicle, which is to be collected for the use of a traffic area by the vehicle that is identifiable on the basis of the recorded position data.
  • a value of an operational readiness state which, incidentally, forms a state variable of the vehicle device—is stored in the vehicle device, which can correspond to one of at least two values: a given operational readiness and a lack of operational readiness.
  • the vehicle device is designed to monitor its operational readiness state and, following a change in the value of the operational readiness state from "given" to "lacking,” to discontinue the position data processing process, i.e., to no longer perform it even if position data is still being acquired.
  • the vehicle device can alternatively or optionally be designed to acquire position data of vehicle positions only when the vehicle device is in operational readiness, which implies that if operational readiness is lacking, the position data processing process is also discontinued.
  • the toll system according to the invention is characterized in that a first state variable of the vehicle device is a registered identifier of the vehicle device, the vehicle or a user of the vehicle and a second state variable of the vehicle device is a registered operational readiness state of the vehicle device.
  • the vehicle device is preferably designed to process the position data and/or data derived from the position data, depending on at least the identification of the vehicle device, the vehicle or the user and the registered operational readiness state, for the purpose of collecting a vehicle-related toll fee to be charged for the use of a traffic area by the vehicle that is identifiable on the basis of the recorded position data.
  • the toll system preferably comprises a central data processing device arranged outside the vehicle, and the vehicle device comprises a wireless communication device in the form of a mobile radio communication device at least for sending position data and/or data derived from the position data together with the identification of the vehicle device, the vehicle, or the user to the central data processing device.
  • the vehicle device is designed to send the position data and/or the data derived from the position data together with the identification of the vehicle device, the vehicle, or the user to the central data processing device by means of the mobile radio communication device as part of the position data processing process of processing the position data and/or the data derived from the position data for the purpose of collecting a toll fee related to the vehicle.
  • the central data processing device is preferably designed to link the received data derived from the position data and/or data derived from the received position data, for example a toll fee, with a user account that is stored in the central data processing device in a manner linked to the identification of the vehicle device, the vehicle or the user.
  • An example of an in-vehicle equipment identifier is a serial number of the in-vehicle equipment.
  • Another example of an in-vehicle equipment identifier is the mobile phone number (e.g., MSISDN, "Mobile Subscriber Integrated Services Digital Network Number") of the in-vehicle equipment's mobile communications device.
  • An example of a vehicle identifier is the vehicle registration number (VIN) of the license plate attached to the front and rear of the vehicle (colloquially known as the "license plate").
  • VIN vehicle registration number
  • Another example of a vehicle identifier is the vehicle identification number (colloquially known as the "chassis number") of the vehicle's official registration certificate.
  • An example of a user identifier is a user ID assigned by the toll operator or chosen by the user, which can consist of a user name and a password.
  • Further status variables of the vehicle equipment can be: a registered vehicle class of the vehicle, a registered determination of the use or non-use of a toll road area by the vehicle, a registered toll-obligation or toll-exempt status of the vehicle, a registered availability status of a specific service of the vehicle equipment.
  • the vehicle class examples are a weight class, a length class, an axle class and an emissions class.
  • the amount of the toll as data derived from the position data is in this case dependent on the vehicle class or possibly on several different types of vehicle classes.
  • the vehicle class is also an inventive state variable of the vehicle device because the position data processing process, regardless of whether the vehicle device determines the amount of the toll (first case) or the central data processing device determines the amount of the toll from the position data transmitted by the vehicle device or data derived from the position data (second case), depends on the value of the vehicle class, which in the second case is sent by the vehicle device to the central data processing device together with the position data or the data derived from the position data as part of the position data processing.
  • the registered determination of the use or non-use of a toll road area by the vehicle may affect the way in which the position data and/or data derived from the position data are processed by the vehicle equipment, so that the result of the position data processing depends on whether the vehicle is on a toll road area or not.
  • Whether the vehicle equipment is required to process position data at all depends on the registered toll-paying or toll-exempt status. If the vehicle has been declared toll-exempt in the vehicle equipment, toll collection by the vehicle equipment must be excluded.
  • the registered availability status of a specific service of the vehicle equipment may determine whether and, if so, when the vehicle equipment sends position data or data derived from position data to a central data processing device and/or, if applicable, to which of several central data processing devices.
  • the vehicle equipment can be configured to send the recorded position data to a central data processing device of an anonymization service instead of to a central data processing device of the toll operator.
  • This central data processing device forwards the position data to the toll operator's central data processing device with its own identifier, which, from the perspective of the central data processing device, does not allow any conclusions to be drawn about the vehicle device from which it originated.
  • the toll operator's central data processing device After determining the toll fee from the position data, the toll operator's central data processing device receives the identifier of the vehicle equipment, the vehicle, or the user from the central data processing device of the anonymization service. If the "Anonymous Position Data Provision" service is not available, the vehicle device sends the position data directly to the toll operator's central data processing facility.
  • Another possible state variable is the identifier of the toll road area whose use by the vehicle was determined based on the position data by the vehicle device.
  • the position data or data derived from the position data in an intermediate step in the process for determining the used toll road area constitute the input data according to the invention.
  • the toll system preferably has at least one central data processing device arranged outside the vehicle, and the vehicle device comprises at least one mobile radio communication device for sending and/or receiving data to and/or from the central data processing device, at least one position determination device which is designed to receive and process signals from a global navigation satellite system and to generate position data by processing them, at least one displacement sensor for detecting distances traveled, at least one acceleration or yaw rate sensor for detecting changes in the direction of travel of the vehicle, at least one data memory in which software of the vehicle device is stored, at least one main memory into which software for use by the vehicle device is loaded, at least one data memory in which at least one time value of the expiration of the validity of software to be used by the vehicle device is stored, at least one data memory in which at least temporarily position data, data from identified traffic areas and/or data from toll collections are stored, at least one data memory in which a vehicle registration number of the vehicle is stored, at least one data memory in which a vehicle class of the vehicle is stored, at least one processor which is configured to
  • Each of these events can trigger a change in the value of a state variable due to the execution of instructions for their processing, which are stored for this purpose in the vehicle device.
  • each of the events (i) to (v) or a specific combination of these events can trigger a change in the operational readiness value of the vehicle equipment from “operational” to "not operational” after a period of time in which one or more of these events have occurred.
  • the operational readiness value can change from "operational” to "limited operational readiness.” Only if the positioning device fails to provide position data from signals of a global navigation satellite system for a longer period of time, for example, 1 minute, does the operational readiness value change from "limited operational readiness” to "not operational.” If the positioning device again provides position data from signals of a global navigation satellite system before the expiration of the longer period of 1 minute, the operational readiness value can change from "limited operational readiness” back to "operational.”
  • events (xii) to (xvii) are self-explanatory in light of the above explanations.
  • events (xii) to (xvii) it should be noted that these events each constitute only one of several successive events that, when combined, lead to the intended results.
  • the event of receiving an instruction to change the vehicle registration number can trigger a chain of several successive events (password query, password entry, authentication, sending a request to the central data processing facility, encryption of this request, etc.), which ultimately lead to the entry of the changed vehicle registration number in the status log.
  • examples of the certain volume include a number of toll collections (for example, the number of detected used traffic areas) or a sum of toll fees that were calculated for traffic areas used consecutively.
  • a single data storage device is sufficient to store said data; however, there should preferably be several data storage devices: a first data storage device for storing the software for processing position data and/or data derived from the position data, a second data storage device for temporarily storing the position data and at least a third data storage device for storing the time value of the expiry of the validity of the software used to process position data and/or data derived from the position data, data from identified traffic areas and/or toll collections, data from the vehicle registration number of the vehicle and data from the vehicle class of the vehicle.
  • the toll system is characterized in that at least steps g) and h) are carried out using at least one set of rules stored in the vehicle device and any error message generated is stored in the vehicle device and/or is sent to a central data processing device of the toll system arranged outside the vehicle by means of a mobile radio communication device included in the vehicle device.
  • the vehicle device of such a toll system according to the invention with decentralized error checking is further developed to carry out a self-test in an event-dependent, time-dependent, location-dependent and/or random manner, in which the vehicle device carries out steps g) i) and h) for at least one event message of the event protocol to be checked, wherein the event of the execution of the self-test is stored as input data together with the time value of the execution of the self-test as an event message in the event protocol and wherein the at least one event message to be checked is defined in that it has an event time value that is delayed compared to the time value of the last preceding self-test.
  • the vehicle device of such an inventive toll system with decentralized error checking has a mobile radio communication device for wirelessly sending the status log via at least one mobile radio network to at least one central data processing device of the toll system arranged outside the vehicle and is designed to send the status log to the central data processing device by means of the mobile radio communication device, to receive from the central data processing device by means of the mobile radio communication device an instruction to carry out step g) ii) with regard to at least one item of status information to be checked as defined by the central data processing device, to carry out step g) ii) with regard to the at least one item of status information to be checked as defined by the central data processing device and h) to generate at least one error message upon detection of a lack of input data to be expected according to the at least one set of rules and/or upon detection of the presence of input data prohibited according to the at least one set of rules and to send this error message to the central data processing device by means of the mobile radio communication device.
  • a mobile radio communication device for wirelessly sending the status log via at least one
  • the central data processing device is designed to receive the status protocol, to determine the status information to be checked based on predetermined criteria and to send a check request regarding the status information to be checked to the vehicle device.
  • the toll system is characterized in that the toll system comprises at least one central data processing device arranged outside the vehicle, the vehicle device has at least one vehicle-side communication device for wirelessly sending the event log to the central data processing device and at least one vehicle-side communication device for wirelessly sending at least one item of status information of the status log to the central data processing device and is designed to send the event log and at least one item of status information of the status log to the central data processing device, wherein the central data processing device is designed to receive the event log sent by the vehicle device and the to receive at least one item of status information sent by the vehicle device and to carry out at least steps g) and h) using at least one set of rules stored in the central data processing device.
  • this status information is the status information to be checked according to the invention. If the vehicle device - because it is designed accordingly - sends an extract of the status protocol that comprises several items of status information, or the entire status protocol that comprises several items of status information, the central data processing system is designed to determine from the several items of status information in the status protocol or the extract thereof the status information that is the status information to be checked according to the invention.
  • Such a toll system with central error checking preferably comprises at least one roadside DSRC communication device, which is communicatively coupled to the central data processing device, for receiving the at least one item of status information of the status protocol from the vehicle device, while the vehicle device has a first vehicle-side communication device in the form of a mobile radio communication device for wirelessly sending the event protocol to the central data processing device via at least one mobile radio network and a second vehicle-side communication device in the form of a vehicle-side DSRC communication device for wirelessly sending the at least one item of status information of the status protocol to the roadside DSRC communication device and is designed to send the event protocol to the central data processing device via at least one mobile radio network and to send at least one item of status information of the status protocol to the roadside DSRC communication device of the toll system by means of the mobile radio communication device.
  • the roadside DSRC communication device or a roadside control device comprising the roadside DSRC communication device can be designed to send the status information received from the vehicle device to the central data processing device - either on its own initiative or due to a request from the central data processing device for status information received from the DSRC communication device since the last transmission.
  • the toll system provides a particular advantage in the case of a control, in which a roadside control device compares reference data with output data of status information received from the vehicle device for consistency. Depending on the outcome of this comparison, a Initiation of a control-related log check, in which the status information is checked against the event log by the central data processing device as part of a central check or by the vehicle device as part of a decentralised check in order to determine whether unexpected output data is due to an error in the vehicle device (i.e. the toll system) or to an error by the user.
  • a control-related log check in which the status information is checked against the event log by the central data processing device as part of a central check or by the vehicle device as part of a decentralised check in order to determine whether unexpected output data is due to an error in the vehicle device (i.e. the toll system) or to an error by the user.
  • the toll system according to the invention for control-related protocol checking in the case of a central check comprises at least one central data processing device arranged outside the vehicle and at least one roadside control device with at least one roadside DSRC communication device for receiving at least one item of status information of the status protocol from the vehicle device, wherein the vehicle device has a first communication device in the form of a mobile radio communication device for wirelessly sending the event protocol to the central data processing device via at least one mobile radio network and a second communication device in the form of a vehicle-side DSRC communication device for wirelessly sending at least one item of status information of the status protocol to the roadside DSRC communication device and is designed to send the event protocol to the central data processing device via the mobile radio communication device via at least one mobile radio network and to send at least one item of status information of the status protocol to the roadside DSRC communication device of the toll system via the vehicle-side DSRC communication device, wherein the roadside control device is designed to receive at least one item of status information of the status protocol from the vehicle device to receive by
  • the roadside DSRC communication device can be designed to receive the status protocol or the extract of the status protocol with a plurality of status information items, wherein the roadside control device is designed in this case to obtain from the status protocol the status information with the output data with which the reference data are to be compared.
  • the toll system for check-related protocol checking comprises, for example, at least one central data processing device arranged outside the vehicle and at least one roadside control device with at least one roadside DSRC communication device for receiving at least one item of status information of the status protocol, wherein the vehicle device has a first communication device in the form of a mobile radio communication device for wirelessly sending the event protocol to the central data processing device via at least one mobile radio network and a second communication device in the form of a vehicle-side DSRC communication device for wirelessly sending at least one item of status information of the status protocol to the roadside DSRC communication device and is designed to send the event protocol to the central data processing device by means of the mobile radio communication device and to send at least one item of status information of the status protocol to the roadside DSRC communication device of the toll system by means of the vehicle-side DSRC communication device, wherein the roadside control device is designed to receive at least one item of status information of the status protocol from the vehicle device by means of the roadside
  • the roadside DSRC communication device can be designed to receive the status protocol or the extract of the status protocol with a plurality of status information items, wherein the roadside control device is designed in this case to obtain from the status protocol the status information with the output data with which the reference data are to be compared.
  • control-related protocol check in the event of a deviation or agreement between the output data provided by the vehicle device and or with the reference data recorded or provided at the control device, it can be advantageously determined whether this deviation or agreement is due to an error in the toll system or an error by the user - for example an operating error, a behavioral error (neglect of the duty to cooperate) or an unlawful act (manipulation, falsification or impairment of data or signals).
  • the output data can represent a registered operational readiness state of the vehicle equipment
  • the reference data can represent a state of insufficient operational readiness of the vehicle equipment
  • the roadside control device can be designed to send a problem message about the insufficient operational readiness to the central data processing device in the event that the operational readiness state is that of insufficient operational readiness.
  • the roadside DSRC communication device can be designed to receive the status protocol or an extract of the status protocol with a plurality of status information items, wherein the roadside control device is designed in this case to obtain the status information with the output data in the form of the registered license plate number of the vehicle from the status protocol.
  • Input data can be represented by data relating to the following events: (i) the failure of the positioning device to receive signals from a global navigation satellite system; (ii) the failure of the positioning device to generate position data from signals from a global navigation satellite system; (iii) the quality of at least one signal from a global navigation satellite system and/or at least one position determined by the positioning device falling below a minimum level; (iv) the failure of the signals to receive signals from a displacement sensor; (v) the lack of agreement between heading angles determined from signals from a global navigation satellite system and heading angles determined from changes in heading detected by the acceleration sensor/yaw rate sensor; (vi) the failure to load the operating system from the data memory into the main memory; (vii) the expiration of the validity of the
  • Processing instructions (viii) the absence of a time signal from the timer; (ix) the charge level of the charge storage element falls below a predetermined limit; (x) the failure of the mobile radio communication device to receive signals from base stations of a mobile radio network; (xi) the exceeding of a certain volume of toll collections that could not be transmitted to a central data processing device of the toll system by means of the mobile radio communication device.
  • the output data can represent an identifier of a toll road section last identified as being traveled by the vehicle device
  • the reference data can represent an identifier of a toll road section to be checked that corresponds to the position of the control device and at which the control device is arranged
  • the roadside control device can be designed to send a problem message about the lack of agreement between the identifier of the toll road section last identified as being traveled by the vehicle device and the identifier of the road section to be checked to the central data processing device if the identifier of the toll road section last identified as being traveled by the vehicle device does not match the identifier of the road section to be checked.
  • the roadside DSRC communication device can be configured to receive the status log or an extract from the status log containing multiple items of status information, with the roadside control device in this case being configured to obtain the status information from the status log with the output data in the form of the identifier of the toll road section last identified as traveled by the vehicle device.
  • Input data can be represented by recorded position data from one or more positions useful for identifying the toll road section last identified as traveled. If, during the log check, the recorded position data do not correspond to the identified road section, it is assumed that there was a recognition error in the software for processing the position data and/or data derived from the position data, and a toll system error message is generated. If, during the log check, the recorded position data do correspond to the identified road section, it is assumed that there was an operating error, and a user error message is generated.
  • the output data can represent a position last registered by the vehicle device
  • the reference data can represent a position assigned to the control device
  • the roadside control device can be configured to send a problem message about the lack of agreement between the position last registered by the vehicle device and the position assigned to the control device to the central data processing device if the position last registered by the vehicle device does not match the position assigned to the control device within a permissible deviation (of, for example, 100 meters).
  • a toll system with control-related decentralized or centralized protocol checking can be characterized in that the roadside control device comprises at least one image recording device (for example a camera) for generating at least one image of a license plate of the vehicle and at least one image processing device for obtaining a license plate from the image of the license plate of the vehicle and is designed to generate at least one image of a license plate of the vehicle by means of the camera and to obtain a recorded license plate from the image of the license plate of the vehicle by means of the image data processing device, the output data represent a registered license plate of the vehicle and the reference data represent the recorded license plate of the vehicle, and the roadside control device is further designed to send a problem message about the difference between the registered and recorded license plates to the central data processing device in the event that the registered license plate and the recorded license plate are different.
  • the roadside control device comprises at least one image recording device (for example a camera) for generating at least one image of a license plate of the vehicle and at least one image processing device for obtaining a license plate from the image
  • the roadside DSRC communication device can be designed to receive the status protocol or an extract of the status protocol with a plurality of status information items, wherein the roadside control device is designed in this case to obtain the status information with the output data in the form of the registered license plate number of the vehicle from the status protocol.
  • a toll system with control-dependent decentralized or centralized protocol checking can be characterized in that the roadside control device has at least one detection device for detecting an image and/or a contour of the vehicle and at least one classification device for determining a vehicle class of the vehicle from the detected image and/or the detected contour of the vehicle and is designed to receive at least the status information with the output data in the form of the registered vehicle and/or axle class of the vehicle from the vehicle device by means of the roadside DSRC device, to detect at least one image and/or at least one contour of the vehicle by means of the detection device and to determine a detected vehicle class of the vehicle from the detected image and/or the detected contour of the vehicle by means of the classification device, the output data represent a registered vehicle class of the vehicle, the reference data represent the detected vehicle class of the vehicle and the roadside control device is further designed, in the case in which the registered vehicle class and the detected vehicle class are different, to send a problem message about to send the difference between the registered and the recorded vehicle class to the central data processing facility.
  • the roadside DSRC communication device can be designed to receive a status protocol with a plurality of status information items, wherein the roadside control device is designed in this case to obtain the status information with the output data in the form of the registered vehicle class of the vehicle from the status protocol,
  • the vehicle device it is also possible for the vehicle device to be configured to send only the output data of the status information to the control device, since the output data is sufficient for the control device to compare with the reference data.
  • the central data processing device is configured to request from the vehicle device, in addition to the event log, the status time value of the status information of the output data, and the The vehicle device is designed to send the status time value of the status information of the output data together with the event log to the central data processing device.
  • the vehicle device prefferably configured to send only an extract of the event log with multiple event messages.
  • the said extract can also be considered an event log.
  • the vehicle device prefferably configured to delete event messages from the event log that refer to status information that is no longer current or no longer available, insofar as the outdated values of their state variables have been updated by current values of state variables. This allows the scope of the event log to be limited.
  • the vehicle device has a vehicle-mounted DSRC communication device for wirelessly transmitting at least one item of status information from the status protocol to the roadside DSRC communication device
  • the vehicle device is preferably divided into a first device part and at least one second device part, which is connected to the first device part and is communicatively coupled to the first device part.
  • the first device part has a first processor, which is at least configured to process the position data and/or data derived from the position data depending on several state variables of the vehicle device for the purpose of collecting a vehicle-related toll fee to be collected for the use of a traffic area by the vehicle, which is identifiable on the basis of the recorded position data, and at least one first data memory.
  • the second device part connects the vehicle-mounted DSRC communication device to a second processor, which is configured to control DSRC communication of the vehicle-mounted DSRC communication device with the roadside DSRC communication, and at least one second data memory. and wherein the vehicle device is configured to store the event log in the first data memory and to store the status log in the second data memory.
  • the status log or at least one item of status information of the status log can be quickly provided by the vehicle device for transmission from the vehicle-side DSRC communication device to the roadside DSRC communication device as the vehicle passes a roadside DSRC communication device.
  • a vehicle device for detecting positions of a vehicle by which it is carried, wherein the vehicle device is designed (a) to detect position data of positions of the vehicle (b) to process the position data and/or data derived from the position data as a function of several state variables of the vehicle device for the purpose of collecting a toll fee related to the vehicle, which is to be collected for the use of a traffic area by the vehicle that is identifiable on the basis of the detected position data, (c) to receive or generate input data and (d) to generate output data as a function of the received or generated input data, each output data representing a value of one of the state variables of the vehicle device, characterized in that the vehicle device is further configured to (e) enter status information, each comprising generated output data linked to a status time value, in a status log stored in the vehicle device, (f) enter event messages, each comprising received or generated input data linked to an event time value, in an event log stored in the vehicle device, (g) determine, based on at least one
  • the vehicle device can be designed to (g) determine, based on at least one set of rules stored in the vehicle device, whether (i) for at least one event message of the event protocol to be checked in the status protocol, expected and/or prohibited output data according to the at least one set of rules are contained in at least one item of status information, the status time value of which lies within a predetermined time interval after the event time value of the event message to be checked, and/or (ii) for at least one item of status information of the status protocol to be checked in the event protocol, expected and/or prohibited input data according to the at least one set of rules are contained in at least one event message, the event time value of which lies within a predetermined time interval before the status time value of the status information to be checked, and (h) to generate an error message if a lack of expected output data and/or input data expected according to the at least one set of rules is detected.
  • the vehicle device has a vehicle-mounted DSRC communication device for wirelessly sending at least one item of status information of the status protocol to the roadside DSRC communication device and is divided into a first device part and at least one second device part, which is received by the first device part and is communicatively coupled to the first device part, wherein the first device part has a first processor, which is at least designed to process the position data and/or data derived from the position data as a function of several state variables of the vehicle device for the purpose of collecting a toll fee related to the vehicle, which is to be collected for the use of a traffic area by the vehicle, which is identifiable on the basis of the recorded position data, and at least one first data memory, wherein the second device part has the vehicle-mounted DSRC communication device with a second processor, which is designed to control the DSRC communication of the vehicle-mounted DSRC communication device with the roadside DSRC communication, and at least one second data memory, and wherein the vehicle device is designed is to store the event log in the
  • a method for detecting errors in a vehicle device of a toll system carried by a vehicle comprising the following steps: (a) recording position data of positions of the vehicle by the vehicle device, (b) processing of the position data and/or data derived from the position data by the vehicle device as a function of several state variables of the vehicle device for the purpose of collecting a toll fee related to the vehicle, which is to be collected for the use of a traffic area by the vehicle that is identifiable on the basis of the recorded position data, (c) receiving or generating input data by the vehicle device, and (d) generating output data, each representing a value of one of the state variables of the vehicle device, as a function of the received or generated input data by the vehicle device, characterized by the further steps of (e) entering status information, each comprising generated output data linked to a status time value, in a status log stored in the vehicle device by the vehicle device, (f) entering event messages, each associated with an event time value linked received or generated input data, in
  • the method can provide the following steps: (g) Determination by the vehicle device and/or by a central data processing device of the toll system arranged outside the vehicle, based on at least one set of rules stored in the vehicle device and/or in the central data processing device, whether (i) for at least one event message of the event protocol to be checked, in the status protocol, output data to be expected and/or prohibited according to the set of rules are contained in at least one item of status information, the status time value of which lies within a predetermined time interval after the event time value of the event message to be checked, and/or (ii) for at least one item of status information of the status protocol to be checked, in the event protocol, input data to be expected and/or prohibited according to the set of rules are contained in at least one event message, the event time value of which lies within a predetermined time interval before the status time value of the status information to be checked, by the decentralized processor and/or a central processor of a central data processing device of the toll system, which stores the event protocol and has received the
  • event messages each comprising received or generated input data linked to an event time value
  • status information each comprising generated output data linked to a status time value
  • a status log stored in a second device part of the vehicle device, which is retrieved by the first device part and is communicatively coupled to the first device part
  • a first processor of the first device part carries out the processing of the position data and/or data derived from the position data as a function of several state variables of the vehicle device for the purpose of collecting a toll fee related to the vehicle, which is to be collected for the use of a traffic area by the vehicle, which is identifiable on the basis of the recorded position data
  • a second processor of the second device part controls the sending of status information carried out by the second device part as part of a DSRC communication.
  • a GNSS positioning device 12 receives signals from satellites of a Global Navigation Satellite System (GNSS), for example, GPS, via its GNSS receiving antenna 12b and determines its provisional position—and thus the provisional position of a vehicle 30—from the received satellite signals using its GNSS receiver 12a (see Fig. 2 ), which carries the vehicle device 20.
  • the determined provisional position is further processed by the processor 11 based on direction change values provided by a gyroscope 16 of the vehicle device and on relative path length values of a path traveled in a specific time, provided by the path sensor 21, to a final position (hereinafter referred to as "position") that is more precise than the provisional position, in the course of a process known per se as dead reckoning.
  • GNSS Global Navigation Satellite System
  • the position determination by the processor 11 and the GNSS positioning device 12 is carried out repeatedly - for example, every second - during the course of the movement of the vehicle 30 by the vehicle device 20.
  • the decentralized processor 11 is coupled to a security module 18, which is designed as an independent data processing unit (for example, a chip card) having at least one autonomous control module 18a and a memory area 18b.
  • the autonomous control module 18a is configured to execute requests for the release of data from the memory area 18b and/or the modification or recording of data in the memory area 18b only against authentication.
  • the authentication procedure can be carried out by analyzing a digital signature using a public key stored by the signatory in the memory area 18b of the security module 18.
  • a cryptographic data memory (not shown) can be provided, into which the processor 11 can store data in encrypted form and read it out in decrypted form only with appropriate authentication.
  • the central data processing device 50 can also be carried out by the central data processing device 50 (see Fig. 2 ) to which the user has previously transmitted the data of the initial registration or change, by the central data processing device 50 sending a corresponding instruction for the initial registration or change of the vehicle identification, the axle class and/or the vehicle class via the mobile network 40 (see Fig. 2 ) is sent to the vehicle device 20, which receives this instruction together with the new data by means of a mobile radio transceiver 13 and processes it by means of the decentralized processor 11.
  • the encrypted storage of the vehicle identification, the axle class and/or the emission class in the memory area 18b of the security module 18 or in the cryptographic data memory can be initiated by means of corresponding instructions from the decentralized processor 11.
  • These - vehicle-internal - instructions form second input data according to the invention, which are stored together with a second event time value in the event log as a second event message.
  • the autonomous control module 18a of the security module 18 sends a corresponding confirmation signal to the decentralized processor 11, which is stored as third input data according to the invention with a third event time value in the event log by the decentralized processor 11 as a third event message.
  • the status time value is the time value at which the output data was entered into the status log and thus lies chronologically after the first, second, and third event time values.
  • the specified time interval within which the event time values of event messages that must precede the entry of the status information is, for example, 10 seconds for vehicle data (vehicle identification, vehicle class). This value would also apply to a time range within which the event time values of event messages that require the entry of the status information must lie if the status time value did not lie after the third event time value, but instead fell, for example, on the first event time value; only the temporal position of the time range, which has the same temporal width as the interval, would have to be adjusted accordingly.
  • the status protocol is stored in the DSRC communication module data read/write memory 22d of a vehicle-mounted DSRC communication module, which is mounted at a distance from the vehicle device 10 on the inside of the windscreen of the vehicle 30 in such a way that the DSRC transceiver 22a is connected by means of its DSRC antenna 22b to a roadside DSRC communication device 63a of a roadside control device 60 arranged outside the vehicle 30 (see Fig. 2 ).
  • the DSRC communication carrier is microwave in the 5.8 GHz frequency range.
  • infrared light 850 nm
  • photodiodes being used as the receiving elements and IR light-emitting diodes as the transmitting elements.
  • the decentralized processor 11 To store status information in the DSRC communication module data read/write memory 22d, the decentralized processor 11 communicates wirelessly or via a wired communication connection with the DSRC communication module processor 22c of the DSRC communication module 22.
  • the processor 11 records - as already mentioned - every second - a position of the vehicle 30 and processes the recorded position data of these positions for the purpose of collecting a vehicle-related toll fee to be charged for the use of a section of the route by the vehicle 30, which can be identified on the basis of the recorded position data.
  • the decentralized processor 11 compares, by means of a toll fee determination program executed in the main memory 17b, position data of one or more recorded positions with geographical elements of a digital map, each of which is assigned an identifier of a route section If there is sufficient geographical correspondence between the recorded position data and a specific geographical element, the route section whose identifier is linked to the specific geographical element is recognized as being traveled. The decentralized processor 11 then uses the identifier of the route section recognized as being traveled to determine a toll fee that depends on the axle class and the emission class of the vehicle 30.
  • axle class and pollutant class are state variables of the vehicle equipment according to the invention because they determine the amount of the toll and thus influence the processing of the position data into a toll fee related to the vehicle.
  • the central processor 11 then instructs the mobile radio transceiver 13 to transmit the determined toll fee together with the vehicle identification via the mobile radio network 40 to the central data processing device 50 of a toll center 58 (see Fig. 2 ).
  • the central data processing device 50 of the toll center 58 assigns the toll fee to a user account based on the vehicle identification, from which the toll fee is deducted by a data processing device of a bank (not shown) and credited to the toll operator's account.
  • the vehicle identification is also an inventive state variable of the vehicle device because it determines the allocation of the toll fee to a user and thus influences the processing of the position data into a toll fee related to the vehicle.
  • the central processor 11 instructs the mobile radio transceiver 13, by means of a position data processing program executed in the main memory 17b, to send recorded position data - in particular position data of several positions recorded in immediate succession - together with the vehicle identification, axle class and pollutant class of the vehicle 30 - to the central data processing device 50.
  • the central processor 51 of the central data processing device 50 compares the received position data of one or more recorded positions with geographical elements of a digital map, each of which is assigned an identifier of a route section. If there is sufficient geographical correspondence between the recorded position data and a specific geographical element, the route section whose identifier is linked to the specific geographical element is recognized as being traveled. Subsequently, the central processor 51 uses the identifier of the route section recognized as being traveled to determine a toll fee that depends on the axle class and the emission class of the vehicle 30.
  • the vehicle identifier, axle class, and emission class are state variables of the vehicle device according to the invention because they determine the amount of the toll fee and the allocation of the toll fee to a user and thus influence the processing of the position data into a vehicle-related toll fee.
  • the route section recognized as being traveled also represents a status variable of the vehicle device, the identifier of which is stored as output data of a status information in the status protocol as the currently traveled route section at the instigation of the decentralized processor 11 in the DSRC communication module data read-write memory 22d.
  • the decentralized processor 11 is configured to check the operational readiness of the vehicle device 20 upon the on-board device 10 receiving power via the power supply connection 19 or upon the on-board device 10 being switched on, and to commission the vehicle device as far as possible. To this end, the decentralized processor 11 initially at least attempts to load the toll fee calculation program from the data read/write memory 17a into the main memory 17b. If the loading of the toll fee calculation program into the main memory 17b fails, it writes an event message about the attempted loading and an event message about the failed loading to the event log stored in the data read/write memory 17a.
  • the failure of the charging process causes the controller to set an operational readiness state to "lacking", to indicate this to the user via the display device 15, and to store status information about the lack of operational readiness of the vehicle device in the status log stored in the DSRC communication module data read-write memory 22d.
  • the decentralized processor 11 checks whether the software, which includes the toll collection program and the digital card, is still valid by reading a time value of the software's expiration date from the memory area 18b of the security module 18 and comparing it with a current time value of the timer 14, for example, a radio clock. If the software is invalid because the current time value of the timer is greater than the expiration date of the software's validity, the decentralized processor 11 writes an event message about the execution of the validity check and an event message about the negative result of the validity check to the event log stored in the data read/write memory 17a.
  • the result of the invalidity of the software causes the controller to set the vehicle device's operational readiness status to "lacking", to display this to the user via the display device 15, and to store status information about the lack of operational readiness of the vehicle device in the status log stored in the DSRC communication module data read-write memory 22d.
  • the attempt to load the toll calculation program into the working memory 17b and to check the validity of the software can also be carried out in the reverse order.
  • the status protocol can alternatively or optionally be stored in the data write-read memory 17a of the vehicle device in addition to being stored in the DSRC communication module data write-read memory 22d.
  • the decentralized processor 11 After the decentralized processor 11 has commissioned the vehicle equipment 20 in this way—assuming successful loading and valid software—it performs an internal log check as part of a self-test. This check relates to event messages and status information from a previous operating cycle of the vehicle equipment. These are all event messages stored in the event log whose event time values lie between the penultimate event of switching on or establishing a power supply to the vehicle equipment 20 or the vehicle device 10 via the power supply connection 19 and the last event of switching off or deactivating the power supply to the vehicle equipment 20 or the vehicle device 10 via the power supply connection 19.
  • the decentralized processor 11 checks, based on at least one set of rules stored in the data write-read memory 17a, whether for each event message of the event protocol in the status protocol - as far as specified in the set of rules - output data to be expected according to the set of rules are contained in at least one item of status information, the status time value of which lies within a predetermined time interval of, for example, 10 seconds after the event time value of the event message to be checked, and upon detection of a lack of output data to be expected according to the at least one set of rules, generates an error message, for the display of which on the display device 15 the decentralized processor does not issue an instruction to the display device 15, but rather for its transmission to the central data processing device 50 (see Fig. 2 ) the mobile radio transceiver 13 is instructed by the decentralized processor.
  • the set of rules comprises a database in which input data of one or more event messages are linked to output data of one or more status information items, whereby for a forward search the output data linked to the input data of one or more event messages to be checked are the expected output data.
  • the input data of the three event messages "Attempt to load the toll fee calculation program into the main memory 17b," “Failure to load the toll fee calculation program into the main memory 17b,” and “Registration of a lack of operational readiness” are linked to the output data of a status information "lack of operational readiness.”
  • the protocol check according to the invention provides—and this is one of its key advantages—that the event messages and the status information are correlated with each other over the specified time range. Event messages that fall outside this specified time range with regard to status information are not subject to the protocol check and therefore cannot lead to an error message.
  • the decentralized processor 11 is configured to attempt to load the toll determination program into the main memory 17b again after a predetermined period of time has elapsed since the detection of the lack of operational capability due to the unsuccessful attempt to load the toll determination program into the main memory 17b. In the event of a successful loading of the toll determination program into the main memory 17b, the decentralized processor 11 is configured to change the value of the status information of the operational readiness state from "lack of operational readiness" to "sufficient operational readiness.”
  • the vehicle equipment 20 After performing this self-test, the vehicle equipment 20 is ready for operation (provided it is not in a state of lack of operational readiness) and displays this given operational readiness on the display device 15.
  • the vehicle device 20 In the event that the vehicle device 20 is operated without connection to an external power supply (e.g., vehicle battery), the vehicle device receives its operating current from a rechargeable battery (accumulator as an example of a charge storage element) 19a, which is included in the vehicle device 10.
  • the decentralized processor 11 is designed to receive measured values of the charge state of the battery 19a at predetermined time intervals (e.g., 10 minutes) and to write these values, together with the measurement time, as an event time value in the event log as an event message.
  • the decentralized processor 11 is designed to compare the measured value of the charge state with a limit value of the charge state for each measurement and to store the undershoot of the limit value as input data of an event message in the event log.
  • the decentralized processor 11 is further configured to count the entries from those immediately consecutive measurements of the state of charge whose measured values fall below the limit value, to set the counter to zero if the measured value does not fall below the limit value during a state of charge measurement, and to determine a lack of operability of the vehicle device 20 when the counter is at three.
  • the counter readings are entered into the event log by the decentralized processor 11 as input data from counter reading events, as is the determination of the lack of operability, which is subsequently written to the status log as status information together with the time of the determination.
  • the decentralized processor 11 is configured to acquire measured values again after a predetermined period of time has elapsed since the detection of the lack of operational capability due to the insufficient state of charge and to check whether the measured value of the state of charge of the battery 19a still falls below the limit value. If three immediately consecutively acquired measured values of the state of charge do not fall below the limit value, the decentralized processor 11 is configured to change the value of the status information of the operational readiness state from "lack of operational readiness" to "given operational readiness.”
  • the decentralized processor 11 of the vehicle device 10 - and thus the vehicle device 20 - is designed to acquire preliminary position data by means of the GNSS positioning device 12 and to generate final position data (hereinafter referred to as "position data") from these preliminary position data on the basis of path length data from the path sensor 21 and direction angle change data from the gyroscope 16, and to process these position data as described above depending on several state variables of the vehicle device for the purpose of collecting a vehicle-related toll fee to be charged for the use of a toll road section by the vehicle that is identifiable on the basis of the acquired position data.
  • position data final position data
  • the processor 11 is designed to detect the events (i) of the failure to receive signals from a global navigation satellite system at the position-determining device 12, (ii) of the failure to generate position data from signals from a global navigation satellite system by the position-determining device 12, (iii) of the quality of at least one signal from a global navigation satellite system and/or at least one position determined by the position-determining device 12 falling below a minimum quality level, (iv) of the failure to receive signals at the interface for receiving signals from a displacement sensor 21 and/or (v) of the lack of agreement between the direction of travel angles determined from signals from a global navigation satellite system and the direction of travel angles determined from changes in direction detected by the gyroscope 16, to enter these events with corresponding input data in the event log and, in the case of one-time or multiple - in particular immediately consecutive detection of such events, the value of the operational readiness status of the vehicle equipment shall be set to "inadequate" and corresponding status information shall be entered in the status log.
  • the decentralized processor 11 is configured to acquire measured values again after a predetermined period of time has elapsed since the detection of the lack of operational capability due to the insufficient state of charge and to check whether the measured value of the state of charge of the battery 19a still falls below the limit value. If three measured values of the state of charge acquired in immediate succession do not fall below the limit value, the decentralized processor 11 is configured to change the value of the status information of the operational readiness state from "lack of operational readiness" to "given operational readiness.”
  • the central data processing device 50 is comprised of a control center 58 of the toll system and has a central communication device 53, a central processor 51, a first central data memory 56, and a second central data memory 57.
  • the central communication device 53 is a network card (network adapter, network interface card), which is the interface between the public telephone network, mobile radio network 40, and/or the Internet, and the central processor 51 comprised of the central data processing device 50.
  • the first central data memory 56 comprises user data linked to an identifier of the vehicle 30 (vehicle registration number), to a user account and to toll fees associated with identifiers of toll road sections, which were sent by the vehicle device 20 together with the vehicle registration number to the central data processing device after the detection of driving on at least one toll road section.
  • the second central data memory 57 is provided for storing status information from status logs and event messages from event logs linked to the vehicle registration numbers of vehicles, for example the vehicle 30, which the central data processing device 50 receives from vehicle devices, for example the vehicle device 20.
  • the vehicle device 20 can be designed to receive an instruction to transmit the status protocol via the mobile radio network 40 by means of the mobile radio transceiver 13 and to comply with this instruction by the decentralized processor 11 of the vehicle device 10 - and thus the vehicle device 20 - instructing the mobile radio transceiver 13 to send the status protocol via a mobile radio network 40 to the central data processing device 50 arranged outside and away from the vehicle.
  • the central processor 51 is configured to store the status log received via the mobile radio network 40 by means of the central communication device 53 in the second central data memory 57 and to check for the presence of unusual status information or unusual combinations of status information.
  • An unusual piece of status information can, for example, be that whose output data represents a lack of operability of the vehicle device.
  • An unusual combination of status information can, for example, be formed by two pieces of status information that were registered directly one after the other with respect to a traveled section of road and whose output data represent the same identifier of the traveled section of road.
  • the central processor 51 identifies an unusual status information or an unusual combination of status information, it instructs the central communication device 53 to send an instruction to transmit the event log to the vehicle device 20.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Devices For Checking Fares Or Tickets At Control Points (AREA)

Claims (14)

  1. Système de péage, comprenant
    au moins un dispositif embarqué (20) transporté par un véhicule (30), et
    au moins un dispositif central de traitement de données (50) disposé à l'extérieur du véhicule,
    dans lequel le dispositif de véhicule (20) est formé,
    a) collecter des données de position à partir de positions du véhicule (30),
    b) en fonction de plusieurs variables d'état du dispositif de véhicule (20), traiter les données de position et/ou des données dérivées des données de position dans le but de percevoir un péage se rapportant au véhicule (30), qui doit être perçu pour l'utilisation par le véhicule (30) d'une surface de circulation qui peut être identifiée à l'aide des données de position saisies,
    c) recevoir ou générer des données d'entrée
    les données d'entrée représentant un ou plusieurs des événements suivants :
    i) l'absence de réception de signaux d'un système global de navigation par satellite au niveau d'un dispositif de détermination de position (12) compris par le dispositif de véhicule (20), qui est conçu pour recevoir et traiter des signaux d'un système global de navigation par satellite et pour générer des données de position par leur traitement;
    ii) l'absence de génération de données de position à partir de signaux d'un système global de navigation par satellite au niveau d'un dispositif de détermination de position (12) compris par l'équipement de véhicule (20), qui est adapté pour recevoir et traiter des signaux d'un système global de navigation par satellite et pour générer des données de position par leur traitement;
    iii) le fait de ne pas atteindre une qualité minimale de la qualité d'au moins un signal d'un système global de navigation par satellite et/ou d'au moins une position déterminée par un dispositif de détermination de position (12) compris par le dispositif de véhicule (20), qui est conçu pour recevoir et traiter des signaux d'un système global de navigation par satellite et pour générer des données de position par leur traitement;
    iv) l'omission de la réception de signaux au niveau de l'interface de réception de signaux d'un capteur de déplacement (21) compris dans le dispositif pour véhicule;
    v) le manque de concordance entre des angles de direction de déplacement déterminés à partir de signaux d'un système global de navigation par satellite et des angles de direction de déplacement déterminés à partir de changements de direction de déplacement détectés par un capteur d'accélération/de taux de lacet (16) du dispositif de véhicule (20);
    vi) l'échec du chargement d'un logiciel depuis une mémoire de données (17a) du dispositif embarqué (20) dans une mémoire de travail (17b) du dispositif embarqué;
    vii) le dépassement d'une valeur temporelle, stockée dans une mémoire de données (17a) du dispositif embarqué (20) ou dans une mémoire de travail (17b) du dispositif embarqué, de l'expiration de la validité de logiciels à utiliser par le dispositif embarqué (20);
    viii) l'absence d'un signal de temps d'une minuterie (14) de l'équipement du véhicule (20);
    ix) le fait de passer en dessous d'une valeur limite prédéterminée d'un état de charge d'un élément de stockage de charge (19a) de l'équipement de véhicule (20) ;
    x) l'absence de réception de signaux de stations de base d'un réseau de téléphonie mobile (40) au niveau d'un dispositif de communication mobile (13) de l'équipement de véhicule (20) ;
    xi) le dépassement d'un certain volume de relevés de péage qui n'ont pas pu être transmis au moyen d'un dispositif de communication mobile (13) de l'équipement du véhicule (20) au dispositif central de traitement de données (50) du système de péage ;
    xii) la réception d'une instruction de blocage d'un service de l'équipement de véhicule via un dispositif de communication mobile (13) de l'équipement de véhicule (20) ;
    xiii) la réception d'une instruction de changement du numéro d'immatriculation du véhicule (30) ;
    xiv) la réception d'une instruction de changement de catégorie du véhicule (30) ;
    xv) l'exécution d'un autotest de l'équipement du véhicule (20) ;
    xvi) la réception d'une activation ou d'un blocage d'un service de l'équipement embarqué (20) ;
    xvii) la réception d'une instruction de modification des faits concernant un péage obligatoire ou une exemption de péage pour le véhicule (30) ;
    d) générer, en fonction des données d'entrée reçues ou générées, des données de sortie représentant chacune une valeur de l'une des variables d'état de l'équipement de véhicule (20)
    dans lequel une première variable d'état du dispositif (20) du véhicule
    i) un identifiant enregistré de l'équipement du véhicule (20), du véhicule (30) ou d'un utilisateur du véhicule (30),
    ii) une catégorie de véhicule enregistrée du véhicule (30),
    iii) une constatation enregistrée de l'utilisation ou de la non-utilisation par le véhicule d'une surface de circulation soumise à péage (30),
    iv) un état de péage ou d'absence de péage enregistré du véhicule (30), ou
    v) un état de disponibilité enregistré d'un service particulier de l'équipement embarqué (20 et une deuxième variable d'état de l'équipement de véhicule (20) est un état de préparation au fonctionnement enregistré de l'équipement de véhicule (20), et
    e) des informations d'état, qui comprennent chacune des données de sortie générées associées à une valeur de temps d'état, dans au moins un protocole d'état mémorisé dans le dispositif de véhicule (20),
    caractérisé en ce que
    le dispositif de véhicule (20) est formé,
    f) enregistrer des messages d'événement, qui comprennent chacun des données d'entrée reçues ou générées associées à une valeur temporelle d'événement, dans au moins un journal d'événements enregistré dans l'équipement de véhicule (20),
    et le dispositif central de traitement de données (50) est formé,
    g) déterminer, à l'aide d'au moins un ensemble de règles mémorisées dans le dispositif central de traitement de données (50), si
    i) pour au moins un message d'événement à contrôler du protocole d'événement, des données de sortie attendues et/ou interdites sont contenues dans le protocole d'état conformément à l'au moins un ensemble de règles dans au moins une information d'état dont la valeur temporelle d'état se situe à l'intérieur d'un intervalle de temps prédéfini après la valeur temporelle d'événement du message d'événement à contrôler, et/ou
    ii) pour au moins une information d'état à contrôler du protocole d'état, des données d'entrée attendues et/ou interdites sont contenues dans au moins un message d'événement dans le protocole d'événement conformément à l'au moins un ensemble de règles, dont la valeur temporelle d'événement se situe à l'intérieur d'un intervalle de temps prédéfini avant la valeur temporelle d'état de l'information d'état à contrôler,
    et
    h) en cas de constatation d'un manque de données de sortie attendues conformément à l'au moins un ensemble de règles et/ou de données d'entrée attendues
    et/ou
    en cas de constatation d'une présence de données de sortie interdites conformément à l'au moins un ensemble de règles et/ou de données d'entrée interdites
    générer un message d'erreur.
  2. Système de péage selon la revendication 1, caractérisé en ce que
    l'équipement du véhicule (20) comprend
    - au moins un dispositif de communication mobile (13) pour l'envoi et/ou la réception de données vers et/ou depuis le dispositif central de traitement de données (50),
    - au moins un dispositif de détermination de position (12), qui est conçu pour recevoir et traiter des signaux d'un système global de navigation par satellite et pour générer des données de position par leur traitement,
    - au moins un capteur de déplacement (21) pour enregistrer les distances parcourues,
    - au moins un capteur d'accélération/de taux de lacet (16) pour détecter les changements de direction du véhicule (30),
    - au moins une mémoire de données (17a) dans laquelle est stocké un logiciel de l'équipement du véhicule,
    - au moins une mémoire de travail (17b) dans laquelle est chargé un logiciel destiné à être utilisé par le dispositif pour véhicule (20),
    - au moins une mémoire de données (17a, 18b) dans laquelle est stockée au moins une valeur temporelle de l'expiration de la validité du logiciel à utiliser par l'équipement de véhicule,
    - au moins une mémoire de données (17b, 18b) dans laquelle sont mémorisées au moins temporairement des données de position, des données de surfaces de circulation identifiées et/ou des données de relevés de péage,
    - au moins une mémoire de données (17a, 18b) dans laquelle est enregistré un numéro d'immatriculation du véhicule,
    - au moins une mémoire de données (17a, 18b) dans laquelle est enregistrée une catégorie de véhicule du véhicule,
    - au moins un processeur (11) configuré pour générer les données de sortie par le traitement des données d'entrée,
    - au moins une minuterie (14) et
    - au moins un élément de stockage de charge (19a) pour l'alimentation électrique au moins temporaire d'au moins un processeur (11) du dispositif de véhicule (20).
  3. Système de péage selon l'une des revendications 1 ou 2, caractérisé en ce que
    l'équipement du véhicule (20) comprend
    - au moins un dispositif de communication embarqué (13, 22) pour l'envoi sans fil du protocole d'événements au dispositif central de traitement de données, et
    - au moins un dispositif de communication (13, 22) côté véhicule pour l'envoi sans fil d'au moins une information d'état du protocole d'état à l'installation centrale de traitement de données
    et est formé
    envoyer le protocole d'événements et au moins une information d'état du protocole d'état au dispositif central de traitement de données (50),
    dans lequel le dispositif central de traitement de données (50) est formé,
    - recevoir le journal des événements envoyé par le dispositif embarqué (20) et les au moins une information d'état envoyée par le dispositif embarqué (20), et
    - d'exécuter au moins les étapes g) et h) à l'aide d'au moins un ensemble de règles mémorisées dans le dispositif central de traitement de données (50).
  4. Système de péage selon la revendication 3, caractérisé en ce que
    le système de péage comprend au moins un dispositif de communication DSRC (63a) côté route, couplé en termes de communication au dispositif central de traitement de données (50), pour la réception de l'au moins une information d'état du protocole d'état de l'équipement de véhicule (20), et
    le dispositif de véhicule (20)
    - un premier dispositif de communication embarqué sous la forme d'un dispositif de communication mobile (13) pour l'envoi sans fil du protocole d'événement au dispositif central de traitement de données (50) par l'intermédiaire d'au moins un réseau mobile (40) et
    - un deuxième dispositif de communication embarqué sous la forme d'un dispositif de communication DSRC embarqué (22) pour l'envoi sans fil de l'au moins une information d'état du protocole d'état au dispositif de communication DSRC routier (63a)
    et est formé,
    - envoyer le protocole d'événement au moyen du dispositif de communication mobile (13) par au moins un réseau mobile (40) au dispositif central de traitement de données (50) et
    - de l'au moins une information d'état du protocole d'état au moyen du dispositif de communication DSRC côté véhicule (22) vers le dispositif de communication DSRC côté route (63a) du système de péage.
  5. Système de péage selon l'une des revendications 1 ou 2, caractérisé en ce que
    le système de péage comprend
    - au moins un dispositif de contrôle côté route (60) avec au moins un dispositif de communication DSRC côté route (63a) pour recevoir au moins une information d'état du protocole d'état provenant du dispositif de véhicule (20)
    et l'équipement du véhicule (20) comprend
    - un premier dispositif de communication sous la forme d'un dispositif de communication mobile (13) pour l'envoi sans fil du protocole d'événements au dispositif central de traitement de données (50) par l'intermédiaire d'au moins un réseau mobile et
    - un deuxième dispositif de communication sous la forme d'un dispositif de communication DSRC côté véhicule (22) pour l'envoi sans fil d'au moins une information d'état du protocole d'état au dispositif de communication DSRC côté route (63a)
    et est formé,
    - envoyer le protocole d'événement au moyen du dispositif de communication mobile (13) au moins un réseau mobile (40) au dispositif central de traitement de données (50) et
    - envoyer au moins une information d'état du protocole d'état au moyen du dispositif de communication DSRC côté véhicule (22) au dispositif de communication DSRC côté route (63a) du système de péage,
    où
    le dispositif de contrôle côté route (60) est formé,
    - à recevoir au moins une information d'état du protocole d'état provenant de l'équipement de véhicule au moyen du dispositif de communication DSRC côté route (63a),
    - comparer les données de sortie de la au moins une information d'état du protocole d'état avec des données de référence pour déterminer si elles concordent,
    - et, en fonction du résultat de la comparaison, à envoyer au dispositif central de traitement de données (50) un message de problème concernant l'absence ou la présence de correspondance entre les données de sortie et les données de référence, et
    le dispositif central de traitement de données (50) est formé,
    - à recevoir du dispositif de contrôle routier (60) le message de problème concernant l'absence ou l'existence d'une concordance entre les données de sortie concernées et les données de référence, en même temps que les informations d'état concernées ; et
    - envoyer un message de demande de journal d'événements par l'intermédiaire d'au moins un réseau radio mobile (40) au dispositif de véhicule (20) pour demander le journal d'événements,
    le dispositif de véhicule (20) est en outre formé,
    - à recevoir le message de demande de journal d'événements au moyen du dispositif de communication mobile (13) et, en réponse au message de demande de journal d'événements, envoyer le journal d'événements au moyen du dispositif de communication mobile (13) au dispositif central de traitement de données (50) via le réseau mobile (40), et
    le dispositif central de traitement de données (50) est en outre formé,
    - à l'aide de l'ensemble de règles, déterminer si le protocole d'événements contient un message d'événement avec des données d'entrée attendues, dont le traitement par le dispositif de véhicule (20) devrait produire, conformément à l'ensemble de règles, l'information d'état concernée avec les données de sortie concernées, et/ou un message d'événement avec des données d'entrée interdites, dont le traitement par le dispositif de véhicule (20) ne devrait pas produire, conformément à l'ensemble de règles, l'information d'état concernée avec les données de sortie concernées,
    - générer au moins un message d'erreur du système de péage en cas de constatation d'un manque de données d'entrée attendues dans le journal des événements conformément à la réglementation et/ou de constatation de la présence de données d'entrée interdites dans le journal des événements conformément à la réglementation ; et
    - générer un message d'erreur de l'utilisateur en cas de détection d'une présence de données d'entrée attendues conformément à l'ensemble de règles du journal des événements et/ou en cas de détection d'une absence de données d'entrée interdites conformément à l'ensemble de règles du journal des événements.
  6. Système de péage selon la revendication 5, caractérisé en ce que
    les données de sortie représentent un état de préparation au fonctionnement enregistré de l'équipement de véhicule (20), les données de référence représentent un état de non-mise en service de l'équipement du véhicule (20), et
    le dispositif de contrôle côté route (60) est formé,
    dans le cas où l'état de fonctionnement est celui de l'absence de fonctionnement, envoyer un message de problème d'absence de fonctionnement au dispositif central de traitement de données (50).
  7. Système de péage selon la revendication 5, caractérisé en ce que
    le dispositif de contrôle côté rue (60) comprend
    - au moins une caméra (62) pour produire au moins une prise de vue d'une plaque d'immatriculation du véhicule (30) et
    - au moins un dispositif de traitement de données d'image pour obtenir un numéro d'immatriculation à partir de la prise de vue de la plaque d'immatriculation du véhicule (30)
    et est formé,
    - à produire au moyen de la caméra (62) au moins une prise de vue d'une plaque d'immatriculation du véhicule (30) et
    - d'obtenir, au moyen du dispositif de traitement de données d'image, une plaque d'immatriculation enregistrée à partir de la prise de vue de la plaque d'immatriculation du véhicule (30),
    les données de sortie représentent une plaque d'immatriculation enregistrée du véhicule (30), et
    les données de référence représentent la plaque d'immatriculation enregistrée du véhicule (30), et
    le dispositif de contrôle côté route (60) est en outre formé,
    - dans le cas où la plaque d'immatriculation enregistrée et la plaque d'immatriculation enregistrée sont différentes, envoyer un message de problème concernant la différence entre la plaque d'immatriculation enregistrée et la plaque d'immatriculation enregistrée au dispositif central de traitement de données (50).
  8. Système de péage selon la revendication 5, caractérisé en ce que
    le dispositif de contrôle côté rue (60) comprend
    - au moins un dispositif de détection (64) pour détecter une image et/ou un contour du véhicule (30) et
    - au moins un dispositif de classification pour déterminer une catégorie de véhicule du véhicule (30) à partir de l'image saisie et/ou du contour saisi du véhicule (30)
    et est formé,
    - au moins l'information d'état avec les données de sortie sous la forme de la classe de véhicule et/ou d'essieu enregistrée du véhicule (30) est reçue par le dispositif de véhicule (20) au moyen du dispositif DSRC côté route (63),
    - saisir au moins une image et/ou au moins un contour du véhicule (20) au moyen du dispositif de saisie (64) et
    - déterminer, au moyen du dispositif de classification, une catégorie de véhicule détectée du véhicule (30) à partir de l'image détectée et/ou du contour détecté du véhicule (30),
    les données de sortie représentent une catégorie de véhicule enregistrée du véhicule (30),
    les données de référence représentent la catégorie de véhicule détectée du véhicule (30), et
    le dispositif de contrôle côté route (60) est en outre formé,
    - dans le cas où la catégorie de véhicule enregistrée et la catégorie de véhicule détectée sont différentes, envoyer un message de problème concernant la différence entre la catégorie de véhicule enregistrée et la catégorie de véhicule détectée au moyen central de traitement de données (50).
  9. Dispositif embarqué (20) destiné à détecter les positions d'un véhicule (30) par lequel il est transporté,
    le dispositif de véhicule (20) étant conçu
    a) collecter des données de position à partir de positions du véhicule (30)
    b) en fonction de plusieurs variables d'état du dispositif de véhicule (20), traiter les données de position et/ou des données dérivées des données de position dans le but de percevoir un péage se rapportant au véhicule (30), qui doit être perçu pour l'utilisation par le véhicule (30) d'une surface de circulation qui peut être identifiée à l'aide des données de position saisies,
    c) de recevoir ou de générer des données d'entrée les données d'entrée représentant un ou plusieurs des événements suivants :
    i) l'absence de réception de signaux d'un système global de navigation par satellite au niveau d'un dispositif de détermination de position (12) compris par le dispositif de véhicule (20), qui est conçu pour recevoir et traiter des signaux d'un système global de navigation par satellite et pour générer des données de position par leur traitement ;
    ii) l'absence de génération de données de position à partir de signaux d'un système global de navigation par satellite au niveau d'un dispositif de détermination de position (12) compris par l'équipement de véhicule (20), qui est adapté pour recevoir et traiter des signaux d'un système global de navigation par satellite et pour générer des données de position par leur traitement ;
    iii) le fait de ne pas atteindre une qualité minimale de la qualité d'au moins un signal d'un système global de navigation par satellite et/ou d'au moins une position déterminée par un dispositif de détermination de position (12) compris par le dispositif de véhicule (20), qui est conçu pour recevoir et traiter des signaux d'un système global de navigation par satellite et pour générer des données de position par leur traitement ;
    iv) l'omission de la réception de signaux au niveau de l'interface de réception de signaux d'un capteur de déplacement (21) compris dans le dispositif pour véhicule ;
    v) le manque de concordance entre des angles de direction de déplacement déterminés à partir de signaux d'un système global de navigation par satellite et des angles de direction de déplacement déterminés à partir de changements de direction de déplacement détectés par un capteur d'accélération/de taux de lacet (16) du dispositif de véhicule (20) ;
    vi) l'échec du chargement d'un logiciel depuis une mémoire de données (17a) de l'équipement embarqué (20) dans une mémoire de travail (17b) de l'équipement embarqué ;
    vii) le dépassement d'une valeur temporelle, stockée dans une mémoire de données (17a) du dispositif embarqué (20) ou dans une mémoire de travail (17b) du dispositif embarqué, de l'expiration de la validité de logiciels à utiliser par le dispositif embarqué (20) ;
    viii) l'absence d'un signal de temps d'une minuterie (14) de l'équipement du véhicule (20) ;
    ix) le passage en dessous d'une valeur limite prédéterminée d'un état de charge d'un élément de stockage de charge (19a) de l'équipement de véhicule (20) ;
    x) l'absence de réception de signaux de stations de base d'un réseau de téléphonie mobile (40) au niveau d'un dispositif de communication mobile (13) de l'équipement de véhicule (20) ;
    xi) le dépassement d'un certain volume de relevés de péage qui n'ont pas pu être transmis au moyen d'un dispositif de communication mobile (13) de l'équipement du véhicule (20) au dispositif central de traitement de données (50) du système de péage ;
    xii) la réception d'une instruction de blocage d'un service de l'équipement de véhicule via un dispositif de communication mobile (13) de l'équipement de véhicule (20) ;
    xiii) la réception d'une instruction de changement du numéro d'immatriculation du véhicule (30) ;
    xiv) la réception d'une instruction de changement de catégorie du véhicule (30) ;
    xv) l'exécution d'un autotest de l'équipement du véhicule (20) ;
    xvi) la réception d'une activation ou d'un blocage d'un service de l'équipement embarqué (20) ;
    xvii) la réception d'une instruction de modification des faits concernant un péage obligatoire ou une exemption de péage pour le véhicule (30) ;
    d) générer, en fonction des données d'entrée reçues ou générées des données de sortie chacune une valeur de l'une des variables d'état du dispositif (20) du véhicule
    dans lequel une première variable d'état du dispositif (20) du véhicule
    i) un identifiant enregistré de l'équipement du véhicule (20), du véhicule (30) ou d'un utilisateur du véhicule (30),
    ii) une catégorie de véhicule enregistrée du véhicule (30),
    iii) une constatation enregistrée de l'utilisation ou de la non-utilisation par le véhicule d'une surface de circulation soumise à péage (30),
    iv) un état de péage ou d'absence de péage enregistré du véhicule (30), ou
    v) un état de disponibilité enregistré d'un service particulier de l'équipement embarqué (20) et une deuxième variable d'état de l'équipement de véhicule (20) est un état de préparation au fonctionnement enregistré de l'équipement de véhicule (20), et
    e) des informations d'état, qui comprennent chacune des données de sortie générées associées à une valeur de temps d'état, dans un journal d'état mémorisé dans l'équipement de véhicule (20),
    caractérisé en ce que
    le dispositif de véhicule (20) est en outre formé,
    f)inscripter des messages d'événement, qui comprennent chacun des données d'entrée reçues ou générées associées à une valeur temporelle d'événement, dans un journal d'événements enregistré dans l'équipement de véhicule (20),
    g) déterminer, à l'aide d'au moins un ensemble de règles mémorisées dans le dispositif (20) du véhicule, si
    i) pour au moins un message d'événement à contrôler du protocole d'événement, des données de sortie attendues et/ou interdites sont contenues dans le protocole d'état conformément à l'au moins un ensemble de règles dans au moins une information d'état dont la valeur temporelle d'état se situe à l'intérieur d'un intervalle de temps prédéterminé après la valeur temporelle d'événement du message d'événement à contrôler, et/ou
    ii) pour au moins une information d'état à contrôler du protocole d'état, des données d'entrée attendues et/ou interdites sont contenues dans au moins un message d'événement dans le protocole d'événement conformément à l'au moins un ensemble de règles, dont la valeur de temps d'événement se situe à l'intérieur d'un intervalle de temps prédéfini avant la valeur de temps d'état de l'information d'état à contrôler, et
    h) en cas de constatation d'un manque de données de sortie attendues conformément à l'au moins un ensemble de règles et/ou de données d'entrée attendues
    et/ou
    en cas de constatation de la présence de données de sortie et/ou de données d'entrée interdites par l'au moins un ensemble de règles
    générer un message d'erreur.
  10. Dispositif de véhicule selon la revendication 9, caractérisé en ce que
    l'équipement du véhicule (20) comprend
    - au moins un dispositif de communication mobile (13) pour l'envoi et/ou la réception de données vers et/ou depuis le dispositif central de traitement de données (50),
    - au moins un dispositif de détermination de position (12), qui est conçu pour recevoir et traiter des signaux d'un système global de navigation par satellite et pour générer des données de position par leur traitement,
    - au moins un capteur de déplacement (21) pour enregistrer les distances parcourues,
    - au moins un capteur d'accélération/de taux de lacet (16) pour détecter les changements de direction du véhicule (30),
    - au moins une mémoire de données (17a) dans laquelle est stocké un logiciel de l'équipement du véhicule,
    - au moins une mémoire de travail (17b) dans laquelle est chargé un logiciel destiné à être utilisé par le dispositif pour véhicule (20),
    - au moins une mémoire de données (17a, 18b) dans laquelle est stockée au moins une valeur temporelle de l'expiration de la validité du logiciel à utiliser par l'équipement de véhicule,
    - au moins une mémoire de données (17b, 18b) dans laquelle sont mémorisées au moins temporairement des données de position, des données de surfaces de circulation identifiées et/ou des données de relevés de péage,
    - au moins une mémoire de données (17a, 18b) dans laquelle est enregistré un numéro d'immatriculation du véhicule,
    - au moins une mémoire de données (17a, 18b) dans laquelle est enregistrée une catégorie de véhicule du véhicule,
    - au moins un processeur (11) configuré pour générer les données de sortie par le traitement des données d'entrée,
    - au moins une minuterie (14) et
    - au moins un élément de stockage de charge (19a) pour l'alimentation électrique au moins temporaire d'au moins un processeur (11) du dispositif de véhicule (20).
  11. Dispositif de véhicule (20) selon l'une des revendications 9 ou 10 et comportant un dispositif central de traitement de données (50), caractérisé en ce que
    le dispositif de véhicule (20) est conçu pour envoyer le message d'erreur éventuellement généré à un dispositif central de traitement de données (50) du système de péage, disposé à l'extérieur du véhicule (30), au moyen d'un dispositif de communication mobile (13) compris dans le dispositif de véhicule (20).
  12. Dispositif de véhicule (20) selon la revendication 11, caractérisé en ce que
    le dispositif de véhicule (20) est conçu pour exécuter un autotest en fonction d'un événement, en fonction du temps, en fonction du lieu et/ou de manière aléatoire, dans lequel le dispositif de véhicule (20) exécute les étapes g) i) et h) pour au moins un message d'événement à contrôler du protocole d'événement,
    où
    l'événement de l'exécution de l'autotest est enregistré dans le journal des événements en tant que données d'entrée avec la valeur temporelle de l'exécution de l'autotest en tant que message d'événement, et que
    où
    l'au moins un message d'événement à vérifier est défini par le fait qu'il présente une valeur temporelle d'événement retardée par rapport à la valeur temporelle du dernier autotest précédent.
  13. Dispositif de véhicule (20) selon la revendication 11 ou 12, caractérisé en ce que
    l'équipement du véhicule (20) comprend
    - un dispositif de communication mobile (13) pour l'envoi sans fil du protocole d'état par au moins un réseau mobile (40) à au moins un dispositif central de traitement de données (50) du système de péage disposé à l'extérieur du véhicule (30)
    et est formé,
    - à envoyer le protocole d'état au moyen du dispositif de communication mobile (13) au dispositif central de traitement de données (50),
    - recevoir du dispositif central de traitement de données (50), au moyen du dispositif de communication mobile (13), une instruction pour l'exécution de l'étape g) ii) concernant au moins une information d'état à vérifier, définie par le dispositif central de traitement de données (50),
    - à exécuter l'étape g) ii) en ce qui concerne la au moins une information d'état à vérifier définie par le dispositif central de traitement de données (50), et
    lors de la constatation d'un manque de données d'entrée attendues selon l'au moins un ensemble de règles et/ou lors de la constatation d'une présence de données d'entrée interdites selon l'au moins un ensemble de règles, à générer au moins un message d'erreur et à envoyer ce message d'erreur au moyen du dispositif de communication mobile (13) au dispositif central de traitement de données (50).
  14. Procédé de détection d'erreurs dans un dispositif embarqué (20) d'un système de péage transporté par un véhicule (30), comprenant les étapes suivantes :
    a) l'acquisition de données de position de positions du véhicule (30) par le dispositif de véhicule (20),
    b) le traitement des données de position et/ou de données dérivées des données de position par le dispositif de véhicule (20) en fonction de plusieurs variables d'état du dispositif de véhicule (20) dans le but de percevoir un péage lié au véhicule (30) qui doit être perçu pour l'utilisation par le véhicule (30) d'une zone de circulation qui est identifiable à l'aide des données de position détectées,
    c) réception ou production de données d'entrée par l'équipement embarqué (20)
    les données d'entrée représentant un ou plusieurs des événements suivants :
    i) l'absence de réception de signaux d'un système global de navigation par satellite au niveau d'un dispositif de détermination de position (12) compris par le dispositif de véhicule (20), qui est conçu pour recevoir et traiter des signaux d'un système global de navigation par satellite et pour générer des données de position par leur traitement ;
    ii) l'absence de génération de données de position à partir de signaux d'un système global de navigation par satellite au niveau d'un dispositif de détermination de position (12) compris par l'équipement de véhicule (20), qui est adapté pour recevoir et traiter des signaux d'un système global de navigation par satellite et pour générer des données de position par leur traitement ;
    iii) le fait de ne pas atteindre une qualité minimale de la qualité d'au moins un signal d'un système global de navigation par satellite et/ou d'au moins une position déterminée par un dispositif de détermination de position (12) compris par le dispositif de véhicule (20), qui est conçu pour recevoir et traiter des signaux d'un système global de navigation par satellite et pour générer des données de position par leur traitement
    iv) l'omission de la réception de signaux au niveau de l'interface de réception de signaux d'un capteur de déplacement (21) compris dans le dispositif pour véhicule ;
    v) le manque de concordance entre des angles de direction de déplacement déterminés à partir de signaux d'un système global de navigation par satellite et des angles de direction de déplacement déterminés à partir de changements de direction de déplacement détectés par un capteur d'accélération/de taux de lacet (16) de l'équipement de véhicule (20) ;
    vi) l'échec du chargement d'un logiciel depuis une mémoire de données (17a) du dispositif embarqué (20) dans une mémoire de travail (17b) du dispositif embarqué ;
    vii) le dépassement d'une valeur temporelle, stockée dans une mémoire de données (17a) du dispositif embarqué (20) ou dans une mémoire de travail (17b) du dispositif embarqué, de l'expiration de la validité de logiciels à utiliser par le dispositif embarqué (20) ;
    viii) l'absence d'un signal de temps d'une minuterie (14) de l'équipement du véhicule (20) ;
    ix) le passage en dessous d'une valeur limite prédéterminée d'un état de charge d'un élément de stockage de charge (19a) de l'équipement de véhicule (20) ;
    x) l'absence de réception de signaux de stations de base d'un réseau de téléphonie mobile (40) au niveau d'un dispositif de communication mobile (13) de l'équipement de véhicule (20) ;
    xi) le dépassement d'un certain volume de relevés de péage qui n'ont pas pu être transmis au moyen d'un dispositif de communication mobile (13) de l'équipement du véhicule (20) au dispositif central de traitement de données (50) du système de péage ;
    xii) la réception d'une instruction de blocage d'un service de l'équipement de véhicule via un dispositif de communication mobile (13) de l'équipement de véhicule (20) ;
    xiii) la réception d'une instruction de changement du numéro d'immatriculation du véhicule (30) ;
    xiv) la réception d'une instruction de changement de catégorie du véhicule (30) ;
    xv) l'exécution d'un autotest de l'équipement du véhicule (20) ;
    xvi) la réception d'une activation ou d'un blocage d'un service de l'équipement embarqué (20) ;
    xvii) la réception d'une instruction de modification des faits concernant un péage obligatoire ou une exemption de péage pour le véhicule (30) ;
    d) production, par le dispositif embarqué (20), de données de sortie représentant chacune une valeur de l'une des variables d'état du dispositif embarqué (20), en fonction des données d'entrée reçues ou produites dans lequel une première variable d'état du dispositif (20) du véhicule
    vi) un identifiant enregistré de l'équipement du véhicule (20), du véhicule (30) ou d'un utilisateur du véhicule (30),
    vii) une catégorie de véhicule enregistrée du véhicule (30),
    viii) une constatation enregistrée de l'utilisation ou de la non-utilisation par le véhicule d'une surface de circulation soumise à péage (30),
    ix) un état de péage ou d'absence de péage enregistré du véhicule (30), ou
    x) un état de disponibilité enregistré d'un service particulier de l'équipement embarqué (20) et une deuxième variable d'état de l'équipement de véhicule (20) est un état de préparation au fonctionnement enregistré de l'équipement de véhicule (20), et
    e) l'enregistrement, par le dispositif embarqué (20), d'informations d'état comprenant chacune des données de sortie générées associées à une valeur de temps d'état, dans un journal d'état stocké dans le dispositif embarqué (20)
    caractérisé par les étapes supplémentaires de
    f) l'enregistrement, par le dispositif embarqué (20), de messages d'événements comprenant chacun des données d'entrée reçues ou générées associées à une valeur temporelle d'événement, dans un journal d'événements stocké dans le dispositif embarqué (20),
    g) détermination par le dispositif embarqué (20) et/ou par un dispositif central de traitement de données (50) du système de péage, disposé à l'extérieur du véhicule (30), à l'aide d'au moins un ensemble de règles mémorisées dans le dispositif embarqué (20) et/ou dans le dispositif central de traitement de données (50), si
    i) pour au moins un message d'événement à contrôler du protocole d'événement, des données de sortie attendues et/ou interdites sont contenues dans le protocole d'état conformément à l'ensemble de règles dans au moins une information d'état dont la valeur temporelle d'état se situe à l'intérieur d'un intervalle de temps prédéfini après la valeur temporelle d'événement du message d'événement à contrôler et/ou
    ii) pour au moins une information d'état à contrôler du protocole d'état, des données d'entrée attendues et/ou interdites sont contenues dans le protocole d'événement conformément à l'ensemble de règles dans au moins un message d'événement dont la valeur temporelle d'événement se situe à l'intérieur d'un intervalle de temps prédéfini avant la valeur temporelle d'état de l'information d'état à contrôler et
    h) génération d'un message d'erreur
    en cas de constatation d'un manque de données de sortie attendues conformément à l'ensemble de règles et/ou de données d'entrée attendues et/ou
    en cas de constatation d'une présence de données de sortie interdites conformément à l'au moins un ensemble de règles et/ou de données d'entrée interdites
    par le dispositif embarqué (20) et/ou le dispositif central de traitement de données (50).
EP15003424.7A 2015-11-27 2015-11-27 Reconnaissance d'erreurs dans une unité embarquée à bord d'une véhicule d'un système de péage Active EP3174015B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP15003424.7A EP3174015B1 (fr) 2015-11-27 2015-11-27 Reconnaissance d'erreurs dans une unité embarquée à bord d'une véhicule d'un système de péage

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP15003424.7A EP3174015B1 (fr) 2015-11-27 2015-11-27 Reconnaissance d'erreurs dans une unité embarquée à bord d'une véhicule d'un système de péage

Publications (2)

Publication Number Publication Date
EP3174015A1 EP3174015A1 (fr) 2017-05-31
EP3174015B1 true EP3174015B1 (fr) 2025-03-12

Family

ID=54782393

Family Applications (1)

Application Number Title Priority Date Filing Date
EP15003424.7A Active EP3174015B1 (fr) 2015-11-27 2015-11-27 Reconnaissance d'erreurs dans une unité embarquée à bord d'une véhicule d'un système de péage

Country Status (1)

Country Link
EP (1) EP3174015B1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102017222320A1 (de) * 2017-12-08 2019-06-13 Continental Automotive Gmbh Tachografenanordnung und Verfahren zum Betreiben einer Tachografenanordnung

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10104499A1 (de) * 2001-01-31 2002-08-14 Daimler Chrysler Ag Strassengebührenerfassungssystem
EP1708144B1 (fr) * 2005-03-09 2010-12-15 MPS Solutions GmbH Dispositif et procédé destinés à l'échange de données de péage dans des systèmes d'identification par radiofréquence
EP1870302A1 (fr) * 2006-06-21 2007-12-26 AGES International GmbH & Co. KG Personnalisation à distance d'une unité embarquée

Also Published As

Publication number Publication date
EP3174015A1 (fr) 2017-05-31

Similar Documents

Publication Publication Date Title
EP1358635B1 (fr) Méthode de collecte de droits de peage
AT507031B1 (de) Verfahren und vorrichtung zum einheben von maut
WO2015136029A2 (fr) Système télématique, unité télématique et procédé pour commander à distance ou influer sur des fonctions d'un véhicule et pour acquérir des données du véhicule
DE102015226147B4 (de) Verfahren, Prozessorvorrichtung, Kraftfahrzeug mit einer solchen Prozessorvorrichtung und Telematiksystem für die automatische Konfiguration telematischer Datenübermittlungen des Kraftfahrzeugs
DE102022125933A1 (de) System und Verfahren zur Mauterhebung für ein Kraftfahrzeug
EP2994890B1 (fr) Procédé et dispositif de fourniture de données pour la perception de péage et système de péage
DE102018006281A1 (de) Verfahren zum Betrieb eines Assistenzsystems eines Fahrzeuges
DE102018203392A1 (de) Fahrerassistenzverfahren zum Planen einer Routengestaltung eines Elektrokraftfahrzeuges mit einem oder mehreren Ladestopps an Ladestationen und entsprechende Fahrerassistenzvorrichtung
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
WO2021013508A1 (fr) Procédé de fonctionnement d'un système de réservation d'une station de charge pour un véhicule électrique
EP3355249B1 (fr) Procédé d'attribution d'un véhicule à un lieu de stationnement, installation de traitement de données et véhicule
EP3279870A1 (fr) Dispositif de traitement de donnees, systeme et procede de controle de realisation de la fonction conforme d'un dispositif de determination de position
EP3174015B1 (fr) Reconnaissance d'erreurs dans une unité embarquée à bord d'une véhicule d'un système de péage
EP2195788B1 (fr) Procédé et dispositif de détermination des données relatives aux performances d'un ou de plusieurs véhicules
EP3242206A1 (fr) Procede de mise a jour de la configuration d'un dispositif de vehicule, dispositif de vehicule, dispositif de traitement de donnees central et systeme de peage
EP3211605B1 (fr) Dispositif de véhicule, système, dispositif coté route et procédé d'exécution d'au moins une transaction
EP4163886B1 (fr) Système et procédé de perception de péage pour un véhicule automobile
EP2757513B1 (fr) Procédé de calcul d'utilisations d'espaces
DE102014116756A1 (de) Vorrichtung zum Erheben einer Fahrzeugmaut
EP3242205A1 (fr) Procede de mise a jour de la configuration d'un dispositif de vehicule, dispositif de vehicule, dispositif de traitement de donnees central et systeme de peage
EP2772886B2 (fr) Système de tableau de bord électronique de véhicule et procédé de contrôle correspondant
EP2184716B1 (fr) Procédé de calcul automatisé d'un système d'inventaire de taxes ou de péage
DE202016001371U1 (de) Fahrzeugeinrichtung, System und straßenseitige Einrichtung zur Durchführung wenigstens einer Transaktion
EP3188133B1 (fr) Dispositif de traitement de donnees de position et systeme de peage et procede de fonctionnement d'un dispositif de traitement de donnees de position et d'un systeme de peage
WO2002101661A2 (fr) Systeme de peage double

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

AX Request for extension of the european patent

Extension state: BA ME

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20171130

RBV Designated contracting states (corrected)

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

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

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20190731

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

Effective date: 20231207

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

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

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTG Intention to grant announced

Effective date: 20241203

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

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

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

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

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 502015017039

Country of ref document: DE

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

Free format text: LANGUAGE OF EP DOCUMENT: GERMAN

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: RS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250612

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250312

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250312

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG9D

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250612

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250312

REG Reference to a national code

Ref country code: NL

Ref legal event code: MP

Effective date: 20250312

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250312

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250613

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250312

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250312

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250312

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250312

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250714

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250312

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250312

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250312

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250312

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250312

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250312

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250712

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 502015017039

Country of ref document: DE

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20251118

Year of fee payment: 11

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250312

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

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

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

REG Reference to a national code

Ref country code: CH

Ref legal event code: L10

Free format text: ST27 STATUS EVENT CODE: U-0-0-L10-L00 (AS PROVIDED BY THE NATIONAL OFFICE)

Effective date: 20260121

26N No opposition filed

Effective date: 20251215