VALIDATION OF DATA PROVIDED BY AN ON-BOARD DIAGNOSTIC SYSTEM

Description

[0001] The invention is concerned with a method for validating data provided by an on-board diagnostics system of a vehicle.

[0002] Nowadays, obtaining vehicle data plays a critical role in a variety of economically important activities. Such an activity is, for example, vehicle valuation, vehicle fleet management, or a vehicle related diagnostics and repair action. However, most vehicles in use are either completely unconnected to other vehicles or only have a limited connectivity possibility due to a lack of a corresponding communication device on board of such a vehicle. One way to obtain vehicle data from such an unconnected or only limitedly connected vehicle involves a connection device to establish a wired connection between a data reading device and the vehicle via the connection device. This is often referred to as a dongle solution. This means that the connection device is plugged into an on-board diagnostics (OBD) systems port. An OBD system is a vehicle self-diagnostics and reporting system that is designed to give a vehicle owner or repair technician access to the status of various vehicle subsystems. The vehicle data provided by the OBD system can be read via the installed connection device, for example, by establishing a wired communication connection to the connection device in a dealer workshop, via a Bluetooth connection between a mobile communication device and the connection device, and / or via a built-in subscriber identity module (SIM) card in the connection device itself. Another method to access vehicle data obtained from the OBD system involves retrofitting a vehicle with a physical device capable of reading data from this vehicle.

[0003] Document US 9,393,958 B2 discloses a method for validating information, wherein a first information item is detected continuously, at least for the duration of its relevance, by a vehicle-to-X communication device. A second information item is detected at the same time as the first information item by a sensor, wherein the sensor is coupled at the data level to the vehicle-to-X communication device. The first and second information items are validated by reconciling an information content of the first and second information item in the case of corresponding information content.

[0004] The publication "Exploiting Insurance Telematics for Fun and Profit" (Guan, L., Xu, J., Wang, S., Xing, X., Lin, L., Huang, H., Liu, P., and Lee, W. (2016). Exploiting Insurance Telematics for Fun and Profit. ArXiv, abs / 1609.02234.) describes a method to validate OBD data of a vehicle by using a statistic model. The statistic model predicts a velocity range for a given acceleration value measured by a tamper-resistant sensor of the vehicle. If velocity data of the OBD system of the vehicle match the predicted velocity range, the OBD-data is not considered manipulated. Another method for validating data provided by an on-board diagnostics system of a vehicle according to the state of the art is disclosed by US 2017 / 294054 A1.

[0005] It is an object of the present invention to provide a solution to provide reliable on-board diagnostics system data of a vehicle.

[0006] The object is accomplished by the subject matter of the independent claim.

[0007] Advantageous developments with convenient and non-trivial further embodiments of the invention are specified in the following description, the dependent claims and the figures.

[0008] The inventive method is based on the assumption that in a typical potential application concerning analysis and process of vehicle data integrity of vehicle data provided by a vehicle is paramount. Such a potential application is for example a user base vehicle insurance, a characterization of a current vehicle status, and / or a characterization of both vehicle status and vehicle performance. The reason for this is that it is difficult nowadays to guarantee the integrity of data, as one cannot easily distinguish between data generated by the vehicle itself and artificial vehicle data. Artificial vehicle data is, for example, vehicle data that was created based on authentic vehicle data by manipulating the authentic vehicle data. In this context, such artificial, manipulated data can be referred to as spoofed data. Such spoofed data is often even created intentionally, e.g., by a software developer who creates vehicle-like data by an off-vehicle computer to imitate data received from an OBD system. This can be done, for example, to simulate driving behavior of a vehicle but also, if the created data is transmitted to the OBD system of a vehicle, to manipulate data provided by this very OBD system. Based on such simulations functioning of a driver assistance system for a vehicle could be improved. It is therefore important to provide a method with which confidence in vehicle data coming from either a retrofit solution or a connection device for an OBD system can be stablished. Such a method could preferably be based on cross validation by correlating received vehicle data of different data type.

[0009] The inventive method for validating data provided by an OBD system of a vehicle therefore comprises receiving data related to the vehicle. The received data comprise a first data element provided by the OBD system of the vehicle. The OBD system, i.e., the first data element, is typically accessible by connecting the OBD system or a respective vehicle part with a connector device. A connection between the connector device and a device requesting vehicle data provided by the OBD system can be established as a wireless or as a wired connection. One way to obtain vehicle data via a wired connection involves installing the so-called dongle solution as connector. This means that a physical device, which can be referred to as a dongle device, is plugged into an OBD port of the vehicle. Once the dongle device is plugged in, vehicle data provided by the OBD system of the vehicle can be downloaded and read. Alternatively, a wireless connection between, for example, a mobile communication device as device requesting vehicle data and the OBD system can be established via a Bluetooth connection and / or a wireless local network such as a wireless local area network (WLAN). It is also possible to build in a subscriber identity module (SIM) card into the dongle device itself in order to obtain vehicle data from the OBD system. The OBD system preferably offers a OBD2 port for data extraction.

[0010] Additionally, the received data comprise at least one further data element. The first data element and the at least one further data element are acquired simultaneously. This first step of a method is performed by an off-vehicle device such as a server unit that is not located on board of a vehicle. The off-vehicle server unit is designed as a computer such as a network host. The server unit receives a set of data wherein all data received is related to one particular vehicle. The first data element that is provided by the OBD system of the vehicle could be for example (according to an aspect different from the claimed invention) an odometer reading value giving information on the total distance driven by the vehicle so far. This value is provided by the OBD system and can be transmitted as described above. The at least one further data element is retrieved in the same way and is thus as well data provided by the OBD system of the vehicle. The at least one further data element could be characterizing a throttle position, a fuel flow, a fuel consumption, an average vehicle gear selection over time, and / or a rotational speed of a vehicle engine as a revolutions per minute value. In this example, different data connected to the engine of the vehicle are received as at least one further data element.

[0011] In a following step, evaluating of the received data is performed. This means that the first data element and the at least one further data element are evaluated according to a correlation rule. This is done in order to provide a probability value that characterizes a probability with which the first data element is manipulation-free. Therefore the correlation rule comprises a specific data element value range for the at least one further data element that is correlated with a first data element value of the received first data element. In other word, the correlation rule comprises a specific data element value range for the at least one further data element that is a function of a current value of the received first data element. This means that for the received odometer reading value, which is the first data element in this example, a specific range of, for example, the rotational speed of the vehicle engine as a revolutions per minute value as well as the current vehicle gear selection over time value is given, respectively. Analogously, a respective value range is defined for fuel consumption, throttle position and fuel flow is given for each specific odometer reading value. This means that first of all the different data elements, i.e., the first data element and the at least one further data element are correlated with each other. To be precise, a distribution function is given for every possible odometer reading value connecting the respective odometer reading value with the respective range of any of the named further data elements. The correlation rule thus provides a clear definition whenever the given odometer reading value seems probable after performing a cross validation with the different further data elements. This cross validation is based on the idea that a digital physical model of the vehicle exists in which details are defined that describe how individual parts of the vehicle are connected in a specific vehicle situation such as a driving, accelerating, braking or stopping situation. This digital model hence describes how a throttle position value describing the throttle position of the engine is mathematically connected to the respective other at least one further data element and / or the first data element.

[0012] If the provided probability value is in a specific probability value range, validation of the data provided by the OBD system is confirmed by creating a certification signal indicating that the data provided by the OBD system is confirmed valid. As specific probability value range is could be prescribed that if the provided probability value is between 70 and 100 percent, the provided vehicle data is confirmed as real and therefore trustworthy vehicle data. This means that if the probability value indicates that the first data element is actually a true first data element that has not been manipulated with and therefore was not artificially forged this information is taken into account to estimate if the provided specific probability value is high enough to confirm reliability of the data from the OBD system. In other words one could say that the first data element is accepted or rejected as a trustworthy signal recovered from the OBD system if it is appropriately mathematically related to other internal signals, i.e., to the further data elements. These further data elements are produced for example by the vehicle itself when the first data element is being measured. This means that if one is interested in measuring the total length of distance driven by the vehicle, then the reported odometer reading value of an odometer reading device of the vehicle should be highly correlated to the described further data elements. As the odometer reading value should be correlated to fuel consumption, and fuel consumption correlated to throttle position and fuel flow. Explicitly, the integral of different signals over time related to generation of motion should be correlated to motion measurements, whereby motion measurements are here the first data elements as the odometer reading value. The different data elements related to the generation of motion are either connected to each other on a physical basis, e.g., each depending on gear tuning, or on a chemical basis, e.g., each dependent on fuel consumption. Those values are summed up as the at least one further data element.

[0013] Additionally to the described confirmation of the vehicle data provided by the OBD system as valid based on the provided probability value, the first data element as well as the at least one further data element could each be checked for plausibility. This is done in consideration of a respective predefined minimal and / or maximal value of the first data element and the at least one further data element. This can result in rejecting any data element as non-valid if this data element indicates that, for example, the vehicle has been driving at a speed greater than a maximal speed of the vehicle or at a non-land based location. In other words, a sanity check is performed on the first data element and / or the at least one further data element, respectively, to immediately recognize obviously manipulated vehicle data. Even if the provided probability value is in the specific probability value range, validation of the data provided by the OBD system is then not confirmed due to the failed sanity check. Thus, a fast and reliable additional mechanism to identify manipulated vehicle data is provided.

[0014] If validation of the vehicle data has been confirmed, the created certification signal is kept for retrieval stored in a memory unit. The memory unit can be comprised by or connected to the off-vehicle device such as an off-vehicle server unit. This off-vehicle server unit can be the server unit in which the previously described steps of the method are conducted. Alternatively or additionally, the created certification signal can be stored in a different server unit that is independent of the server unit that performs the above-mentioned steps. Alternatively or additionally, the memory unit can be designed as an in-vehicle device. If this is the case, retrieval of the stored certification signal is possible in an environment without communication connection to the off-vehicle memory unit, i.e., to the off-vehicle device. However, the certification signal is stored in an encrypted manner on the in-vehicle device to decrease susceptibility to manipulation attempt on the created and stored certification signal. In the end, the created certification signal can be used to create a vehicle curriculum vitae (CV). The reason behind this is that there is a lot of fraud associated with the false reporting of how many kilometers a vehicle has been driven. But by correlating different data elements with the odometer reading value from the vehicle as first data element can be used to build confidence in data reported by vehicle because in the end all data provided by the OBD system can be validated with the described method. This is for example of interest when the vehicle is supposed to be sold or bought by a person. Because as advantage, confidence is built into the vehicle data provided by the OBD system meaning that reliable data for example regarding the odometer reading value of a vehicle are available and stored in the memory unit which is in this example an off-vehicle server unit.

[0015] The at least one further data element is provided by the OBD system of the vehicle. As already described in the example above, the further data element is, just like the first data element, provided by the OBD system. If this is the case, at least the further data elements describing physically or chemically a motion or other engine correlated activities within the vehicle can be taken into account to make sure that the first data element in question can be validated as manipulation-free. Additionally or alternatively to the already described further data elements, position data of the vehicle provided by a satellite navigation system with global coverage, i.e., a global navigation satellite system (GNSS) such as the global positioning system (GPS) and / or temperature data of a temperature sensor device of the vehicle can be considered as at least one further data element provided by the OBD system. Considering all the different possibilities to cross correlate and connect the first data element with the at least one further data element, a high reliability of the OBD system data provided by the specific vehicle is achieved.

[0016] The at least one further data element is provided by an off-vehicle equipment. This off-vehicle equipment is particularly designed as an off-vehicle sensor device. It is hence possible to consider additional data such as weather data provided by an external weather station as at least one further data element and not just in-vehicle data provided by the OBD system. Alternatively or additionally, a traffic camera, a velocity measurement device located on a road, and / or a public or private rain sensor device can function as an respective off-vehicle equipment.

[0017] The first data element is GNSS data provided by the OBD system, and data provided by a local weather station is taken into account as further data elements. Hereby, data on total rain fall and current temperature are provided by both the OBD system as well as by the weather station. This weather information from the off-vehicle equipment, i.e., the weather station, is then cross-correlated to the weather information from OBD system, as the vehicle, for example, also detects an event of rain with a rain sensor positioned at a windshield of the vehicle as well as measures temperature data with an outdoor temperature sensor. If it is determined that the GNSS data, the rain sensor measurement data and the temperature sensor measurement data are not correlated to the external weather information data provided by the weather station it could be concluded that the GNSS signal may not be authentic. If, however, the GNSS signal is found to be authentic, the OBD system data is confirmed valid and therefore the certification signal is created and stored in the memory unit. It is therefore possible to further increase reliability of the described validation method by additionally taking data provided by off-vehicle equipment into account. to the method comprises verifying the odometer reading value as first data element by cross-validating it with the GNSS data provided by the OBD system based on which the total length driven with the vehicle could be estimated. Because if the GNSS data has been proven to be valid, the validity of the odometer reading value is derived from this result as well.

[0018] The method comprises that an off-vehicle device receives and evaluates the first data element and the further data elements. The different steps described above therefore do not take place within the vehicle that provides the OBD system data in question but in a device that is separated from the vehicle. Therefore the data comprising the first data element and the at least one further data element are first transmitted to the off-vehicle device where evaluation of these data elements takes place. This makes the described method less susceptible for fraud and manipulation and allows the possibility to detect tempered with OBD system data by performing the described steps.

[0019] The invention also comprises embodiments that provide features which afford additional technical advantages.

[0020] It is furthermore intended in an not claimed embodiment to take into account data that is collected and provided by another vehicle as at least one further data element. This means that not only data provided by vehicle-to-infrastructure communication, i.e., data as provided by the off-vehicle equipment can be taken into account but also data that is provided other vehicle and is thus received from another vehicle. Hereby, for example, the server unit can receive data directly from the other vehicle or data can be received via vehicle-to-vehicle communication by the vehicle and then be transmitted to the server unit together with the first data element. This means that sensor data, for example, from another vehicle that is driving in a certain specified distance to the vehicle of which OBD data is investigated can be used to evaluate the probability value. The at least one further data element could then be sensor data provided by a sensor device the other vehicle and / or OBD system data provided by the other vehicle. It is therefore not given that the process of authentication of the vehicle data from the OBD system only depends on data from the authenticating party, meaning the vehicle that provides the OBD system data. It is furthermore possible to have proprietary access to external corroborating data, such as data from the off-vehicle equipment but also data from the other vehicle. Such access may come from exclusive access to environmental sensors but also from sensors from other vehicles that are either produced by the same manufacturer as the vehicle in question or by other vehicle manufacturers. Finally, this further increases reliability in the result of the validation procedure for the data provided by the OBD system of the vehicle.

[0021] Moreover, an embodiment of a method comprises as the off-vehicle device an analysis device connected with a OBD system, a mobile communication device, and / or a server unit. It is for example possible that the described dongle solution is realized by plugging the connection device, i.e., the dongle device into the OBD2 port of the vehicle. This means that some sort of analysis device referred to as the dongle device, is directly connected to the OBD system. In case of a wireless connection to the OBD system this connection can be built-up with the help of a mobile communication device, for example, the mobile communication device of a workshop worker or an owner of the vehicle. The connection between the mobile communication device and the OBD system could then be achieved by a Bluetooth connection. The analysis device connected with the OBD system can also contain a build-in SIM card in order to be able to access the OBD system data of the vehicle. Furthermore the data can be directly sent to the server unit as described above. The off-vehicle device can therefore be chosen from a variety of possible off-vehicle devices. Essential is, that the off-vehicle device is capable of performing the evaluation steps as described above. This offers numerous opportunities for implementation of the described method.

[0022] According to another embodiment, the data related to the vehicle is only received on demand of a request signal. This means that only upon receiving the request signal data related to the vehicle is sent to, for example, the server unit as off-vehicle device in order to evaluate the first data element and the at least one further data element according to the correlation rule. The request signal can, for example, be provided by a vehicle selling platform or a manufacture that sends an electronic request signal to the server unit so that the server unit asks for data related to the vehicle from the OBD system and, if necessary, from the source of the at least one further data element, i.e., the off-vehicle equipment and / or the other vehicle.

[0023] A request signal could also be provided by a person who provides the request signal by sending a request via an application of a mobile communication device to the off-vehicle device asking for validation of data provided by the OBD system of a specific vehicle. This means that the method only takes place once it has been activated manually or automatically by transmitting the request signal. This allows a potential buyers or sellers or a manufacturer of the vehicle to request a validation of the vehicle data provided by a specific vehicle. It is therefore easy and comfortably executable within reach for a person to ask for validation of an identity of the designated vehicle.

[0024] In another embodiment, it is disclosed that the request signal is created at a randomly selected point in time. This means, it is possible to randomly check if the data provided by an OBD system of the specific vehicle is valid or not. This allows for spontaneous review and examination of the data provided by a specific vehicle without warning in advance. This increases reliability of the described method because potential manipulation of the vehicle data cannot be deleted before the validation step takes place due to a previously known time stating when the validation method is supposed to take place. This results in a particularly reliable vehicle CV that can be provided for a specific vehicle and its vehicle data.

[0025] The vehicle that provides OBD system data is designed as a motor vehicle, in particular as a passenger vehicle or a truck, or as a bus or a motorcycle.

[0026] The invention also discloses a not claimed system for validating data provided by an on-board diagnostics system of a vehicle. The system comprises the vehicle with the OBD system, a memory unit and an off-vehicle device. The system is designed to conduct the method as described above. The invention also comprises not claimed embodiments of the system that comprise features that correspond to features as they have already been described in connection with the embodiments of the inventive method. For this reason, the corresponding features of the embodiments of the system are not described here again.

[0027] The vehicle of the system is preferably designed as a motor vehicle, in particular as a passenger vehicle or a truck, or as a bus or a motorcycle.

[0028] In order to perform the inventive method, the invention also provides a processing unit for a server unit comprising at least one processor and a data memory coupled to the at least one processor, wherein the processing unit is designed to perform corresponding steps for the server unit of an embodiment of the inventive method. The at least one processor may each be based on one of a microprocessor and a microcontroller and an ASIC (application specific integrated circuit). For performing the inventive method, the data memory may comprise computer readable instructions that -when executed by the at least one processor- cause the at least one processor to perform the embodiment of the inventive method. The processing unit may comprise one or more microprocessors and / or one or more microcontrollers. Further, the processing unit may comprise program code that is designed to perform the described method when executed by the processing unit. The program code may be stored in a data storage of the processing unit.

[0029] The invention also comprises the combinations of the features of the different embodiments.

[0030] In the following an exemplary implementation of the invention is described. The only Fig. shows a schematic illustration of a method for validating data provided by an on-board diagnostic system of a vehicle.

[0031] The embodiment explained in the following is a preferred embodiment of the invention. However, in the embodiment, the described components of the embodiment each represent individual features of the invention which are to be considered independently of each other and which each develop the invention also independently of each other and thereby are also to be regarded as a component of the invention in individual manner or in another than the shown combination. Furthermore, the described embodiment can also be supplemented by further features of the invention already described.

[0032] In the figure identical reference signs indicate elements that provide the same function.

[0033] In the only Fig. individual steps of a method for validating data provided by an on-board diagnostic (OBD) system 10 of a vehicle 12 are sketched. Most steps of this method are conducted by an off-vehicle device 14, which is sketched as an off-vehicle server unit. In a first step S1, the off-vehicle device 14 receives data related to the vehicle 12. The received data comprise a first data element 16. The first data element 16 is provided by the OBD system 10 of the vehicle 12. It is received by the off-vehicle device 14, which can be designed as an analysis device connected with the OBD system 10. Alternatively or additionally, the first data element 16 can be received by a mobile communication device 42 and / or by the off-vehicle server unit, as it is sketched in the only Fig.

[0034] Additionally to the first data element 16, the data related to the vehicle 12 received by the off-vehicle device 14 also comprises a further data element 18. Further data element 18 is also provided by the OBD system 10. After receiving the first data element 16 and the further data element 18 in step S1, an evaluation step is taking place in step S2. This evaluating step takes place in an evaluation unit 20 of the server unit as off-vehicle device 14. Hereby the first data element 16 and the further data element 18 are evaluated according to a correlation rule 22. This is done in order to provide a probability value 24 that characterizes a probability with which the first data element 16 is manipulation-free.

[0035] The correlation rule 22 comprises a specific data element value range for the data element 18 that is correlated with a first data element value of the received first data element 16. The first data element 16 is here as an example an odometer reading value given by the OBD system 10. The further data element 18 is here a position value provided by a global navigation satellite system (GNSS) describing at least one position to which the vehicle 12 has been travelled. Based on GNSS data as further data elements 18, the total distance driven by the vehicle 12 can be approximated, i.e., the odometer reading value. There should thus be a correlation between the value of the further data element 18 and the first data element 16. If those values match, meaning that the approximated distance driven by the vehicle 12 according to the GNSS data as further data element 18 matches the odometer reading value given as the first data element 16, the corresponding probability value 24 characterizes that the first data element 16 is supposed to be manipulation-free. Because if the provided probability value 24 is in a specific probability value range 26, the validation of the data provided by the OBD system 10 is confirmed. This takes place in step S3. In the only Fig., the specific probability value range 26 is sketched as a value range of a data graph between two dashed lines. In situation A, the probability value 24 is in the specific probability value range 26. Hence, validation of the data provided by the OBD system 10 is given in situation A. If this is the case, a certification signal 28 is created in step S4. The certification signal 28 indicates that data provided by the OBD system 10 is confirmed valid. In a next step S5 the created certification signal 28 is kept for retrieval stored in a memory unit 30. Here, the memory unit 30 is the off-vehicle device 14, i.e., the server unit. More precisely, the created certification signal 28 is stored in the memory unit 30 of the off-vehicle device 14.

[0036] If, however, the provided probability value is not in the specific probability value range 26 as it is sketched in situation B, the validation of the data provided by the OBD system 10 cannot be confirmed. This can result in creating a warning signal 32 indicating the data provided by the OBD system 10 is not confirmed valid and thus confirmed invalid. The warning signal 32 can also be stored in the memory unit 30 for further retrieval.

[0037] It is furthermore possible to add other further data elements 18 to make the whole method more reliable. Therefore data from an off-vehicle equipment 34 can be taken into account. The off-vehicle equipment 34 is preferably an off-vehicle sensor device like a weather station. This weather station can provide additional further data elements 18' that are for example a measured rainfall volume value as well as a measured temperature. Furthermore another vehicle 36 can provide sensor data from a sensor unit 38 of the other vehicle 36. This could be a temperature data measured by the other sensor unit 38 of the other vehicle 36 that is provided as further data element 18". This data can now additionally be taken into account. Now it is beneficial, if additionally to the GNSS data as a further data element 18 also temperature data measured by a sensor of the vehicle 12 as well as rain indication data signaling that rain has been monitored to be fallen on a windshield of the vehicle 12 are also taken into account. These additional vehicle data are both provided as further data elements 18 provided by the OBD system 10 of the vehicle 12. All of this allows for cross-validation of the temperature data determined by the other vehicle 36 (i.e. further data element 18") with the temperature data provided by the OBD system 10 of the vehicle 12 as well as cross-validation of the information on rainfall in general provided by the OBD system 10 (i.e. further data element 18) with the data from the weather station as off-vehicle equipment 34 (i.e. further data element 18'). If now still all information match meaning that the evaluation step S2 and S3 result in a positive result as it is the case in situation A, an especially reliable certification signal 28 can be provided for the vehicle 12.

[0038] The data related to the vehicle 12 is only received by the off-vehicle device 14 upon receiving a request signal 40. The request signal 40 can be provided by the mobile communication device 42 of a person. Alternatively, it could also be provided as an automatically generated request signal 40 generated by a vehicle seller platform, a manufacturer, and / or the server unit. The request signal 40 could also be created at a randomly selected point in time 44 meaning that there is no indication for an upcoming request signal 40 so that the time when the data related to the vehicle 12 is received and evaluated is not known in advance.

[0039] Overall, the example shows how cross-validation of data extracted from the vehicle 12 is provided by the invention.

Claims

1. Method for validating data provided by an on-board diagnostics system (10) of a vehicle (12), the method comprising: - receiving data related to the vehicle (12), wherein the received data comprise a first data element (16), which is GNSS data provided by the on-board diagnostics system (10) of the vehicle (12), and further data elements (18), wherein the further data elements (18) are data on total rainfall and current temperature provided by the on-board diagnostics system (10) of the vehicle (12) and a local weather station, wherein the first data element (16) and the further data elements (18) are acquired simultaneously (S1); - evaluating the first data element (16) and the further data elements (18) according to a correlation rule (22) to provide a probability value (24) that characterizes a probability with which the first data element (16) is manipulation-free, wherein the method comprises cross-correlating the data on total rainfall and current temperature from the local weather station to the data on total rainfall and current temperature from the on-board diagnostics system (10) and the correlation rule (22) comprises a specific data element value range for the further data elements (18) that is a function of a current value of the received first data element (S2); - if the provided probability value (24) is in a specific probability value range (26), • confirming validation of the data provided by the on-board diagnostics system (10) (S3) by creating a certification signal (28) indicating that data provided by the on-board diagnostics system (10) is confirmed valid (S4) and keeping the created certification signal (28) for retrieval stored in a memory unit (30) (S5), and • further verifying an odometer reading value giving information on a total distance driven by the vehicle (12) so far by cross-validating it with the GNSS data provided by the on-board diagnostics system (10) based on which a total driven length with the vehicle (12) is estimated, wherein an off-vehicle device (14), which is designed as a computer, receives and evaluates the first data element (16) and the further data elements (18).

2. Method according to claim 1, wherein the off-vehicle device (14) is an analysis device connected with the on-board diagnostics system (10), a mobile communication device (42) and / or a server unit (14).

3. Method according to any of the preceding claims, wherein the data related to the vehicle (12) is only received on demand of / upon receiving a request signal (40).

4. Method according to claim 3, wherein the request signal (40) is created at a randomly selected point in time (44).