Fault detection in a vehicle-carried toll system device

Description

[0001] 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.

[0002] 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 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.

[0003] In this case, 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 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 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.

[0004] 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.

[0005] 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. For example, input data can be supplied to the vehicle device via an interface or generated by the vehicle device itself.

[0006] When the vehicle equipment is put into operation, the input data received generates output data that enables the vehicle equipment to be operated as intended. Even during operation, the vehicle equipment can receive input data, the processing of which then results in a change to the output data, with the result that a changed value of the affected state variable is saved in the vehicle equipment. Furthermore, the vehicle equipment itself can generate input data during operation, the processing of which then also results in a change to the output data, with the result that a changed value of the affected state variable is saved in the vehicle equipment.

[0007] For example, 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. In the interest of both the toll operator and the user, it is necessary to determine in such a case that an error has occurred and, if applicable, whose area of ​​responsibility it falls under.An error may be due to the toll operator's vehicle equipment or to the user's lack of cooperation.

[0008] German Patent Application DE 101 04 499 A1 discloses a vehicle device that 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 log of the vehicle device known as a logbook.

[0009] 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 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.

[0010] EP 1708143 A2 discloses a method, a device, and a system for processing position-related data. The position-related data is acquired on a plurality of mobile on-board units and transmitted via a mobile network as an interface to a central and stationary back office for further processing. The back office includes a position calculation instance designed to calculate normalized position data from the read-in position-related data. The normalized position data is then forwarded to other service instances for further processing.

[0011] 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.

[0012] This problem is solved by the independent claims. Advantageous further developments are the subject of the dependent claims. Features of further developments of independently claimed products and processes are considered interchangeable and transferable across all inventions, to the extent technically possible.In summary, the invention provides for the detection of faulty state variables of a vehicle device used for toll collection, input data from which output data in the form of a value of the state variable is generated by the vehicle device, to be stored in an event log and the output data to be stored in a status log, in order to then search for expected and / or prohibited output data in the status log based on the input data to be checked using a set of rules, or to search for expected and / or prohibited input data in the event log based on the output data to be checked using a set of rules, wherein an error message is output if one or the other search for expected data is unsuccessful and / or one or the other search for prohibited data is successful.

[0013] According to one aspect of the invention, a toll system is provided which comprises at least one vehicle device carried by a vehicle, which is designed to (a) record position data of positions of the vehicle, (b) 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 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, (c) receive or generate input data and (d) generate output data as a function of the received or generated input data, which each represent a value of one of the state variables of the vehicle device, and is characterized in that the vehicle device is designed to (e) receive status information,which each comprise generated output data linked to a status time value, in at least one status log stored in the vehicle device, (f) event messages which each comprise received or generated input data linked to an event time value, in at least one event log stored in the vehicle device, and the toll system is 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 log to be checked, expected and / or prohibited output data are contained in the status log according to at least one set of rules stored in the toll system in at least one item of status information, the status time value of which lies within at least one predetermined time range around 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, expected and / or prohibited input data are contained in at least one event message in the event protocol according to at least one set of rules stored in the toll system, the event time value of which lies within at least a predetermined time range around the status time value of the status information to be checked, and (h) to generate an error message upon detection of a lack of output data and / or input data 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 rules.

[0014] 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".

[0015] 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".

[0016] Expected input or output data can be 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 the 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.

[0017] 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.

[0018] The formulation of a specified time range (short: time range) around the respective time value of the event message or status information to be checked does not necessarily mean that the respective time value of the event message or status information to be checked must be contained in the specified time range (this condition only applies to the time value of the status information(s) or the event message(s) that are searched for in the context of the check).The respective time value of the event message or status information to be checked can also lie outside the specified time range, in which case the limits of the time range are then defined in the definition of the specified time range with two relative time intervals, each with a negative sign, if the specified time range lies entirely before the respective time value of the event message or status information to be checked, and with two relative time intervals, each with a positive sign, if the specified time range lies entirely after the respective time value of the event message or status information to be checked.In the event that the respective time value of the event message or status information to be checked forms a boundary so that a relative distance is equal to zero, it is sufficient to specify a single time distance to the respective time value of the event message or status information to be checked to define the time range.

[0019] In particular, the 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.

[0020] Preferably, for example, 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.

[0021] Conversely, 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. Likewise, 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.

[0022] 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 time range in question.

[0023] In particular, 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 event message 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) to generate an error message upon detection of a deficiency in the output data and / or input data 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 rules.

[0024] This makes it possible to check, within the scope of a backward search, whether the value of a specific state variable, represented by output data, was correctly generated from expected input data, was incorrectly generated from unexpected input data or no input data, or should not have been generated at all due to forbidden input data. Likewise, it is possible to check, within the scope of a forward search, whether input data was correctly processed to produce expected output data representing the value of a specific state variable.

[0025] The inventive set of rules provides a monitoring tool that verifies the intended design of the vehicle equipment. Deviations from the intended design that are due to unforeseen influences can thus be identified as errors in the toll system—in particular, the vehicle equipment. In this case, it is proven that the user is not at fault if combinations of input and output data are identified that contradict each other, for example, because they are not in context with each other.

[0026] Preferably, 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.

[0027] Such a database provides combinations of compatible input and output data.

[0028] Preferably, in the same or a further database of the rule set, 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.

[0029] Such a database provides combinations of incompatible input and output data.

[0030] Preferably, 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 depend on a status time value of a different piece of status information than 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 a different piece of status information than the status information to be checked.

[0031] The toll system can be designed to select from the status protocol a first item of status information and a second item of status information entered directly thereafter in the status protocol with regard to one and the same status variable, to check first output data of the first item of status information and second output data of the second item of status information for a change in the value of the state variable, to determine whether the event protocol contains expected input data of at least one event message 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 upon determination,that no input data expected according to the rules is contained in the event log, to generate the error message.,

[0032] 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.

[0033] 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 write operation, 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.Nevertheless, 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 with first status information relating to a respective state variable, is first sent by the vehicle device by means of 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 with second status information relating to a respective state variable, is sent by the vehicle device by means of 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.Alternatively, the vehicle device may be configured to simultaneously store multiple status logs generated at different times with respect to the same state variable.

[0034] In both cases, the toll system can be designed to select a first item of status information from a first status protocol written at a first time and a second item of status information from a second status protocol written at a second 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 protocol contains expected input data of at least one event message according to at least one set of rules stored in the toll system,whose processing 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 upon detection that no input data expected according to the rule set is contained in the event log, to generate the error message.

[0035] 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 the status log contains output data of at least one item of status information that is to be expected 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 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 to generate the error message upon determination that no output data that is to be expected according to the set of rules is contained in the event log.

[0036] 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.

[0037] 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.

[0038] 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 upon determination that no output data to be expected according to the set of rules is contained in the event log.

[0039] 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.

[0040] 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.

[0041] In particular, the toll system is designed to collect a vehicle-related toll fee 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.

[0042] Preferably, 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.

[0043] In particular, the central data processing device is located away from the vehicle.

[0044] 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.

[0045] Alternatively or optionally, the vehicle device can send data derived from the position data to the central data processing unit—for example, an identifier of a traffic area identified by the vehicle device based on the position data, or 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 based on the recorded position data. If an identifier of an identified traffic area is transmitted, the central data processing unit determines a toll fee from the identifier of the identified traffic area.The toll fee received by the central data processing facility or alternatively / optionally determined is assigned by the central data processing facility to a user account, with respect to which the central data processing facility sends a request to debit the toll fee and credit it to an account of the toll operator to an account management data processing facility.

[0046] Preferably, the vehicle device sends an identifier of the vehicle device, the vehicle, or the user along 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. For this purpose, the identifier of the vehicle device, the vehicle, or the user is stored in the central data processing device in conjunction with the user's account data.Based on the identification of the vehicle equipment, the vehicle or the user received from the vehicle equipment, which was sent by the vehicle equipment linked to the position data, the identification of the identified traffic area and / or the toll fee, the central data processing device can assign the position data, the identification of the identified traffic area and / or the toll fee to the user account.

[0047] The identifier of the vehicle device, the vehicle, or the user is a possible state variable of the vehicle device. Within the meaning of the invention, in this case, 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.

[0048] Preferably, 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.

[0049] For this purpose, 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. Thus, 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.

[0050] Preferably, 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.

[0051] In this case, 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.

[0052] In this case, 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. Within the scope 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 vehicle 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.

[0053] In this case, 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.

[0054] 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"). Another example of a vehicle identifier is the vehicle identification number (VIN) 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.

[0055] 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-paying or toll-exempt status of the vehicle, a registered availability status of a specific service of the vehicle equipment.

[0056] Examples of vehicle classes include 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, depends in this case on the vehicle class or, if applicable, on several different types of vehicle classes. In this respect, the vehicle class is also a state variable of the vehicle equipment according to the invention, because thePosition data processing process, regardless of whether the vehicle equipment determines the amount of the toll fee (first case) or the central data processing device determines the amount of the toll fee from the position data transmitted by the vehicle equipment 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 equipment 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.

[0057] 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.

[0058] 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.

[0059] For example, the registered availability status of a specific service of the vehicle device may determine whether and, if so, when the vehicle device 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. For example, if the "Anonymous Position Data Provision" service is available, the vehicle device 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.After determining the toll fee from the position data, the toll operator's central data processing facility receives the identification of the vehicle device, the vehicle, or the user from the anonymization service's central data processing facility. 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.

[0060] 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. In this case, 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.

[0061] Preferably, the toll system according to the invention 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 travelled, 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 theExpiration of the validity of software to be used by the vehicle device is stored, at least one data memory in which position data, data from identified traffic areas and / or data from toll collections are stored at least temporarily, 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 generate the output data by processing the input data, at least one timer and at least one charge storage element for at least temporarily supplying power to at least one processor of the vehicle device, wherein the input data represent one or more of the following events: (i) the failure to receive signals from a global navigation satellite system at the position-determining device; (ii) the failure to generatePosition data from signals of a global navigation satellite system by the position-determining device; (iii) the quality of at least one signal of a global navigation satellite system and / or at least one position determined by the position-determining device falls below a minimum level; (iv) the failure to receive signals at the interface for receiving signals from a displacement sensor; (v) the lack of agreement between the heading angles determined from signals of a global navigation satellite system and the heading angles determined from changes in heading detected by the acceleration sensor / yaw rate sensor; (vi) the loading of software for processing position data and / or data derived from the position data from the data memory into the main memory fails; (vii) the time value of the expiry of the validity of the software is exceeded; (viii) the absence of a time signal from thetimer; (ix) the charge level of the charge storage element falls below a predetermined limit, (x) the failure of the mobile communication device to receive signals from base stations of a mobile 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 communication device; (xii) the receipt of an instruction to block a service of the vehicle device via the mobile communication device; (xiii) the receipt of an instruction to change the vehicle registration number of the vehicle; (xiv) the receipt of an instruction to change the vehicle class of the vehicle; (xv) the performance of a self-test of the vehicle device; (xvi) the receipt of an activation or deactivation of a service of the vehicle device; (xvii) the receipt of an instruction to change the facts regarding aToll obligation or toll exemption of the vehicle.

[0062] Each of these events, individually or in conjunction with other 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.

[0063] Thus, 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.

[0064] The same applies to events (vi) to (xi).

[0065] However, further differentiations regarding the operational readiness status of the vehicle equipment are also possible. For example, if the positioning device fails to generate position data from signals of a global navigation satellite system for the first time or if the positioning device fails to generate position data from signals of a global navigation satellite system for a short period of time, for example, 10 seconds, the operational readiness value can change from "operational" to "limited operational." 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" to "not operational."If position data from signals of a Global Navigation Satellite System are again provided by the positioning device before the longer period of 1 minute has elapsed, the operational readiness value can change from "limited operational" back to "operational".

[0066] The consequences of the occurrence of events (xii) to (xvii) are self-explanatory in view of the above explanations. Regarding 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. Thus, 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.

[0067] With regard to exceeding 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 first communication device, 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.

[0068] A single data storage device is sufficient to store said data; however, there are preferably 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.

[0069] Preferably, in one embodiment of the decentralized error checking, 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.

[0070] Preferably, 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.

[0071] This has created a toll system in which a vehicle equipment, for example every time the vehicle equipment is switched on; every time the power supply to the vehicle equipment is reconnected; every time the vehicle equipment has completed its hour of operation; every time a connected road network of toll sections is used again; every time a distance of 100 kilometers is covered again and / or at a random time during the operation of the vehicle equipment for a selection of events or all event messages newly registered in the event log since the last self-test was carried out to check whether the expected status information is present in the status log.

[0072] Preferably, the vehicle device of such a toll system according to the invention with decentralized error checking has a mobile radio communication device for wirelessly sending the status protocol 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 protocol 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 for carrying out step g) ii) with respect to at least one item of status information to be checked, defined by the central data processing device,to carry out step g) ii) with respect to the at least one item of status information defined by the central data processing device to be checked, and h) upon detection of a lack of input data 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, to generate at least one error message and to send this error message to the central data processing device by means of the mobile radio communication device.

[0073] In particular, 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.

[0074] Preferably, in one embodiment of the central error check, 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 designedto receive the event log sent by the vehicle device and the at least one item of status information sent by the vehicle device, and to carry out at least steps g) and h) based on at least one set of rules stored in the central data processing system. If the vehicle device—because it is configured accordingly—sends only a single item of status information at a time, this status information is the status information to be checked according to the invention. If the vehicle device—because it is configured accordingly—sends an extract of the status log that comprises multiple items of status information, or the entire status log that comprises multiple items of status information, the central data processing system is configured to determine from the multiple items of status information in the status log or the extract thereof the status information that is the status information to be checked according to the invention.

[0075] 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 log to the central data processing device via at least one mobile radio network using the mobile radio communication device, and to send at least one item of status information of the status log to the roadside DSRC communication device of the toll system using the vehicle-side DSRC communication device.

[0076] 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 based on a request from the central data processing device for status information received from the DSRC communication device since the last transmission.

[0077] If the vehicle device sends an extract of the status protocol that includes a plurality of status information items, or the entire status protocol that includes a plurality of status information items, the roadside DSRC communication device or a roadside control device that includes the roadside DSRC communication device can be designed to determine from the plurality of status information items of the status protocol or the extract thereof the status information that is the status information to be checked according to the invention, and to send the determined status information to be checked to the central data processing device.Alternatively, the roadside DSRC communication device or a roadside control device comprising the roadside DSRC communication device may be configured to send the complete received extract of the status protocol or the complete status protocol to the central data processing device.

[0078] The toll system according to the invention provides a particular advantage in the event of a control, in which a roadside control device compares reference data with output data from status information received from the vehicle device for consistency. Depending on the outcome of this comparison, a control-related protocol check is then initiated. In this case, 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 decentralized check to determine whether unexpected output data is due to an error in the vehicle device (i.e., the toll system) or a user error.

[0079] For example, 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 log 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 log to the central data processing device by means of the mobile radio communication device of at least one mobile radio network and to send at least one item of status information of the status log 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 log from the vehicle device by means of the roadside DSRC communication device, to compare output data of the at least one item of status information of the status log with reference data for consistency, and depending on the result of the comparison, to send a problem message about the lack of or existing consistency of the output data with the reference data to the central data processing device, and the central data processing device is designed,to receive the problem message about the lack of or existing agreement between the relevant output data and the reference data together with the relevant status information from the roadside control device and to send an event log request message via at least one mobile radio network to the vehicle device to request the event log, the vehicle device is further configured to receive the event log request message by means of the mobile radio communication device and, in response to the event log request message, to send the event log by means of the mobile radio communication device via the mobile radio network to the central data processing device, and the central data processing device is further configured to determine, based on the rule set, whether the event log contains an event message with expected input data,whose processing by the vehicle device according to the rules should generate the relevant status information with the relevant output data, and / or an event message with prohibited input data is contained, whose processing by the vehicle device according to the rules should not generate the relevant status information with the relevant output data, to generate at least one toll system error message upon detection of a lack of input data expected in the event log according to the rules and / or the presence of input data prohibited in the event log according to the rules, and to generate a user error message upon detection of the presence of input data expected in the event log according to the rules and / or the presence of input data prohibited in the event log according to the rules.

[0080] If the vehicle device - because it is designed accordingly - sends the status protocol comprising a plurality of status information items or an extract of the status protocol comprising a plurality of status information items, 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.

[0081] In the case of a decentralized check, the toll system according to the invention for control-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 log 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 log 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 log from the vehicle device by means of the roadside DSRC communication device, to compare output data of the at least one item of status information of the status log with reference data for consistency, and depending on the result of the comparison, to send a problem message about the lack of or existing consistency of the output data with the reference data to the central data processing device, and the central data processing device is designed,to receive the problem message about the lack of or existing agreement between the relevant output data and the reference data together with the relevant status information from the roadside control device and to send a test instruction message via at least one mobile radio network to the vehicle device for testing the event log with regard to the relevant status information, the vehicle device is further configured to receive the test instruction message by means of the mobile radio communication device, in response to the test instruction message, to determine based on the set of rules whether the event log contains an event message with expected input data, the processing of which by the vehicle device should generate the relevant status information with the relevant output data according to the set of rules, and / or an event message with prohibited input data,whose processing by the vehicle device according to the rules should not generate the relevant status information with the relevant output data, to send at least one toll system error message to the central data processing device by means of the mobile radio communication device upon detection of a lack of input data expected in the event log according to the rules and / or upon detection of the presence of input data prohibited in the event log according to the rules, and to send a user error message to the central data processing device by means of the mobile radio communication device upon detection of the presence of input data expected in the event log according to the rules and / or upon detection of a lack of input data prohibited in the event log according to the rules.

[0082] If the vehicle device - because it is designed accordingly - sends the status protocol comprising a plurality of status information items or an extract of the status protocol comprising a plurality of status information items, 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.

[0083] With the control-related protocol check according to the invention, 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).

[0084] The following embodiments of such control-related protocol checks clarify the significance of the invention for control practice in toll systems: Thus, in a toll system with control-related decentralized or centralized protocol checks, the output data can represent a registered operational readiness state of the vehicle device, the reference data can represent a state of insufficient operational readiness of the vehicle device, and 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.

[0085] In particular, 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.

[0086] 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 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 storage into the main memory; (vii) the expiration time of the validity of the;

[0087] Processing instructions; (viii) the absence of a time signal from the timer; (ix) the charge state 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.

[0088] Furthermore, in a toll system with control-related decentralized or centralized protocol checking, the output data can represent an identifier of a toll road section last identified as driven by the vehicle device, the reference data can represent an identifier of a toll road section to be controlled corresponding to the position of the control device, at which the control device is located, and the roadside control device can be designed, in the event that the identifier of the toll road section last identified as driven by the vehicle device does not match the identifier of the road section to be controlled,Send a problem message to the central data processing device regarding the mismatch between the identifier of the toll road section last identified by the vehicle device as having been traveled and the identifier of the road section to be monitored. In particular, the roadside DSRC communication device can be configured to receive the status log or an extract of the status log containing multiple status information items, with the roadside monitoring device being configured in this case 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 last identified toll road section. 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.

[0089] Alternatively or optionally, in a toll system with control-related decentralized or centralized protocol checking, 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, and the roadside control device can be designed 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 100 meters, for example).In particular, 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 position last registered by the vehicle device from the status protocol.

[0090] In addition, a toll system with control-related decentralized or centralized protocol checking can be characterized in that the roadside control device comprises and is designed to comprise at least one image recording device (for example a camera) for generating at least one image recording of a license plate of the vehicle and at least one image processing device for obtaining a license plate from the image recording of the license plate of the vehicle.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 the recorded license plate to the central data processing device in the event that the registered license plate and the recorded license plate are different.In particular, 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.

[0091] Furthermore, a toll system with control-related 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 configured to send a problem message about the difference between the registered and detected vehicle classes to the central data processing device in the event that the registered vehicle class and the detected vehicle class are different.

[0092] In particular, 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,

[0093] 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, because the output data is sufficient for the control device to compare with the reference data. In the case of central testing by the central data processing device, the central data processing device is configured to request the status time value of the status information of the output data from the vehicle device in addition to the event log, and the vehicle device is configured 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.

[0094] It is also possible for the vehicle device to be configured to send only an extract of the event log with multiple event messages. In this sense, the said extract is also to be understood as an event log.

[0095] This allows the data volume when sending the event log to be limited or at least reduced.

[0096] It is possible for the vehicle device to be 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 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.

[0097] In cases where the vehicle device has a vehicle-side DSRC communication device for wirelessly sending 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 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 depending on 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 has at least one first data memory,The second device part comprises the vehicle-side DSRC communication device with a second processor configured to control DSRC communication between the vehicle-side DSRC communication device and the roadside DSRC communication device, and at least one second data memory. The vehicle device is configured to store the event log in the first data memory and the status log in the second data memory. With this embodiment, the status log or at least one item of status information from 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.

[0098] According to a second aspect of the invention, a vehicle device for detecting positions of a vehicle by which it is carried is provided, wherein the vehicle device is designed (a) to detect position data of positions of the vehicle (b) 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 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 detected position data, (c) to receive or generate input data and (d) depending on the received or generated input data, to generate output data, each representing a value of one of the state variables of the vehicle device, characterized in that the vehicle device is further designed (e) to receive status information,which each comprise generated output data linked to a status time value, in a status log stored in the vehicle device, (f) event messages which each comprise received or generated input data linked to an event time value, in an event log stored in the vehicle device, (g) to determine on the basis of at least one set of rules stored in the vehicle device whether i) for at least one event message of the event log to be checked, the status log contains expected and / or prohibited output data in accordance with the at least one set of rules in at least one item of status information whose status time value lies within a predetermined time range around 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, expected and / or prohibited input data according to the at least one set of rules are contained in at least one event message in the event protocol, the event time value of which lies within a predetermined time range around the status time value of the status information to be checked, and (h) to generate an error message upon detection of a lack of output data and / or input data 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 rules.

[0099] In particular, the vehicle device according to the invention 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, 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) generate an error message upon detection of a deficiency in expected output data and / or in expected input data according to the at least one set of rules. Preferably, the vehicle device according to the invention comprises 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, and is divided into a first device part and at least one second device part, which is detected by the first device part and is communicatively coupled to the first device part. The first device part comprises 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 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 comprises the vehicle-side DSRC communication device with a second processor, which is designed to control the DSRC communication of the vehicle-side DSRC communication device with the roadside DSRC communication, and at least one second data memory, and wherein the vehicle device is designed,to store the event log in the first data memory and to store the status log in the second data memory. With this embodiment, the status log or at least one item of status information from the status log can be quickly provided by the vehicle device according to the invention for transmission from the vehicle-side DSRC communication device to the roadside DSRC communication device as the vehicle passes a roadside DSRC communication device.

[0100] According to a third aspect of the invention, a method is provided for detecting errors in a vehicle device of a toll system carried by a vehicle, comprising the following steps: (a) acquisition of 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 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 traffic area by the vehicle that is identifiable on the basis of the acquired position data, (c) receipt or generation of input data by the vehicle device, and (d) generation of output data, each representing a value of one of the state variables of the vehicle device, depending on the input data received or generated by the vehicle device,characterized by the further steps of (e) entering status information, each of which comprises 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 of which comprises received or generated input data linked to an event time value, in an event log stored in the vehicle device by the vehicle device, (g) determining 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) output data to be expected in the status log according to the set of rules for at least one event message to be checked in the event log are contained in at least one item of status information,whose status time value lies within a predetermined time range around 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, input data to be expected in accordance with the rule set is contained in at least one event message in the event protocol, the event time value of which lies within a predetermined time range around the status time value of the status information to be checked, and (h) generation of an error message upon detection of a lack of output data and / or input data to be expected in accordance with the rule set and / or upon detection of the presence of output data and / or input data prohibited in accordance with at least one rule set by the vehicle device and / or the central data processing device.

[0101] In particular, 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, the status protocol contains expected and / or prohibited output data in accordance with the set of rules in at least one item of status information whose status time value 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, the event protocol contains expected and / or prohibited input data in accordance with the set of rules in at least one event message,whose event time value 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 has received the event log and the status log from the vehicle device, and (h) generation of an error message upon detection of a lack of output data and / or input data expected according to the set of rules and / or upon detection of the presence of output data and / or input data prohibited according to at least one set of rules by the vehicle device and / or the central data processing device.

[0102] Preferably, event messages, each of which comprises received or generated input data linked to an event time value, are entered in an event log stored in a first data memory of a first device part of the vehicle device, and status information, each of which comprises generated output data linked to a status time value, is entered in a status log stored in a second device part of the vehicle device, which is received by the first device part and is coupled to the first device part for communication purposes, wherein a first processor of the first device part processes 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 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 a second processor of the second device part controls the sending of status information by the second device part as part of a DSRC communication.

[0103] The invention is explained below using exemplary embodiments.

[0104] To show Fig. 1 schematically shows a vehicle device according to the invention. Fig. 2 schematically shows a toll system according to the invention.

[0105] A vehicle device 20 according to the invention comprises - as shown schematically in Fig. 1 - a vehicle device 10 with a decentralized processor 11 as well as a DSRC communication module 22 and a displacement sensor 21 (for example, a mileage counter or an odometer), which are data-linked to the vehicle device 10. Data-linked components are described in Fig. 1 by continuous connecting lines between the coupled components. They can be implemented by interfaces, connecting lines, or wireless communication means (e.g., Bluetooth). The decentralized processor 11 is configured to control the DSRC communication module processor 22d and receive data from it by executing a computer program that is loaded from the data read / write memory 17a into the main memory 17b for execution. 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 from the received satellite signals using its GNSS receiver 12a—and thus the provisional position of a vehicle 30 (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, which are 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-finding.

[0106] In an alternative embodiment, the signals of the gyroscope 16 and the displacement sensor 21 can be passed to the GNSS positioning device 12 instead of to the processor 11, wherein the GNSS positioning device 12 performs the dead-finding.

[0107] 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.

[0108] 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 upon 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.

[0109] Instead 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.

[0110] A vehicle identification of the vehicle 30 is stored in the memory area 18b of the security module 18 or cryptographic data memory in the form of the vehicle license plate, which is included in at least one vehicle plate of the vehicle 30. Alternatively or optionally, the vehicle identification can be stored in the data read / write memory 17a.

[0111] Furthermore, an axle class and an emissions class, the combination of which forms a vehicle class, are stored in the memory area 18b of the security module 18.

[0112] An initial registration or change of the vehicle identification, the axle class and / or the emission class can be effected by the user by transmitting corresponding data and instructions to the processor 11 of the vehicle device via a user interface (not shown) (Bluetooth interface, USB interface, keyboard or touch-sensitive display device).

[0113] It 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 radio 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.

[0114] Such incoming instructions form first input data according to the invention, which are stored by the decentralized processor 11 in an event log provided for this purpose in the data read / write memory 17a, together with a first event time value of the input of the respective instruction, as a first event message.

[0115] 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 instructions—internal to the vehicle device—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. After the storage in the memory area 18b of the security module 18 has been successfully completed, 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.

[0116] Only after the security module 18 has confirmed storage does the decentralized processor 11 enter the received vehicle identification, the received axle class, and / or the received pollutant class as output data according to the invention, together with a status time value, in the status log. This status time value can correspond to the first event time value, the third and last event time value, or a time value that is even later than the third and last event time value and corresponds to the time value of the entry of the output data in the status log. While this is only a matter of definition, it does influence the determination of the predefined time range in which relevant event messages from the event log are to be searched for for status information in the status log during the log check according to the invention.

[0117] In this exemplary embodiment, 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.

[0118] 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. Alternatively or optionally, infrared light (850 nm) can be used as the DSRC communication carrier, with photodiodes being used as the receiving elements and IR LEDs as the transmitting elements.

[0119] 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.

[0120] 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 road by the vehicle 30, which can be identified on the basis of the recorded position data.

[0121] During a decentralized toll fee determination, the decentralized processor 11 uses a toll fee determination program executed in the main memory 17b to compare position data from 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 having been traveled. The decentralized processor 11 then uses the identifier of the route section recognized as having been traveled to determine a toll fee that depends on the axle class and the emission class of the vehicle 30.

[0122] In this respect, axle class and emission class are inventive state variables of the vehicle equipment 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.

[0123] 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.

[0124] In this respect, the vehicle identification is also a state variable of the vehicle device according to the invention, 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.

[0125] In the course of an alternative or optional central toll fee determination, 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.

[0126] During a central toll fee determination, 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 having been traveled. Subsequently, the central processor 51 uses the identifier of the route section recognized as having been traveled to determine a toll fee that depends on the axle class and the emission class of the vehicle 30.In this case, too, vehicle identification, axle class and emission class are state variables of the vehicle equipment 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.

[0127] In the case of decentralized toll collection, the route section recognized as being traveled also represents a state 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.

[0128] In particular, the decentralized processor 11 is configured to check the operational readiness of the vehicle device 20 upon receipt of power to the vehicle device 10 via the power supply connection 19 or as a result of the vehicle 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.Furthermore, the failure of charging 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.

[0129] If the toll fee calculation program is successfully loaded into the main memory 17b, a corresponding event message is entered in the event log.

[0130] The decentralized processor 11 then 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.

[0131] Furthermore, 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 write the storage of status information about the lack of operational readiness of the vehicle device into the status log stored in the DSRC communication module data read-write memory 22d.

[0132] 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.

[0133] 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.

[0134] After the decentralized processor 11 has commissioned the vehicle device 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 device. 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 device 20 or the vehicle device 10 via the power supply connection 19 and the last event of switching off or removing the power supply to the vehicle device 20 or the vehicle device 10 via the power supply connection 19.

[0135] For this purpose, the decentralized processor 11 checks, based on at least one set of rules stored in the data read / write 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 for its transmission to the central data processing device 50 (see Fig. 2 ) the mobile radio transceiver 13 is instructed by the decentralized processor.

[0136] 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.

[0137] For example, in the database, the input data of the three event messages "Attempt to load the toll calculation program into the working memory 17b", "Failure to load the toll calculation program into the working memory 17b" and "Registration of a lack of operational readiness" are linked to the output data of a status information "lack of operational readiness".This corresponds to the rule that the input data of the three aforementioned event messages must be stored in the event log if the status information "lack of operational readiness" is entered in the status log, or that the input data of the three aforementioned event messages in the event log must result in the status information "lack of operational readiness" in the status log, and only two of the three aforementioned event messages in the event log may be insufficient for the status information "lack of operational readiness" to be entered in the status log. It is possible that the status information "lack of operational readiness" is also entered in the status log (for the first time or again) due to the input data of other event messages.However, 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.

[0138] 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 inability to operate was determined 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."

[0139] After performing this self-test, the vehicle equipment 20 is ready for operation (unless it is in a state of lack of operational readiness) and displays this given operational readiness on the display device 15.

[0140] 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 power from a rechargeable battery (accumulator as an example of a charge storage element) 19a, which is included in the vehicle device 10. In this case, 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, 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.

[0141] 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 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 "sufficient operational readiness."

[0142] During operation of the vehicle device 20, the decentralized processor 11 of the vehicle unit 10 - and thus the vehicle device 20 - is configured 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 based on path length data of the path sensor 21 and direction angle change data of 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 levied for the use of a toll road section by the vehicle that is identifiable based on the acquired position data.

[0143] The processor 11 is designed to detect the events (i) the failure to receive signals from a global navigation satellite system at the position-determining device 12, (ii) the failure to generate position data from signals from a global navigation satellite system by the position-determining device 12, (iii) 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) the failure to receive signals at the interface for receiving signals from a displacement sensor 21, and / or (v) the lack of agreement between the direction angles of travel determined from signals from a global navigation satellite system and the direction angles of travel determined from changes in direction detected by the gyroscope 16.to enter these events with corresponding input data in the event log and, if such events are detected once or repeatedly - especially in immediate succession - to set the value of the operational readiness status of the vehicle equipment to "inadequate" and to enter corresponding status information in the status log.

[0144] 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 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 "sufficient operational readiness."

[0145] The further description of the operation of the vehicle device 20 according to the invention in a toll system according to the invention is based on Fig. 2 described.

[0146] During operation of the vehicle equipment 20 ( Fig. 1 ) is the decentralized processor 11 ( Fig. 1 ) of the vehicle device 10 - and thus the vehicle device 20 - is designed to transmit the mobile radio transceiver 13 ( Fig 1 ) to send the status log via a mobile radio network 40 to the central data processing device 50 located outside and away from the vehicle. The central data processing device 50 is comprised of a control center 58 of the toll system and has a central communications device 53, a central processor 51, a first central data memory 56, and a second central data memory 57. For example, the central communications 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 by the central data processing device 50.

[0147] The first central data storage 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.

[0148] 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.

[0149] Independently of this, 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.

[0150] 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 one 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 recorded 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.

[0151] If 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.

[0152] The exceptional status information and / or the status information of the exceptional combination of status information form status information to be checked according to the invention.

[0153] The vehicle device 20 is designed to receive an instruction to transmit the event log 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 event log via a mobile radio network 40 to the central data processing device 50 arranged outside and away from the vehicle.

[0154] The central data processing device 50 is designed to receive the event log sent by the vehicle device 20 and to store it in the second central data memory 57.In addition, the central data processing device 50 is designed to determine whether, for status information of the status protocol to be checked in the event protocol according to at least one set of rules stored in the first data memory 56, expected input data are contained in at least one event message whose event time value lies within a predetermined time range around the status time value of the status information to be checked, and to generate an error message upon detection of a lack of output data and / or expected input data according to the at least one set of rules and to add this error message to the data record stored in the first central data memory 56 which has the vehicle registration number of the vehicle 30.

[0155] During its journey on toll sections, vehicle 30 reaches a toll system inspection facility 60, which it passes without stopping. The inspection facility 60 has an inspection bridge 61 that spans the toll section transversely to the direction of travel, allowing vehicle 30 to pass underneath it. Attached to the inspection bridge 61 above the toll section are a control device 63 with a roadside DSRC communication device 63a, an image recording device 62, and a vehicle contour detection device 64.

[0156] The image recording device 62 records at least one image of the approaching vehicle 30 and, by means of an image data processing device (not shown), determines the vehicle registration number of the vehicle, which is printed on the vehicle registration plate 31 of the vehicle 30, from image data of the image of the approaching vehicle 30.

[0157] The vehicle contour detection device 64 detects the contour of the vehicle 30 and, by means of a classification device (not shown), determines a vehicle class of the vehicle 30 from the detected contour - in this case an axle class of the vehicle 30, which is determined based on the number of axles of the vehicle 30.

[0158] Examples of means for detecting vehicle contours that are familiar to those skilled in the art and that are included in the vehicle contour detection device 64 are: a radar, a LIDAR, a time-of-flight camera (TOF camera), a stereo camera arrangement, a light section sensor with structured illumination / shading of the vehicle.

[0159] During the passage of the vehicle 30 at the control device 60, the vehicle-side DSRC communication module 22 of the vehicle device 20 receives a request from the roadside DSRC communication device 63a to send a control-relevant extract of the status protocol to the roadside control device.The control-relevant extract of the status protocol contains status information with output data, each representing the value of a status variable of the vehicle equipment 20 in the form of a registered vehicle registration number of the vehicle 30, a registered axle class of the vehicle 30, a registered emission class of the vehicle 30, a registered operational readiness state of the vehicle equipment 20, a registered identifier of a toll road section last recognized as being traveled, and a registered identifier of a toll road section before last recognized as being traveled, along with the associated status time values.

[0160] The DSRC communication module processor 22c provides the requested excerpt of the status protocol to the vehicle-side DSRC transceiver 22a for transmission by accessing the DSRC communication module data read / write memory 22d, which transmits the excerpt to the roadside DSRC communication device 63a via the DSRC antenna 22b.

[0161] The control device 63 is designed to receive the extract of the status protocol by means of the roadside DSRC communication device 63a, as well as the recorded vehicle registration number of the vehicle 30 determined by the image recording device 62 and the recorded axle class of the vehicle 30 determined by the vehicle contour detection device 64, and to register each reception with a reception time.

[0162] Based on the times of receipt of the extract of the status protocol of the vehicle device 20 as well as the image recording and vehicle contour detection of the vehicle 30, the control device 63 assigns the recorded vehicle registration number to the registered vehicle registration number and the recorded axle class to the registered axle class.

[0163] The control device 63 is initially designed to obtain the status information with the output data from the received extract of the status protocol, which are to be compared with reference data of the control device 60.

[0164] The control device 63 is then designed to check the registered operational readiness state of the vehicle device 20 received from the vehicle device 20 to determine whether it corresponds to the lack of operational readiness and, if so, to send a problem message about the lack of operational readiness of the vehicle device 20 together with the time of receipt of the extract of the status protocol via the mobile radio network 40 to the central data processing device 50.

[0165] Furthermore, the control device 63 is designed to check the route section identifier received from the vehicle device 20 to determine whether it corresponds to the route section identifier of the route section that the control device bridges, and in the event of a mismatch, to send a problem message about the mismatch between the identifier of the toll-paying route section last recognized by the vehicle device 20 as being traveled and the identifier of the controlled route section to the central data processing device.

[0166] Furthermore, the control device 63 is designed to check the registered vehicle registration number sent by the vehicle device 20 for correspondence with the vehicle registration number recorded by the image recording device 62 and, in the event of a lack of correspondence, to send a problem message about the lack of correspondence between the received vehicle registration number and the registered vehicle registration number of the vehicle 20 to the central data processing device.

[0167] Finally, the control device 63 is designed to check the registered axle class sent by the vehicle device 20 for agreement with the axle class detected by the vehicle contour detection device 64 and, in the event of a lack of agreement, to send a problem message about the lack of agreement between the detected axle class and the registered axle class of the vehicle 20 to the central data processing device.

[0168] The central data processing device 50 is designed to receive each of the problem messages, wherein the receipt of a single problem message, whose problematic status information in this case forms the status information to be checked, is sufficient for the central data processing device to send a request to the vehicle device 20 to transmit the event log by means of the central communication device 53 via the mobile radio network 40.

[0169] The vehicle device 20 is designed to receive an instruction to transmit the event log 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 event log via a mobile radio network 40 to the central data processing device 50 arranged outside and away from the vehicle.

[0170] The central data processing device 50 is configured to receive the event log from the vehicle device 20 via the central communication device 53 and to store it in the second central data memory 57, linked to the status information(s) to be checked. The central processor 51 is configured to determine, for each item of status information to be checked, whether the event log contains expected input data in at least one event message according to at least one set of rules stored in the first data memory 56, the event time value of which lies within a predetermined time range around the status time value of the status information to be checked.

[0171] In the event that the status information to be checked comprises output data in the form of the value of the lack of operational readiness of the vehicle device 20 of the status variable "operational readiness state", the central processor 51 is designed to check according to the set of rules whether the transmitted event log contains one or more event messages of input data triggering a lack of operational readiness (examples of this are mentioned above), the event time value of which is no earlier than 10 seconds before and no later than the status time value of the registered lack of operational readiness.The central processor 51 is designed to generate a toll system error message if none or not all event messages whose input data trigger a lack of operational readiness are present in the event log in the said first time range of 10 seconds, and to generate a user error message if all event messages whose input data trigger a lack of operational readiness are present in the said first time range in the event log.

[0172] For example, it may be a mistake on the part of the user to drive on a toll-paying section of road with a non-operational vehicle device 20 if he has not previously deactivated this non-operational vehicle device (e.g. switched it off) and uses an alternative device to the vehicle device 20 for toll collection and / or payment.

[0173] In addition, the central processor 51 is designed to check, in accordance with the rules, whether the transmitted event log contains one or more event messages from input data that cancel a lack of operational readiness (examples of this are mentioned above), the event time value of which lies in a second time range later than the status time value of the registered lack of operational readiness and earlier than the time of receipt of the control-relevant extract of the status log by the control device 63. The central processor 51 is designed to generate a toll system error message if one or more event messages are present in the second time range whose input data triggers the cancellation of a lack of operational readiness, and to generate a user error message if no event message is present in the second time range whose input data triggers or contributes to the cancellation of the lack of operational readiness.

[0174] The processor 51 is particularly designed to generate a user error message only if all event messages necessary to trigger a lack of operational readiness are present in the first time range and not all event messages necessary to cancel a lack of operational readiness are present in the second time range.

[0175] In the event that the status information to be checked comprises output data in the form of the identifier of the toll road section last recognized as being travelled by the vehicle device 20, the central processor 51 is designed to check according to the set of rules whether the transmitted event log contains one or more event messages of input data generating this road section identifier, the event time value of which is not earlier than the status time value of the registered identifier of the toll road section last recognized as being travelled and not later than the status time value of the registered identifier of the toll road section last recognized as being travelled.The central processor 51 is designed to generate a toll system error message if none or not all event messages whose input data are a prerequisite for identifying the last route section traveled are present in the event log in the stated time range between two route section identifiers registered directly one after the other, and to generate a user error message if all event messages whose input data are a prerequisite for identifying the last route section traveled are present in the event log in the stated time range between two route section identifiers registered directly one after the other.

[0176] In this case, a user error may occur if a user simulates false navigation satellite signals to the GNSS positioning device 12, which the GNSS positioning device 12 uses to determine its position instead of the correct navigation satellite signals originating from the GNSS navigation satellites. This so-called spoofing causes the vehicle device to process position data from a different route, for example, a toll-free route, with the result that none of the toll road sections that should have been detected are detected. A similar effect can be caused by simulating interference signals (jamming), which leads to the GNSS positioning device 12 being unable to determine its position at all.

[0177] Input data in this case can be: a spatial and / or temporal mean of positions that were compared with the geographical elements of the digital map, a spatial and / or temporal mean of directions of travel whose positions were compared with the geographical elements of the digital map, the geographical element identified during the comparison, a measure of the quality of the GNSS positioning of the positions that were compared with the geographical elements of the digital map.

[0178] In the event that the status information to be checked has output data in the form of the registered vehicle registration number, the central processor 51 is designed to check according to the rule set whether the transmitted event log contains one or more event messages with input data that lead to the registration of the registered vehicle registration number and whose event time value is not earlier than 10 seconds before and not later than the status time value of the registered vehicle registration number.The central processor 51 is configured to generate a toll system error message if none or not all event messages whose input data are relevant for registration of the registered license plate are present in the event log in the said 10-second time range, and to generate a user error message if all event messages whose input data are relevant for registration of the registered vehicle license plate are present in the said 10-second time range in the event log.

[0179] For example, it may be a mistake on the part of the user to have changed his vehicle registration plate 31 without having entered a corresponding change in the vehicle registration number into the vehicle device or transmitted it to the central data processing device.

[0180] Input data that is relevant for registration of the registered vehicle registration number was given as an example earlier in the description text.

[0181] In the event that the status information to be checked has output data in the form of the registered axle class, the central processor 51 is designed to check according to the rule set whether the transmitted event protocol contains one or more event messages with input data that lead to the registration of the registered axle class and whose event time value is not earlier than 10 seconds before and not later than the status time value of the registered axle class.The central processor 51 is configured to generate a toll system error message if none or not all event messages whose input data are relevant for registration of the registered axle class are present in the event log in the said 10-second time range, and to generate a user error message if all event messages whose input data are relevant for registration of the registered axle class are present in the said 10-second time range in the event log.

[0182] For example, it may be a mistake on the part of the user to have fitted his three-axle tractor with a two-axle trailer without having entered a corresponding change in the axle class from three axles to five axles into the vehicle equipment or transmitted it to the central data processing device.

[0183] Examples of input data that are relevant for registration of the registered axle class were given earlier in the description text. List of reference symbols

[0184] 10Vehicle device 11Decentralized processor 12GNSS positioning device 12aGNSS receiver 12bGNSS receiving antenna 13Mobile radio transceiver (vehicle-side) 13bMobile radio antenna (vehicle-side) 14Radio clock 15Display device 16Gyroscope 17aData read / write memory 17bRAM 18Security module 18aAutonomous control module of the security module 18 18bMemory area of ​​the security module 18 19Power supply connection 19aBattery,Supercapacitor 20Vehicle equipment 21Displacement sensor 22DSRC communication module (vehicle-side) 22aDSRC transceiver (vehicle-side) 22bDSRC antenna 22cDSRC communication module processor 22dDSRC communication module data read / write memory 30Vehicle 31Vehicle license plate 40Mobile radio network 50Central data processing device 51Central processor 53Central communication device 56First central data storage 57Second central data storage 58Toll center 60Control device 61Control bridge 62Image recording device 63Control device 63aDSRC communication device (roadside) 64Vehicle contour detection device,

Claims

1. Toll system comprising at least one vehicle device (20) carried by a vehicle (30) and at least one central data processing device (50) arranged outside the vehicle, wherein the vehicle device (20) is designed, a) to detect position data of positions of the vehicle (30), b) to process the position data and / or data derived from the position data as a function of a plurality of status variables of the vehicle device (20) for the purpose of charging a toll related to the vehicle (30), which toll is to be charged for the use of a traffic area by the vehicle (30) which can be identified on the basis of the recorded position data, c) to receive or generate input data wherein the input data represents one or more of the following events: i) the failure to receive signals from a global navigation satellite system at a positioning device (12) which is comprised by the vehicle device (20) and is designed to receive and process signals from a global navigation satellite system and to generate position data by processing them; ii) the failure to generate position data from signals from a global navigation satellite system at a positioning device (12) which is comprised by the vehicle device (20) and which is designed to receive and process signals from a global navigation satellite system and to generate position data by processing them; iii) the quality of at least one signal from a global navigation satellite system and / or at least one position determined by a position determination device (12), which is comprised by the vehicle device (20) and is designed to receive and process signals from a global navigation satellite system and to generate position data by processing them, falls below a minimum quality level; iv) failure to receive signals at the interface for receiving signals from a motion sensor (21) included in the vehicle device; v) the lack of correspondence between direction of travel angles determined from signals from a global navigation satellite system and direction of travel angles determined from changes in direction of travel detected by an acceleration sensor / yaw rate sensor (16) of the vehicle device (20); vi) the failure to load software from a data memory (17a) of the vehicle device (20) into a working memory (17b) of the vehicle device; vii) exceeding a time value stored in a data memory (17a) of the vehicle device (20) or in a working memory (17b) of the vehicle device of the expiry of the validity of software to be used by the vehicle device (20); the absence of a time signal from a timer (14) of the vehicle device (20); viii) the charge state of a charge storage element (19a) of the vehicle device (20) falls below a predetermined ix) limit value; the failure to receive signals from base stations of a mobile radio network (40) at a mobile radio x) communication device (13) of the vehicle device (20); xi) the exceeding of a certain volume of toll charges which could not be transmitted to the central data processing facility (50) of the toll system by means of a mobile radio communication device (13) of the vehicle device (20); xii) receiving an instruction to disable a service of the vehicle device via a mobile radio communication device (13) of the vehicle device (20); xiii) the receipt of an instruction to change the vehicle's licence plate number (30); xiv) receipt of an instruction to change the vehicle class of the vehicle (30); xv) carrying out a self-test of the vehicle device (20); xvi) the receipt of an activation or blocking of a service of the vehicle device (20); xvii) the receipt of an instruction to change the facts with regard to a toll obligation or a toll exemption of the vehicle (30); d) to generate output data as a function of the received or generated input data, each of which represents a value of one of the state variables of the vehicle device (20) wherein a first state variable of the vehicle device (20) i) a registered identifier of the vehicle device (20), the vehicle (30) or a user of the vehicle (30), ii) a registered vehicle class of the vehicle (30), iii) a registered determination of the use or non-use of a toll road by the vehicle (30), iv) a registered toll or toll-free status of the vehicle (30) or v) a registered availability status of a specific service of the vehicle device (20 and a second state variable of the vehicle device (20) is a registered operational readiness state of the vehicle device (20), and di) to enter status information, which in each case comprises generated output data linked to a status time value, in at least one status log stored in the vehicle device (20), characterised in that the vehicle device (20) is designed, f) to log event messages, each comprising received or generated input data linked to an event time value, in at least one event log stored in the vehicle device (20), and the central data processing device (50), g) to determine on the basis of at least one set of rules stored in the central data processing device (50) whether i) for at least one event message of the event log to be checked, the status log contains expected and / or prohibited output data in accordance with the at least one set of rules in at least one piece of status information, the status time value of which is within a predefined time interval after the event time value of the event message to be checked, and / or ii) expected and / or prohibited input data for at least one piece of status information to be checked in the status log are contained in at least one event message in the event log in accordance with the at least one set of rules, the event time value of which lies within a predefined time interval before the status time value of the piece of status information to be checked, and h) when determining a lack of output data to be expected according to at least one set of rules and / or input data to be expected and / or upon detection of the presence of output data and / or input data that are prohibited according to the at least one set of rules to generate an error message2. Toll system according to claim 1, characterised in that the vehicle device (20) includes - at least one mobile radio communication device (13) for sending and / or receiving data to and / or from the central data processing device (50), - at least one positioning device (12) 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 distance sensor (21) for recording the distance travelled, - at least one acceleration sensor / yaw rate sensor (16) for detecting changes in the direction of travel of the vehicle (30), - at least one data memory (17a) in which the software of the vehicle device is stored, - at least one working memory (17b) into which software is loaded for use by the vehicle device (20), - at least one data memory (17a, 18b) in which at least one time value of the expiry of the validity of software to be used by the vehicle device is stored, - at least one data memory (17b, 18b) in which position data, data from identified traffic areas and / or data from toll surveys are stored at least temporarily, - at least one data memory (17a, 18b) in which a vehicle registration number of the vehicle is stored, - at least one data memory (17a, 18b) in which a vehicle class of the vehicle is stored, - at least one processor (11) configured to generate the output data by processing the input data, - at least one timer (14) and - at least one charge storage element (19a) for at least temporarily supplying power to at least one processor (11) of the vehicle device (20)3. Toll system according to one of claims 1 or 2, characterised in that the vehicle device (20) comprises - at least one vehicle-side communication device (13, 22) for wireless transmission of the event log to the central data processing device, and - at least one vehicle-side communication device (13, 22) for wireless transmission of at least one status information item of the status log to the central data processing device and is designed to send the event log and at least one status information item of the status log to the central data processing device (50), wherein the central data processing device (50) is designed, - to receiving the event log sent by the vehicle device (20) and the at least one status information sent by the vehicle device (20), and - at least steps g) and h) are carried out using at least one set of rules stored in the central data processing device (50).

4. Toll system according to claim 3, characterised in that the tolling system comprises at least one roadside DSRC communication device (63a) coupled to the central data processing device (50) for receiving the at least one status information of the status log from the vehicle device (20), and the vehicle device (20) - a first vehicle-side communication device in the form of a mobile radio communication device (13) for wireless transmission of the event log to the central data processing device (50) via at least one mobile radio network (40), and - a second vehicle-side communication device in the form of a vehicle-side DSRC communication device (22) for wirelessly sending the at least one status information of the status protocol to the roadside DSRC communication device (63a) and is designed, - to send the event log by means of the mobile radio communication device (13) via at least one mobile radio network (40) to the central data processing device (50), and - of the at least one status information of the status log to the roadside DSRC communication device (63a) of the toll system by means of the vehicle-side DSRC communication device (22).

5. Toll system according to one of claims 1 or 2, characterised in that the toll system comprises - at least one roadside control device (60) comprising at least one roadside DSRC communication device (63a) for receiving at least one status information of the status log from the vehicle device (20) and the vehicle device (20) comprises - a first communication device in the form of a mobile radio communication device (13) for wireless transmission of the event log to the central data processing device (50) via at least one mobile radio network, and - a second communication device in the form of a vehicle-side DSRC communication device (22) for wirelessly sending at least one status information of the status protocol to the roadside DSRC communication device (63a) and is designed, - to send the event log by means of the mobile radio communication device (13) at least one mobile radio network (40) to the central data processing device (50), and - to send at least one status information of the status log by means of the vehicle-side DSRC communication device (22) to the roadside DSRC communication device (63a) of the toll system, whereby the roadside control device (60) is designed, - to receive at least one status information of the status log from the vehicle device by means of the roadside DSRC communication device (63a), - to compare the output data of the at least one piece of status information of the status log with reference data to determine whether they match, - and, depending on the result of the comparison, to send a problem message to the central data processing device (50) about the lack of or given correspondence between the output data and the reference data, and the central data processing device (50) is designed, - to receive the problem message about the lack of or given conformity of the relevant output data with the reference data together with the relevant status information from the roadside control device (60), and - to send an event log request message via at least one mobile radio network (40) to the vehicle device (20) to request the event log, the vehicle device (20) is also designed, - to receive the event log request message by means of the mobile radio communication device (13) and, in response to the event log request message, to send the event log to the central data processing device (50) by means of the mobile radio communication device (13) via the mobile radio network (40), and the central data processing device (50) is further designed, - using the set of rules to determine whether the event log contains an event message with expected input data, the processing of which by the vehicle device (20) in accordance with the set of rules should generate the relevant status information with the relevant output data, and / or an event message with prohibited input data, the processing of which by the vehicle device (20) in accordance with the set of rules should not generate the relevant status information with the relevant output data, - to generate at least one toll system error message when detecting a lack of input data to be expected in the event log in accordance with the rules and regulations and / or when detecting the presence of input data prohibited in the event log in accordance with the rules and regulations, and - to generate a user error message when detecting the presence of input data expected in the event log in accordance with the set of rules and / or when detecting a lack of input data prohibited in the event log in accordance with the set of rules.

6. Toll system according to claim 5, characterised in that the output data represents a registered operational readiness status of the vehicle device (20), the reference data represent a state of inoperability of the vehicle device (20), and the roadside control device (60) is designed, in the event that the operational readiness status is that of insufficient operational readiness, to send a problem message about the insufficient operational readiness to the central data processing device (50).

7. Toll system according to claim 5, characterised in that the roadside control device (60) comprises - at least one camera (62) for generating at least one image recording of a licence plate of the vehicle (30), and - at least one image data processing device for obtaining a licence plate number from the image recording of the vehicle's licence plate (30) and is designed, - to generate at least one image recording of a licence plate of the vehicle (30) by means of the camera (62) and - using the image data processing device to obtain a recorded licence plate number from the image recording of the vehicle's licence plate (30), the output data represents a registered licence plate of the vehicle (30), and the reference data represents the recorded licence plate of the vehicle (30), and the roadside control device (60) is also designed, - in the case where the registered licence plate number and the recorded licence plate number are different, to send a problem message to the central data processing device (50) about the difference between the registered licence plate number and the recorded licence plate number.

8. Toll system according to claim 5, characterised in that the roadside control device (60) comprises - at least one detection device (64) for detecting an image and / or a contour of the vehicle (30), and - at least one classification device for determining a vehicle class of the vehicle (30) from the captured image and / or the captured contour of the vehicle (30) 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 (30) from the vehicle device (20) by means of the roadside DSRC device (63), - to detect at least one image and / or at least one contour of the vehicle (20) by means of the detection device (64), and - using the classification device to determine a detected vehicle class of the vehicle (30) from the detected image and / or the detected contour of the vehicle (30), the output data represents a registered vehicle class of the vehicle (30), the reference data represent the recorded vehicle class of the vehicle (30) and the roadside control device (60) is also designed, - in the case where the registered vehicle class and the detected vehicle class are different, to send a problem message to the central data processing device (50) about the difference between the registered vehicle class and the detected vehicle class.

9. Vehicle device (20) for detecting positions of a vehicle (30) by which it is carried, wherein the vehicle device (20) is designed a) to record position data of positions of the vehicle (30) b) to process the position data and / or data derived from the position data as a function of a plurality of status variables of the vehicle device (20) for the purpose of charging a toll related to the vehicle (30), which toll is to be charged for the use of a traffic area by the vehicle (30) which can be identified on the basis of the recorded position data, c) to receive or generate input data, where the input data represents one or more of the following events: i) the failure to receive signals from a global navigation satellite system at a positioning device (12) which is comprised by the vehicle device (20) and is designed to receive and process signals from a global navigation satellite system and to generate position data by processing them; ii) the failure to generate position data from signals from a global navigation satellite system at a positioning device (12) which is comprised by the vehicle device (20) and which is designed to receive and process signals from a global navigation satellite system and to generate position data by processing them; iii) the quality of at least one signal from a global navigation satellite system and / or at least one position determined by a position determination device (12), which is comprised by the vehicle device (20) and is designed to receive and process signals from a global navigation satellite system and to generate position data by processing them, falls below a minimum quality level; iv) failure to receive signals at the interface for receiving signals from a motion sensor (21) included in the vehicle device; v) the lack of correspondence between direction of travel angles determined from signals from a global navigation satellite system and direction of travel angles determined from changes in direction of travel detected by an acceleration sensor / yaw rate sensor (16) of the vehicle equipment (20); vi) the failure to load software from a data memory (17a) of the vehicle device (20) into a working memory (17b) of the vehicle device; vii) exceeding a time value stored in a data memory (17a) of the vehicle device (20) or in a working memory (17b) of the vehicle device of the expiry of the validity of software to be used by the vehicle device (20); the absence of a time signal from a timer (14) of the vehicle device (20); viii) the charge state of a charge storage element (19a) of the vehicle device (20) falls below a predetermined ix) limit value; the failure to receive signals from base stations of a mobile radio network (40) at a mobile radio x) communication device (13) of the vehicle device (20); the exceeding of a certain volume of toll charges which could not be transmitted to the central data xi) processing facility (50) of the toll system by means of a mobile radio communication device (13) of the vehicle device (20); receiving an instruction to disable a service of the vehicle device via a mobile radio communication device xii) (13) of the vehicle device (20); the receipt of an instruction to change the vehicle's licence plate number (30); xiii) receipt of an instruction to change the vehicle class of the vehicle (30); xiv) carrying out a self-test of the vehicle device (20); xv) the receipt of an activation or blocking of a service of the vehicle device (20); xvi) xvii) the receipt of an instruction to change the facts with regard to a toll obligation or a toll exemption of the vehicle (30); d) to generate output data as a function of the received or generated input data, each of which a value of one of the state variables of the vehicle device (20) wherein a first state variable of the vehicle device (20) i) a registered identifier of the vehicle device (20), the vehicle (30) or a user of the vehicle (30), ii) a registered vehicle class of the vehicle (30), iii) a registered determination of the use or non-use of a toll road by the vehicle (30), iv) a registered toll or toll-free status of the vehicle (30) or v) a registered availability status of a specific service of the vehicle device (20) and a second state variable of the vehicle device (20) is a registered operational readiness state of the vehicle device (20), and e) to enter status information, each of which comprises generated output data linked to a status time value, in a status log stored in the vehicle device (20), characterised in that the vehicle device (20) is also designed, f) to log event messages, each comprising received or generated input data linked to an event time value, in an event log stored in the vehicle device (20), g) to determine on the basis of at least one set of rules stored in the vehicle device (20) whether i) for at least one event message of the event log to be checked, expected and / or prohibited output data are contained in at least one status information item in the status log in accordance with the at least one set of rules, the status time value of which is within a predetermined time interval after the event time value of the event message to be checked, and / or ii) for at least one status information item of the status log to be checked, input data to be expected and / or prohibited in the event log 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 item to be checked, and h) when determining a lack of output data to be expected according to at least one set of rules and / or input data to be expected and / or upon detection of the presence of output data and / or input data that are prohibited according to the at least one set of rules to generate an error message.

10. Vehicle device according to claim 9, characterised in that the vehicle device (20) comprises - at least one mobile radio communication device (13) for sending and / or receiving data to and / or from the central data processing device (50), - at least one positioning device (12) 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 distance sensor (21) for recording the distance travelled, - at least one acceleration sensor / yaw rate sensor (16) for detecting changes in the direction of travel of the vehicle (30), - at least one data memory (17a) in which the software of the vehicle device is stored, - at least one working memory (17b) into which software is loaded for use by the vehicle device (20), - at least one data memory (17a, 18b) in which at least one time value of the expiry of the validity of software to be used by the vehicle device is stored, - at least one data memory (17b, 18b) in which position data, data from identified traffic areas and / or data from toll surveys are stored at least temporarily, - at least one data memory (17a, 18b) in which a vehicle registration number of the vehicle is stored, - at least one data memory (17a, 18b) in which a vehicle class of the vehicle is stored, - at least one processor (11) configured to generate the output data by processing the input data, - at least one timer (14) and - at least one charge storage element (19a) for at least temporarily supplying power to at least one processor (11) of the vehicle device (20)11. Vehicle device (20) according to one of claims 9 or 10 and with a central data processing device (50), characterised in that the vehicle device (20) is designed to send any error message that is generated to a central data processing device (50) of the toll system arranged outside the vehicle (30) by means of a mobile radio communication device (13) comprised by the vehicle device (20).

12. Vehicle device (20) according to claim 11, characterised in that the vehicle device (20) is designed to carry out a self-test depending on the event, time, location and / or randomly, in which the vehicle device (20) carries out steps g) i) and h) for at least one event message to be checked in the event log, whereby 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 log and whereby the at least one event message to be checked is defined by the fact that it has a delayed event time value compared to the time value of the last preceding self-test.

13. Vehicle device (20) according to claim 11 or 12, characterised in that the vehicle device (20) comprises - a mobile radio communication device (13) for wireless transmission of the status log via at least one mobile radio network (40) to at least one central data processing device (50) of the toll system located outside the vehicle (30) and is designed, - to send the status log to the central data processing device (50) by means of the mobile radio communication device (13), - to receive from the central data processing device (50) by means of the mobile radio communication device (13) an instruction to perform step g) ii) with respect to at least one piece of status information to be checked defined by the central data processing device (50), - to perform step g) ii) with respect to the at least one piece of status information to be checked as defined by the central data processing device (50), and to generate at least one error message when a deficiency in input data to be expected in accordance with the at least one set of rules is detected and / or when the presence of input data prohibited in accordance with the at least one set of rules is detected and to send this error message to the central data processing device (50) by means of the mobile radio communication device (13).

14. Method for detecting faults in a vehicle device (20) of a toll system carried by a vehicle (30), comprising the following steps: a) detection of position data of positions of the vehicle (30) by the vehicle device (20), b) processing of the position data and / or of data derived from the position data by the vehicle device (20) as a function of a plurality of status variables of the vehicle device (20) for the purpose of charging a toll related to the vehicle (30), which toll is to be charged for the use of a traffic area by the vehicle (30) which can be identified on the basis of the recorded position data, c) receipt or generation of input data by the vehicle device (20) where the input data represents one or more of the following events: i) the failure to receive signals from a global navigation satellite system at a positioning device (12) which is comprised by the vehicle device (20) and is designed to receive and process signals from a global navigation satellite system and to generate position data by processing them; ii) the failure to generate position data from signals from a global navigation satellite system at a positioning device (12) which is comprised by the vehicle device (20) and which is designed to receive and process signals from a global navigation satellite system and to generate position data by processing them; iii) the quality of at least one signal from a global navigation satellite system and / or at least one position determined by a position determination device (12), which is comprised by the vehicle device (20) and is designed to receive and process signals from a global navigation satellite system and to generate position data by processing them, falls below a minimum quality level; iv) failure to receive signals at the interface for receiving signals from a motion sensor (21) included in the vehicle device; v) the lack of correspondence between direction of travel angles determined from signals from a global navigation satellite system and direction of travel angles determined from changes in direction of travel detected by an acceleration sensor / yaw rate sensor (16) of the vehicle device (20); vi) the failure to load software from a data memory (17a) of the vehicle device (20) into a working memory (17b) of the vehicle device; vii) exceeding a time value stored in a data memory (17a) of the vehicle device (20) or in a working memory (17b) of the vehicle device of the expiry of the validity of software to be used by the vehicle device (20); the absence of a time signal from a timer (14) of the vehicle device (20); viii) the charge state of a charge storage element (19a) of the vehicle device (20) falls below a predetermined ix) limit value; the failure to receive signals from base stations of a mobile radio network (40) at a mobile radio x) communication device (13) of the vehicle device (20); xi) the exceeding of a certain volume of toll charges which could not be transmitted to the central data processing facility (50) of the toll system by means of a mobile radio communication device (13) of the vehicle device (20); xii) receiving an instruction to disable a service of the vehicle device via a mobile radio communication device (13) of the vehicle device (20); xiii) the receipt of an instruction to change the vehicle's licence plate number (30); xiv) the receipt of an instruction to change the vehicle class of the vehicle (30); xv) carrying out a self-test of the vehicle device (20); xvi) the receipt of an activation or blocking of a service of the vehicle device (20); xvii) the receipt of an instruction to change the facts with regard to a toll obligation or a toll exemption of the vehicle (30); d) generation of output dataeach representing a value of one of the state variables of the vehicle device (20), in dependence on the input data received or generated by the vehicle device (20) wherein a first state variable of the vehicle device (20) vi) a registered identifier of the vehicle device (20), the vehicle (30) or a user of the vehicle (30), vii) a registered vehicle class of the vehicle (30), viii) a registered determination of the use or non-use of a toll road by the vehicle (30), ix) a registered toll or toll-free status of the vehicle (30) or x) a registered availability status of a specific service of the vehicle device (20) and a second state variable of the vehicle device (20) is a registered operational readiness state of the vehicle device (20), and di) entry of status information, each comprising generated output data linked to a status time value, in a status log stored in the vehicle device (20) by the vehicle device (20) characterised by the further steps of the f) entry of event messages, each comprising received or generated input data linked to an event time value, in an event log stored in the vehicle device (20) by the vehicle device (20), g) determination by the vehicle device (20) and / or by a central data processing device (50) of the toll system arranged outside the vehicle (30) on the basis of at least one set of rules stored in the vehicle device (20) and / or in the central data processing device (50) as to whether i) for at least one event message of the event log to be checked, the status log contains expected and / or prohibited output data in accordance with the set of rules in at least one piece of status information, the status time value of which is within a predefined time interval after the event time value of the event message to be checked and / or ii) for at least one status information item of the status log to be checked, input data to be expected and / or prohibited in the event log in accordance with 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 item to be checked, and h) generation of an error message if a lack of output data and / or input data to be expected according to the set of rules is detected and / or upon detection of the presence of output data and / or input data prohibited in accordance with the at least one set of rules by the vehicle equipment (20) and / or the central data processing device (50).