VERIFYING INTEGRITY OF A VEHICLE

Abstract

 A method of verifying integrity of a vehicle comprises sending (110) queries for vehicle data to a plurality of different components (61-63, 72, 74, 76) within the vehicle (10) and receiving (116) vehicle data in response to the queries. The method comprises analysing (132) the received vehicle data for anomalies and generating (134) an indication of integrity of the vehicle (10) based on the analysing. The method may receive a set of vehicle data values from different components (61-63, 72, 74, 76) of the vehicle and analyse the set of vehicle data values for anomalies. The method may receive a vehicle data measured in terms of a different quantity and convert to a quantity of interest, e.g. a number of wheel rotations to distance travelled. The method may be used to verify distance travelled (mileage) or integrity of components within the vehicle.

Description

Background

[0001] A vehicle, such as a car or goods vehicle, records total distance travelled on an odometer. At the point of sale of a vehicle, the total distance as recorded by the odometer of the vehicle is used as a measure of the technical condition of the vehicle, and a value of the vehicle is based on the mileage.

[0002] The total distance travelled will be referred to as "mileage". The mileage on most vehicles is susceptible to alteration by rogue operators. Reducing the odometer mileage to a numerical value, or reading, which is lower than the true numerical value has a direct effect on safety of the vehicle. Many components of a vehicle have a limited lifetime which is often measured in terms of mileage of the vehicle. The safety of the vehicle is dependent on components being serviced, or replaced, according to a schedule which is based on distance travelled or time. For example, a vehicle which has travelled a total distance of 100,000 km may require certain components, or consumable items, to be replaced in line with the manufacturer's maintenance schedule. However, if the odometer mileage has been unscrupulously reset to 50,000 km without replacing those components or consumable items, an innocent third party acquiring the vehicle will be unaware of a need to replace those components or consumable items. This has a direct effect on safety of the vehicle. Reducing the odometer mileage can also increase a monetary value of the vehicle for resale.

[0003] Some measures have been implemented in an attempt to prevent tampering with the odometer of a vehicle. One measure is to record the mileage on a public register at the time of an annual vehicle inspection, such as a Ministry of Transport (MOT) inspection in the United Kingdom. However, the first MOT inspection only occurs after a period of three years from a date of first registration of a vehicle. Therefore recording the mileage is not a safeguard against unscrupulous reduction of odometer mileage during a period before the first inspection. Also, it does not prevent an unscrupulous reduction of mileage before any of the subsequent inspections.

[0004] A vehicle requires servicing at intervals which are typically based on distance travelled or time, with parts being replaced before their end-of-life expiry. Servicing is recorded in paper-based records or digital online records. However, that is not a safeguard against unscrupulous updating of servicing records where the required work has not been performed to the vehicle.

Summary

[0005] There is provided a method of verifying integrity of a vehicle comprising:

sending queries for vehicle data to a plurality of different components within the vehicle;

receiving vehicle data in response to the queries;

analysing the received vehicle data for anomalies; and

generating an indication of integrity of the vehicle based on the analysing.

[0006] An advantage of at least one example is obtaining a more reliable indication of the integrity of a vehicle. This provides a higher certainty of the safety of a vehicle compared to conventional techniques, such as relying on paperwork-based or register-based records of mileage and maintenance schedules. In at least one example, the method provides a more reliable indication of distance travelled by the vehicle. In at least one example, the method provides a more reliable indication of integrity of components of the vehicle, such as an indication of whether components have been unexpectedly replaced in the vehicle (e.g. due to a collision), or an indication of whether components have been replaced in the vehicle following a warning of a problem with the vehicle, such as an Engine Management Light (EML).

[0007] Optionally, the queries request vehicle data indicative of a first property of the vehicle, receiving vehicle data comprises receiving a set of vehicle data values comprising at least a first vehicle data value from a first component of the vehicle and a second vehicle data value from a second component of the vehicle, and analysing the vehicle data for anomalies comprises comparing the set of received vehicle data values. This form of analysis makes use of the realisation that multiple components within a vehicle all store data values about the same property (e.g. distance travelled). This form of analysis checks that the data held within the vehicle is consistent. This can help to identify if an attempt has been made to mask a change to some property of the vehicle (e.g. distance travelled) as it is likely that a data value held in one or more of the possible storage locations has not been modified.

[0008] Optionally, analysing the vehicle data for anomalies comprises determining if the set of received vehicle data values are equal, or if the set of received vehicle data lie within a threshold range of each other.

[0009] Optionally, the queries for vehicle data comprise: a first query for vehicle data sent to a first component of the vehicle, wherein the first query is for vehicle data in the form of a first quantity which is indicative of the first property of the vehicle; and a second query for vehicle data sent to a second component of the vehicle, wherein the second query is for vehicle data in the form of a second quantity which is also indicative of the first property of the vehicle, wherein the second quantity is different to the first quantity. An advantage of obtaining vehicle data in the form of a second quantity is that it provides a way of confirming that the first quantity is accurate. The vehicle data in the form of a second quantity acts as a kind of checksum. It is also beneficial to use data which does not directly record the first quantity (e.g. distance travelled) as it is less likely to have been modified by a person who has attempted to mask changes within the vehicle to records of the first quantity on the vehicle.

[0010] Optionally, the receiving comprises: receiving a first vehicle data value in response to the first query, wherein the first vehicle data value is expressed in units of the first quantity; and receiving a second vehicle data value in response to the second query, wherein the second vehicle data value is expressed in units of the second quantity, and the method comprises converting the second vehicle data value from units of the second quantity to units of the first quantity to allow for comparison between the received data values.

[0011] Optionally, the first property of the vehicle is distance travelled and the converting comprises at least one of: converting a received data value expressed in units of a number of wheel rotations to a data value expressed in units of distance travelled; converting a received data value expressed in units of fuel volume to a data value expressed in units of distance travelled.

[0012] Optionally, the converting uses conversion data based on the vehicle.

[0013] Optionally, analysing the vehicle data values for anomalies comprises comparing at least one of the vehicle data values, or a data value based on the received vehicle data values, with external data comprising an expected data value for the first property. This form of analysis checks that the data held within the vehicle is consistent with data stored externally of the vehicle. If an attempt has been made to modify data held within the vehicle, then it is likely that the data held within the vehicle will not correspond to data held externally of the vehicle.

[0014] Optionally, the external data is a store of at least one of: vehicle data indicating expected data values for a vehicle; vehicle data recorded at a periodic vehicle inspection; vehicle data relating to vehicle accidents; vehicle data relating to vehicle servicing; vehicle data relating to vehicle recalls.

[0015] Optionally, the first property of the vehicle is activation of a safety component of the vehicle and the set of vehicle data values comprises at least: a first vehicle data value from a first component of the vehicle indicating an activation state of a safety component; and a second vehicle data value from a second component of the vehicle indicating an activation state of a safety component, and analysing the vehicle data for anomalies comprises comparing the set of received vehicle data values for an inconsistency in the activation state of the safety component received from the first component and the second component. This can detect if an attempt has been made to mask activation of a safety component of the vehicle (e.g. an airbag), which points to the vehicle having been involved in a collision.

[0016] Optionally, the queries request: warning data indicative of: (i) the vehicle issuing a warning in respect of a problem with the vehicle and (ii) a clearing of the warning; and component data for a component that requires placement in order to clear the warning, receiving vehicle data comprises: receiving the warning data; and receiving the component data, and analysing the vehicle data for anomalies comprises determining whether the component data indicates that the component has been replaced. This can detect if an attempt has been made to mask activation of a warning, which points to masking of a potentially serious problem with one or more components of the vehicle.

[0017] Optionally, the analysing uses at least one of: a build date of the component and a serial number of the component.

[0018] Optionally, the queries request component data indicative of an age of the components and analysing the vehicle data for anomalies comprises comparing an age of the components with an age of the vehicle to determine if any of the components have been replaced. This can detect if a component of the vehicle, or a set of components of the vehicle (e.g. the components at the front end of the vehicle) has been replaced since the vehicle was manufactured. Replacement of a set of components may indicate that damage occurred to the vehicle in a collision.

[0019] Optionally, the queries request component data for the plurality of components, wherein the component data is indicative of at least one of origin and age of the components, and analysing the vehicle data for anomalies comprises comparing the component data with external data representing expected component data for the vehicle.

[0020] Optionally, the queries request data indicative of a battery of an electric vehicle (EV) or a hybrid electric vehicle and the vehicle data comprises at least: a first vehicle data value indicating a first expected range of the vehicle as computed by the vehicle; and a plurality of second vehicle data values from the vehicle indicating properties of the battery, and analysing the vehicle data for anomalies comprises: computing a second expected range of the vehicle based on the second vehicle data values; and determining if the first expected range of the vehicle computed by the vehicle is different to the second expected range of the vehicle. This can help to indicate the health of the battery, which may be masked by the computation performed by the vehicle.

[0021] Optionally, computing a second expected range of the vehicle is also based on reference data for a similar battery and vehicle.

[0022] Optionally, computing a second expected range of the vehicle is also based on journey data for the vehicle.

[0023] Optionally, the second vehicle data values comprise historical data for the battery and present data for the battery.

[0024] Optionally, sending queries to request vehicle data indicative of at least one of: total distance travelled; components of the vehicle; safety components of the vehicle; performance or health of a battery of an electric vehicle (EV) or a hybrid electric vehicle.

[0025] Optionally, the method comprises receiving an identifier of the vehicle; and sending queries in a protocol based on the identifier of the vehicle or sending queries to components of the vehicle based on the identifier of the vehicle. For example, the identifier may be used to identify a manufacturer of the vehicle, or a manufacturer (make) and a model of the vehicle, and the queries may be sent in a protocol which is most likely to succeed for that make/model of vehicle. The identifier may be used to identify a manufacturer of the vehicle, or a manufacturer and a model of the vehicle, and components which are known to store a required type of vehicle data (e.g. mileage). Library data may be used to look up the identifier of the vehicle and obtain the manufacturer and model.

[0026] Optionally, sending queries for vehicle data comprises: sending a query for vehicle data to a first component of the vehicle according to a first protocol and; sending a query for the same vehicle data to a second component of the vehicle according to a second protocol which is different to the first protocol.

[0027] Optionally, sending queries for vehicle data comprises: sending a query for vehicle data to a first component of the vehicle according to a first protocol and; sending a query for the same vehicle data to the first component of the vehicle according to a second protocol which is different to the first protocol.

[0028] Optionally, the method comprises addressing the queries to components in the vehicle based on the identifier of the vehicle.

[0029] The method may be performed by a server, or by a group of servers.

[0030] There is provided an apparatus configured to perform the method as described or claimed. There is also provided a system comprising the apparatus. The system may comprise a portable device, called a dongle, which connects to a communications port of a vehicle. In a communication direction towards the vehicle, the portable device is configured to receive, from the server, queries for submitting to the vehicle, or instructions which define queries to be submitted to the vehicle. The portable device is configured to submit the queries to the vehicle. In a communication direction from the vehicle, the portable device is configured to receive responses from the vehicle which comprise vehicle data. The portable device is configured to send the vehicle data (in the form of vehicle data, or the responses comprising the vehicle data) to the server.

[0031] There is provided a computer readable medium having instructions stored thereon which when executed by a processor cause the processor to perform a method as described or claimed.

Brief Description of the Drawings

[0032] The present disclosure will now be described in detail, with reference to the accompanying drawings, in which:

Figure 1 shows an example of a system for verifying the integrity of a vehicle;

Figure 2 shows an example of a communications network within a vehicle;

Figure 3 shows a method for verifying the integrity of a vehicle;

Figure 4 shows an example of verifying the integrity of mileage recorded by a vehicle;

Figure 5 shows an example of verifying the integrity of mileage recorded by a vehicle;

Figure 6 shows an example of verifying the integrity of mechanical or safety components of a vehicle;

Figure 7 shows an example of verifying the integrity of mechanical or safety components of a vehicle;

Figure 8 shows an example of verifying the integrity of components of a vehicle after a warning light;

Figure 9 shows an example of verifying the integrity of a battery of a vehicle;

Figure 10 shows an example of verifying the integrity of a battery of a vehicle;

Figure 11 shows an electronic dongle for use in the system;

Figure 12 shows a portable communications device for use in the system;

Figure 13 shows a computer apparatus for use in the system.

[0033] Like reference numerals are used for like components throughout the description and drawings.

Detailed Description

[0034] Figure 1 shows an example of a system 5 for verifying integrity of a vehicle 10. The vehicle 10 may be a road vehicle in the form of a car, a light goods vehicle or a heavy goods vehicle. Vehicles 10 comprise a digital communications port 15 which is intended for communicating with electronic apparatus within the vehicle. A typical form of communications port 15 provided on a vehicle is an On Board Diagnostics (OBD) port, called OBD2 or OBD-II.

[0035] The main parts of the system 5 are: a portable electronic dongle 20; a portable communications device 30; and at least one server 40.

[0036] A portable electronic dongle 20 connects to the vehicle communications port 15. The dongle 20 interfaces with the electrical pins of the OBD-II port 15. The dongle 20 also communicates with a portable communications device 30. Communication between the dongle 20 and the communications device 30 may be via a short-range personal area network (PAN) 25, using technology such as Bluetooth^™. The dongle 20 comprises a transceiver configured to communicate with the vehicle network and a transceiver configured to communicate with the personal area network 25. The dongle 20 is configured to receive a signal from the PAN and to transmit a signal over the vehicle network. The dongle 20 is configured to receive a signal from the vehicle network and to transmit a signal over the PAN.

[0037] The portable communications device 30 may be in the form of a tablet, smart phone or other portable device. The communications device 30 may have a touch-screen user interface.

[0038] Communication between the portable communications device 30 and the server 40 may be via a wide area network (WAN) 50, such as a cellular communications network (e.g. 3G/LTE/4G/5G). Alternatively, communication between the portable communications device 30 and the server 40 may be via a combination of a local area network (LAN), such as a Wi-Fi network, and a wide area network. The server 40 is configured to store data acquired from the vehicle 10 during the verification. The server 40 may also communicate with other servers 52, 54 which store data for the verification.

[0039] Figure 2 shows an example of a communications network within a vehicle 10. A vehicle comprises a plurality of electronic control units (ECU). This simple example shows three ECUs: ECU_1, 61: ECU_2, 62; ECU_3, 63. A typical vehicle has a larger number of ECUs. A vehicle may have a main (or central) ECU and a plurality of other ECUs which each control a part of the functionality of the vehicle. For example, a vehicle may comprise: an ECU for managing an engine of the vehicle; an ECU for controlling a drivetrain of the vehicle; an ECU for controlling a braking system of the vehicle; an ECU for controlling a fuel system of the vehicle; an ECU for controlling headlights of the vehicle; an ECU for controlling a safety system of the vehicle such as a Supplemental Restraint System (e.g. occupant airbags), and so on.

[0040] The ECUs 61-63 are connected to a wired bus 66 called a Controller Area Network (CAN) bus. The ECUs 61-63 and the CAN bus 66 form an in-vehicle network. ECUs 61-63 are configured to communicate with each other via the CAN bus 66. For example, the ECU which controls the braking system may send data to the ECU which controls the engine. The ECUs are capable of communicating, via the CAN bus 66, with an external device connected to the OBD-II port 15. One or more of the ECUS 61-63 may be connected to a local set of components or devices. Figure 2 shows: ECU_1 connected to components 72 over a bus 71; ECU_2 connected to components 74 over a bus 73; and ECU_3 connected to components 76 over a bus 75. An ECU may communicate with a local set of components/devices using a communication technology which is different to the one used by the CAN bus 66. For example, ECU_2 may represent the ECU which controls the braking system. ECU_2 may connect to an Anti-lock Braking System (ABS) sensor 74 on each wheel. ECU_2 and sensor 74 may communicate using a communications protocol which is different to the one used on the CAN bus 66. A different communications protocol may require messages formatted with a different structure. For example, each protocol may differ in terms of one or more of: message length; number (and type) of fields within a message; length of fields; position of fields within a message; coding type; address length.

[0041] In use, an ECU 61-63 is configured to store data. For example: an ECU which manages a braking system of the vehicle may store a total accumulated number of rotations of each of the wheels; an ECU which manages a fuel system of the vehicle may store a total accumulated volume of fuel used by the engine; an ECU which manages an engine of the vehicle may store a total accumulated time period that the engine has operated since it was manufactured. Other components 72, 74, 76 of the vehicle connected to the ECUs 61-63 may also store data about the components.

[0042] Figure 3 shows an overview of a method for verifying the integrity of a vehicle 10. At block 102 the portable device 30 collects an identifier of the vehicle 10 which is to be investigated. Block 102 may cause the portable device 20 to display a screen requesting a user to manually enter an identifier of the vehicle, such as a Vehicle Registration Mark (VRM) or a Vehicle Identification Number (VIN). In another example, the portable device 30 may comprise a camera and may be configured to obtain an image of a part of the vehicle where the VRM or VIN is located and the server (or software on the portable device 30) may extract the identifier from the image. The VRM and VIN each uniquely identify a vehicle. At block 104, the collected data is sent to the server 40.

[0043] Server 40 may send a summary of a vehicle corresponding to the identifying data to the portable device 30. The summary may indicate a manufacturer and model of the vehicle corresponding to the identifying data. This provides confirmation that the user has entered the correct identifier, or can alert the user that the identifier on the vehicle does not correspond to the recorded data for that identifier. Optionally, the summary data may include an image of a type of vehicle corresponding to the identifying data to ease confirmation that the user has entered the correct identifier.

[0044] The method establishes a communication path between the server 40 and the portable device 30. The communication path between the server 40 and the dongle 20 may be end-to-end encrypted to ensure that data is securely transferred externally of the vehicle 10. The communication path between the server 40 and the dongle 20 may comprise: a communication path between the server 40 and the portable device 30 over a wide area network (WAN); and a communication path between the portable device 30 and the dongle 20 over a personal area network (PAN).

[0045] At block 108 the server 40 determines an initial set of queries for sending to the vehicle 10. The initial set of queries may be based on the type of vehicle. For example, the initial set of queries may be based on one or more of:

a type of propulsion used by the vehicle, e.g. internal combustion engine (ICE) vehicle, electric vehicle (EV), hybrid electric vehicle (HEV);

a manufacturer of the vehicle;

a model of the vehicle;

an age of the vehicle;

a geographic region where the vehicle was intended to be sold;

a preferred network language or protocol;

an anticipated speed of data responses.

[0046] This selection ensures that the vehicle 10 is presented with queries relevant to the vehicle, and that the server obtains useful information about the vehicle. It also helps to reduce the overall amount of querying of the vehicle.

[0047] At block 110 the initial set of initial queries is sent to the vehicle 10. The queries are sent 112 over the communication path to the dongle 20. The dongle 20 formats the queries into a format suitable for transmission to the vehicle OBD-II port. The queries are distributed over the internal network of the vehicle 10. One or more of the queries may be addressed to a particular ECU of the vehicle 10. For example, one of the queries may be addressed to an ECU of the vehicle 10 which controls dashboard data. The server 40 may package the queries in a form such that the dongle 20 can extract the queries and submit them to the vehicle 10. Alternatively, the server 40 may send instructions to the dongle 20 which define each query that is to be submitted to the vehicle.

[0048] At block 116 the server 40 receives responses to the initial set of queries. The responses are sent from ECUs, or other components/devices of the vehicle 10. Initially, these responses are sent over the internal network of the vehicle 10 to the OBD-II port. The dongle 20 translates the responses received via the OBD-II port into a form for transmission to the server 40.

[0049] At block 118 the server 40 determines a further set of queries for sending to the vehicle 10. Block 118 may process responses received from the vehicle to determine the further set of queries. The further set of queries may be based on the responses received at block 116.

[0050] For example, a response to one of the initial queries may indicate that a particular ECU is locally connected to a set of components. Referring again to Figure 2, a response to one of the initial queries may indicate that ECU_2 is responsible for controlling a braking system of the vehicle and is connected to four ABS sensors 74, and list addresses of the ABS sensors 74. Block 118 may process received data to extract the addresses of the wheel sensors 74 and compose a further set of queries which are addressed to one or more of the wheel sensors 74 to extract information held by those sensors.

[0051] At block 120 the further set of queries is sent to the vehicle 10. As before, the queries are sent 122 over the communication path to the dongle 20. The dongle 20 formats the queries into a format suitable for transmission to the vehicle OBD-II port. The queries are distributed over the internal network of the vehicle 10. One or more of the queries may be addressed to a particular ECU of the vehicle 10. One or more of the queries may be addressed to a particular component/device of the vehicle 10. For example, the further set of queries may include queries addressed to one or more of the ABS sensors 74. The queries sent at block 120 may use a different protocol to the initial queries. The queries sent at block 120 may use a protocol which is compatible with a component which is expected to be present on the vehicle. For example, the server 40 may format a query in a protocol which it expects the ABS sensor to use. Multiple queries may be sent to the same component in different formats or according to different communication protocols. For example, the server may send a first query to ABS sensor 74 in a first format/protocol and a second query to the same ABS sensor 74 in a second format/protocol.

[0052] At block 126 the server 40 receives responses to the further set of queries. The responses are sent 124 from ECUs, or other components/devices of the vehicle 10. Initially, these responses are sent over the internal network of the vehicle 10 to the OBD-II port. The dongle 20 translates the responses received via the OBD-II port into a form for transmission to the server 40.

[0053] At block 128 the server processes the responses. Block 128 deciphers vehicle data into a form for subsequent analysis. Optionally, at block 130, at least one received data value is converted from units of one quantity to units of a different quantity, such as from a number of wheel rotations to distance travelled.

[0054] At block 132 the processed data is analysed. There are two main ways in which block 132 may operate. Firstly, block 132 analyses the data obtained from the vehicle 10, or derived from data values obtained from the vehicle. This form of analysis checks that the data held within the vehicle is consistent. Secondly, block 132 analyses vehicle data by comparing it with external data 56 from storage 52, 54. The term "external data" is used in the following description to refer to any data which has not been obtained from the vehicle 10 during the current querying session. This form of analysis checks that the data held within the vehicle 10 is consistent with data stored externally of the vehicle. The external data may be obtained from an external source, such as government organisations, insurance companies or other third party sources. The external may comprise data which has been obtained from other vehicles during other querying sessions. In this way, the server can build a library of useful data for comparison. External data may be stored local to the server 40, or may be obtained from storage which is remote from the server 40.

[0055] At block 134 the method generates an output. The output provides an indication of the integrity of the vehicle data. For example, the output may indicate that, based on the analysis at block 132, the mileage recorded by the odometer is accurate. Alternatively, the output may indicate that, based on the analysis at block 132, the mileage recorded by the odometer may not be accurate. The indication may be provided as a rating in the form of a number (e.g. a percentage of accuracy), a visual scale or any other suitable form to give an indication of integrity. The output may comprise separate indications of integrity of different technical aspects of the vehicle (mileage, components, battery health etc.) The output may comprise a report which is displayed to a user on the portable device 30. The report may also be sent to the user by email or other form of electronic message. The report may be in the form of a scorecard. The report may indicate the most possible likely outcomes for each of the subheadings as displayed on the report.

[0056] Optionally, the method begins with the portable device 30 displaying a log-in screen to gather user credentials. The credentials entered by the user are verified by the server at 104 to register with the server and gain access to the functionality described in Figure 3.

Integrity of recorded mileage

[0057] Figures 4 and 5 show an example of verifying the integrity of mileage recorded by a vehicle 10. Figure 4 shows data stored by the internal network of the vehicle 10, data stored by the server 40, and library/external data.

[0058] In this example, the method obtains data which directly indicates mileage, or distance travelled. ECU_1, 61 of the vehicle stores the odometer mileage 201. This is the numerical value that is displayed to a user on a dashboard of the vehicle. The odometer mileage is the only display of mileage that is readily accessible by a person inspecting the vehicle.

[0059] Additionally, the method obtains secondary data which directly indicates mileage, or distance travelled. In this example, ECU_3, 63 of the vehicle also stores the total mileage 202. Mileage may be stored by a larger number of ECUs or components.

[0060] Additionally, the method obtains data which indirectly indicates mileage, or distance travelled. In this example, the method obtains data about two quantities:

an accumulated number of wheel rotations, 203. ECU_2, 62 stores this data. ECU_2, 62 is an ECU which controls the braking system of the vehicle.

an accumulated volume of fuel, 204. This is a total volume of fuel that the fuel system has used since the car was manufactured. ECU_3, 63 stores this data. ECU_3, 63 is an ECU which controls the fuel system of the vehicle.

[0061] It will be understood that the two quantities described here are examples. There are other quantities which indirectly indicate mileage, and which can be used to determine an estimate of the distance travelled. The quantities which indirectly indicate mileage can be used as a kind of checksum to verify the odometer mileage.

[0062] The method shown in Figure 3 is used to query the vehicle 10. The server 40 determines the presence of ECU_1, ECU_2, ECU_3 and queries these ECUs to determine the data 201-204. Other data, external to the vehicle, can be used to verify the accuracy of the odometer mileage of the vehicle. This includes an external record of mileage values recorded at vehicle inspections 210 or services. Other data used by this method includes conversion data 212 and a library of vehicle data 214.

[0063] Figure 5 shows an example of how the various data is used to verify integrity of the odometer mileage. The odometer mileage 210 directly indicates mileage, but may - or may not - be accurate. The accumulated number of wheel rotations 203 and the accumulated volume of fuel 204 are quantities which indirectly indicate mileage, or distance travelled. Each of the quantities 203, 204 requires conversion into a form in which it can be compared to the odometer mileage 201. The quantities 203, 204 vary proportionally with distance. That is, number of wheel rotations increases with distance travelled and the volume of fuel increases with distance travelled.

[0064] The number of wheel rotations 203 is converted 222 to a distance travelled. Conversion 222 uses data for the vehicle 10. For example, library data 214 indicates a typical tyre size for the vehicle 10. This gives a distance travelled per rotation of the wheel. For example, consider that the library data 214 indicates a vehicle is fitted with tyres having a size 235/35-19, i.e. 235mm tread width, aspect ratio of 35%, and rim diameter of 0.4826 m (19 inches). These tyres have a circumference of 2.03292 m. Therefore, the vehicle travels 2.03292 m per wheel rotation. The total distance travelled is computed by:

[0065] The circumference and distance travelled may vary according to the actual size of the tyre fitted to the vehicle. However, even where the actual size of tyre fitted to a vehicle is different to the recommended size of tyre available from library data 214, the result of the above computation will typically remain within 10% of an expected value.

[0066] It is possible to make use of the actual tyre size if the server 40 has access to this information. For example, a user may visually inspect the tyres of the vehicle and enter the tyre size data at Figure 3, block 102, or the portable device 30 may obtain an image of the data on sidewall of the tyre and the server (or software on the portable device 30) may extract the tyre size from the image.

[0067] The accumulated volume of fuel 204 is converted 224 to a distance travelled. Conversion 224 uses data for the vehicle 10. For example, library data 214 indicates a typical fuel economy of the type of vehicle 10.

[0068] In this example, the analysis module 240 receives four items of vehicle data: an odometer indication 201 of distance travelled; a secondary indication 202 of distance travelled; a first converted value 223 of distance travelled; and a second converted value 225 of distance travelled. There are two main ways in which the analysis module 240 is configured to analyse the data.

[0069] Firstly, the analysis module 240 is configured to analyse the set of data values 201, 202, 223, 225 obtained from the vehicle, or derived from data values obtained from the vehicle (in the case of data values 223, 225). This form of analysis checks that the data held within the vehicle is consistent. In simple terms, does the data stored within the vehicle tell a consistent story?

[0070] Secondly, the analysis module 240 is configured to analyse vehicle data by comparing it with external data. One or more of the set of data values 201, 202, 223, 225 obtained from the vehicle, or derived from data values obtained from the vehicle, is compared with at least one external data value. This form of analysis checks that the data held within the vehicle is consistent with data stored externally of the vehicle. The analysis module 240 comprises a comparison module 242 which is configured to compare data values.

[0071] Data value 201 should be the same as data value 202, as these two data values will typically be derived from the same source. If data value 201 is not equal to data value 202, it indicates that the odometer mileage may be inaccurate. The method may use a larger number of secondary indications 202 of distance travelled, acquired from a larger number of ECUs or other components of the vehicle 10.

[0072] Data value 201 should be close to the converted data values 223 and 225. Data values 223 and 225 will vary from a true value of distance travelled due to the conversions 222, 224. Accuracy of the converted values 223, 225 will vary according to accuracy of the assumptions used in the conversions. Converted data values 223, 225 should lie within a threshold range of data value 201. If one - or both - of the converted data values 223, 225 lie outside the threshold range of data value 201, it provides a stronger indication that the odometer mileage is inaccurate. For example, if a vehicle has an actual mileage of 60,000 km, then it is reasonable to expect the converted data values 223, 225 to lie within a suitable threshold around 60,000 km, such as 59,000 km and 63,000 km. However, if the same vehicle has an odometer mileage of 30,000 km there is a very significant difference between the converted data values 223, 225 and the odometer mileage, which points to tampering. The value of the threshold range may be based on the type of data collected from the vehicle, and the expected accuracy of that type of data. The value of the threshold range may be based on other factors, such as the type of vehicle. For example, some vehicles may be known to detect a quantity with a good or poor accuracy, and this can be allowed for in the conversion to distance travelled.

[0073] In this example, the analysis module 240 receives a further data value 210 in the form of a recorded mileage from an external body (e.g. record of mileage at last MOT inspection). Data value 210 is a historical record of mileage, i.e. acquired at an earlier point in time. Data value 210 is associated with a date at which the mileage was recorded. Data value 210 is compared with the data values 201, 223, 225 obtained from the vehicle. Data value 201 (current odometer mileage) should be more than the externally recorded mileage 210, as it has been recorded more recently than data value 210. If the converted data values 223, 225 lie outside the threshold range of data value 201 (odometer mileage) and if the data value 201 (odometer mileage) is not more the data value 210, it provides an even stronger indication that the odometer mileage is inaccurate.

[0074] The method may obtain a data value 205 from the vehicle which indicates a mileage at which a service interval was reset. This is an operation performed by a technician at the time of completing a maintenance service on the vehicle. If the data value 201 (current odometer mileage) is less than the mileage value 205 at which the service interval was reset, it indicates that the odometer mileage is inaccurate.

[0075] In this example, the output 250 from the analysis module 240 is an indication of an integrity of the odometer mileage 201 based on the comparisons described above.

Integrity of vehicle components

[0076] Figures 6 and 7 show an example of verifying the integrity of components of a vehicle. The components may comprise safety components of a vehicle, such as a component of a Supplemental Restraint System, e.g. an occupant airbag. Other examples of safety components comprise: an airbag sensor; a Light Detection and Ranging (LIDAR) sensor for detecting objects around the vehicle; an adaptive safety controller. The components may comprise electrical or electronic components of the vehicle, or mechanical components which are capable of communicating with an ECU. Examples of electrical/electronic components of the vehicle comprise: an ECU; a headlight; an oxygen (lambda) sensor. Examples of mechanical components which include capability of communicating with an ECU comprise: a gearbox or transmission. The term "component" is intended to generally encompass any component/device/system/sub-system/module/unit of the vehicle.

[0077] Figure 6 shows data stored by the internal network of the vehicle 10, data stored by the server 40, and library data or external data.

[0078] In this example, an occupant airbag 72 is electrically connected via bus 71 to an SRS ECU_1, 61. The occupant airbag 72 stores data which may include a serial number and a build date. The serial number indicates an age and origin of the component 72. The build date indicates an age of the component 72. When an airbag is activated or detonated, that activation is signalled to the SRS ECU_1. The SRS ECU_1 stores data which records the activation event. In ECU_1 this data is stored in a permanent (i.e. non-reversible) manner. The only way to remove this data recording the activation event is to replace the ECU_1. Other ECUs ECU_2, ECU_3 also receive a notification of the activation event and also store data 302, 303 to indicate that an airbag activation event occurred. ECU_2 and ECU_3 store this data along with a change date at which the change of state occurred.

[0079] In this example, the method obtains data from three different ECUS 61-63. Each of the ECUs provides some data which provides an indication of whether an occupant airbag has been activated in the vehicle 10.

[0080] The method shown in Figure 3 is used to query the vehicle 10. The server 40 determines the presence of the SRS ECU ECU_1 and queries ECU_1 to determine the data 301. The server 40 also determines the presence of ECU_2 and ECU_3. The server 40 queries the ECU_2 to determine the data 302, and queries the ECU_3 to determine the data 303. The method may obtain historical data from at least one of the ECUs.

[0081] Other data, external to the vehicle, can also be used to verify the accuracy of the data obtained from the vehicle 10.

[0082] Figure 7 shows an example of how the various data is used to verify integrity of the components within the vehicle 10. In this example, the analysis module 240 receives three sets of vehicle data: data received from (or via) ECU_1, 301; data received from (or via) ECU_2, 302; and data received from (or via) ECU_3, 303. Each of these sets of data 301-303 comprise an indication of whether a particular safety component has been activated. That is, data 301-303 each report about the same safety component 72. The analysis module 240 determines if the indications in data 301-303 are the same. In this example, the ECU_1 data 301 indicates that a safety component has not been activated, but the ECU_2 data 302 and ECU_3 data 303 indicate that a safety component has been activated. This difference between the activation states reported by the ECUs 61-63 indicates that the ECU_1 data may have been altered. The change date of the activation event recorded by data 302, 303 may be compared with other data, such as dates associated with the safety component 72 currently fitted to the vehicle. If available, the serial number and build date of the component 72 may be compared with other data. For example, the build date of component 72 may be compared with a build date of the vehicle. Build date of the vehicle may be obtained from the vehicle itself and/or from external records. If the build date of component 72 is later than the build date of the vehicle, it indicates that the component 76 has been replaced. The serial number obtained from the component 72 may be compared with an external record of serial numbers for components at the time of the build date of the vehicle. If there is an anomaly, it may indicate that the component 76 has been replaced. The analysis module 240 comprises a comparison module 242 which is configured to compare data values.

[0083] Another useful item of data is build date of the SRS ECU, ECU_1. If the build date of ECU_1 is later than the build date of the vehicle, it may indicate that ECU_1 has been replaced to mask a previous activation of airbags in the vehicle.

[0084] In this example, the analysis module 240 receives further data 310, 312, 314 from outside the vehicle. This includes:

vehicle data 310. This may indicate an identifier (e.g. a serial number) of some part of the vehicle, such as a software serial number or a software build number of an ECU or other module within the vehicle which executes software. If data 301-303 differs from the expected vehicle data 310, it may indicate that some data within the vehicle has been altered, and therefore the associated component/device has been compromised;

accident data 312 indicating whether the vehicle has been involved in an accident (e.g. date of accident, date of repair). If accident data 312 indicates that the vehicle has not been involved in an accident, then data 301-303 should correspond to the original build of the vehicle, subject to any parts being replaced for normal wear and tear. If accident data 312 indicates that the vehicle has been involved in an accident, then data 301-303 should indicate that certain components have been replaced, with corresponding build dates or change dates;

recall data 314 indicating any recalls that may affect the vehicle. If a recall has required a certain component to be replaced (e.g. an airbag) then vehicle data 301-303 will be expected to reflect a more recent build date or change date.

[0085] The example described above relates to activation of a safety component. More generally, the method may be applied to other components within the vehicle. A component stores an indication of age, such as build date or serial number. A component which executes software, such as an ECU, includes a build date of the hardware and a build date of the software running on that ECU. The method may collect one or more of these items of data. The method may compare the data values received from the various components of the vehicle 10 with external data, such as expected values, or ranges of values, for build dates or serial numbers of components. For example, the server 40 may identify an expected pattern of build dates or serial numbers for components in vehicles of a particular make, model, built at a particular factory within a particular window of time. If the component data received from a vehicle does not match this expected pattern, it points to an issue with the integrity of the vehicle. As explained above, there are some genuine factors which can cause an anomaly in the expected component data, such as a vehicle which has had components replaced following an accident, or a vehicle which has had a component replaced due to a manufacturer recall. The external data 312, 314 allows the server 40 to identify vehicles which have a genuine reason for an anomaly in the component data.

[0086] In this example, the output 250 from the analysis module 240 is an indication of an integrity of the components based on the comparisons or other analysis described above. That is, the output is an indication of an anomaly in the vehicle data collected for components of the vehicle. The output may comprise an overall indication of integrity of a class of components, such as safety components. Alternatively, the output may comprise an indication of integrity of individual components.

Warning lights

[0087] Many vehicles are configured to activate a warning to a user when a problem or fault is detected with the vehicle. The warning may be in the form of an Engine Management Light (EML) or a Malfunction Indicator Lamp (MIL) on a dashboard of the vehicle. The vehicle may issue the warning when the vehicle determines that there is a problem with the engine, exhaust, or emissions system. The warning light remains illuminated while the vehicle is running, and until the warning light is deactivated. The warning light should be deactivated when the cause of the problem has been rectified. This typically requires a mechanic to replace, or service, a component of the vehicle. The vehicle may be configured to activate other warning lights to warn of a problem with a specific component of the vehicle. The warning is typically displayed as a warning light, but may be displayed as a warning message on a dashboard or other user interface of the vehicle.

[0088] An unscrupulous person may deactivate the warning light without attending to the issue which caused the warning. This masks a problem with the vehicle and can make the vehicle unsafe. One example of a problem which may cause a warning light to be illuminated is a clogged diesel particulate filter (DPF). An unscrupulous person may turn off a DPF warning light without replacing the DPF. This masks the existence of an issue with the DPF and can lead to engine problems or engine failure.

[0089] Figure 8 shows data stored by the internal network of the vehicle 10, data stored by the server 40, and library data or external data.

[0090] In this example, a component (DPF filter) 86 is electrically connected via bus 73 to ECU_2, 62. The component 86 stores data which may include a serial number and a build date. This data indicates an age of the component. In some vehicles, data 88 about component 86 may also be stored by the ECU_2. When the component 86 is replaced, the new component will have a different serial number and, depending on when the component was manufactured, may have a different build date. ECU_2 may store the change of state as change data. In some vehicles, other ECUs ECU_1, ECU_3 may also store data about the change of the component 86.

[0091] The method shown in Figure 3 is used to query the vehicle 10. The server 40 determines the presence of ECU_1, ECU_2, ECU_3 and queries these ECUs to determine the data 331, 332, 333. Other data, external to the vehicle, can also be used to verify the accuracy of the data obtained from the vehicle.

[0092] The warning light data 331 may indicate one or more of: what condition caused a warning light to be activated; when the warning light was activated; when the warning light was deactivated (cleared); distance driven between activation and deactivation of the warning light. ECU_2 and/or ECU_3 may store historical data about the component 86, or data relating to the problem which caused the warning light to be activated.

[0093] The method may obtain data about component 86 from ECU_2, or from the component 86 itself via ECU_2.

[0094] The data acquired during the querying of the vehicle may be used to determine whether a component of the vehicle was replaced at around the time of deactivating (clearing) the warning. The method may determine, based on the warning light data 331 and the component data 332, that the component 86 was replaced at around the time that the warning light was deactivated. The method may also determine how long the vehicle was driven with the warning light activated before the component 86 was replaced. This gives an indication of potential damage to the vehicle.

[0095] The method may determine, based on the warning light data 331 and the component data 332, that the component 86 was not replaced at around the time that the warning light was deactivated. For example, the component data 332 may indicate that the original component 86 is still present in the vehicle. This indicates that a potentially serious problem with the vehicle has been masked. The method may use at least one of the serial number and build date of the component 86, optionally in combination with external data, to determine whether the component 86 was replaced.

[0096] In this example, ECU_2 may only store data about component 86, or ECU_2 and ECU_3 may store data about the same component 86. The method may compare the separate instances sets of data 332, 333 about the same component 86. The separate sets of data 332, 333 should match. If they do not match, it potentially indicates that one of the sets of stored data 332, 333 has been manipulated. For example, an unscrupulous person may deactivate a DPF warning light, and manipulate data 332 to indicate that a new DPF has been fitted to the vehicle. However, the presence of conflicting data 333 with different values indicates that manipulation has occurred.

Integrity of EV battery

[0097] Figures 9 and 10 show an example of verifying the integrity of a battery within an electric vehicle (EV) or a hybrid EV 10.

[0098] Figure 9 shows data stored by the internal network of the vehicle 10, data stored by the server 40, and library data or external data. Vehicle 10 comprises a battery 476 with groups of cells 478. ECU_3, 63 is configured as a battery condition manger. ECU_3 stores data about various properties of the battery 476 and groups of cells 478. ECU_3 may also compute an expected range of the vehicle 10. The expected range calculated by ECU_3 is displayed to a driver of the vehicle 10 on a dashboard of the vehicle 10 and may also be inspected by a prospective purchaser of the vehicle 10. ECU_3 typically uses a proprietary algorithm to calculate the expected range. In use, the expected range may significantly vary according to the manner in which the vehicle has been driven, such as speed or acceleration.

[0099] The method shown in Figure 3 is used to query the vehicle 10. The server 40 determines the presence of the battery condition manager ECU_3 and determines the expected range data 401 as calculated by the vehicle 10. The server 40 also determines data 402 about the battery 476. The server 40 may also determine data 402 about groups of cells 478 within the battery 476. Battery data 402 may comprise present data about the battery and historical data about the battery. For example, the historical data may indicate one or more of: the number of times the battery has been charged; the charging time/type; the maximum voltage after charge; voltage at various points during a discharge cycle; current; temperature readings. Other data, external to the vehicle, can also be used to verify the accuracy of the data obtained from the vehicle. The server 40 may also determine journey data from the vehicle, which is indicative of the conditions under which the battery operated (e.g. speed, acceleration, distance, incline).

[0100] Figure 10 shows an example of how the various data is used to verify integrity of the battery within the vehicle. In this example, the analysis module 240 receives two main items of vehicle data: data 401 from the vehicle indicative of the expected range as calculated by the vehicle; and battery data 402. A computation module 420 computes an expected range of the vehicle based on the current health of the battery. The computation module 420 uses the battery data 402 and may use the journey data from the vehicle to determine the expected range. The computation module 420 may use reference data 410 to determine the expected range, such as reference data 410. The reference data 410 may store battery data and a corresponding expected range for the same type of vehicle as the one currently being verified. The reference data 410 may comprise battery data indicative of a range of different states of battery health, and a corresponding expected range for each state of battery health.

[0101] In one example, the analysis module 240 is configured to compare: (i) the expected range as calculated by the vehicle; and (ii) the expected range as calculated by the server. The analysis module 240 may provide an output which indicates if the expected range, as calculated by the server, is different to the expected range, as calculated by the vehicle. The output may provide an indication of the expected range, as calculated by the server. The output may also provide an indication of the expected range of a new battery obtained from library data.

[0102] In one example, the analysis module 240 is configured to provide an output which indicates the expected range as calculated by the server and an indication of the expected range of a new battery obtained from library data. The analysis module 240 is configured to provide an output which indicates the current battery health relative to an "as new" condition.

[0103] A battery of an EV can be defined in terms of battery heath and battery condition. Firstly, battery health will be considered. Good battery health is reflected by minimal loss between charge cycle influx and retention (e.g. drawing xxx KWh and adding >90% of this to stored capacity). Good battery health is reflected by battery consumption determined as in line with as new energy depletion curves which can be calculated outside of the car based on recent energy consumption vs journey data. Bad battery health may be demonstrated by inefficient charging.

[0104] Secondly, battery condition will be considered. Poor battery condition can determine lower longevity. Poor battery condition will result in less regenerative capacity during journeys which would reflect in range estimates. Good battery condition would be evident in stored capacity retention over time, e.g. how much charge the car loses overnight, or since it was last driven, without any power being drawn by the vehicle. Reconditioning may result in better health and the time it takes for the condition to change from good to fair would indicate poor health or standard variation without deviation.

[0105] Battery life may be expressed as a percentage of capacity held in a state of charge.

[0106] The method may acquire one or more of the following from the vehicle: voltage across cells; voltage depletion under load; temperature anomalies across the battery array; cycle of normal charges; cycle of high power charges; average usage between charges; last journey data.

[0107] The data acquired from the vehicle may be interrogated for degradation and predicted degradation and current depleted maximum capacity. This is more than just state of health determining within the battery. This is aggregate data combining vehicle data pitched against third party data and library data.

[0108] In this example, the output 250 from the analysis module 240 is an indication of an integrity of the vehicle battery based on the comparisons described above.

Machine learning aspects

[0109] The server 40 may be configured to use machine-learning techniques. The server 40 may be configured to learn, over a period of operation, what type of queries work with particular vehicles. The server 40 may be configured to vary the type of queries that are generated (Figure 3, blocks 110, 118) and sent to the vehicle 10 based on the results of previous querying. For example, the server 40 may learn that a particular vehicle has a particular set of ECUs which respond to queries of a particular type. Similarly, the server 40 may learn that a particular vehicle does not respond to queries of a particular type, and therefore learns not to send queries of that type to that type of vehicle. This can reduce the volume of queries that are sent to vehicles 10 in future querying sessions, and thereby reduce the time to acquire useful data from the vehicle. The server 40 may learn the storage locations within a particular vehicle for particular vehicle data. For example, the server 40 may learn that a vehicle of make X and model Y stores mileage data in a particular component.

[0110] The server 40 will, over a period of operation, acquire a volume of new data about vehicles that it has queried. This increased volume of data can be used to improve the querying. The server 40 may be configured to identify, over a period of operation, data patterns in the increased volume of data, which help to verify the integrity of new data acquired from vehicles under test. For example, the server 40 may identify an expected pattern of build dates or serial numbers for components in vehicles of a particular make, model, built at a particular factory within a particular window of time, and intended to be sold in a particular geographic region. This pattern of data can be used for comparison with data acquired from another vehicle. The server 40 may be configured to identify more specific parameters around anticipated values, such as accuracy of a vehicle at recording a number of wheel rotations, or accuracy of a vehicle at recording an odometer mileage. The server 40 may be configured to determine improved parameters for the conversions 222, 224, or improved values for the thresholds used in the comparison module 242.

Hardware

[0111] Figure 11 shows a schematic and simplified representation of a portable electronic dongle 20 for use in the system of Figure 1. The dongle 20 comprises an electrical connector 22 which is configured to connect to a vehicle communications port 15, such as an OBD-II port. The dongle 20 comprises a transceiver 24 configured to communicate with the vehicle network.

[0112] The transceiver 24 may support protocols such as: International Organization for Standardization (ISO) 9141-2; Keyword Protocol 2000 (KWP2000); Society of Automotive Engineers (SAE) J1850 Variable Pulse Width (VPW); SAE J1850 Pulse Width Modulation (PWM); and ISO 15765 Controller Area Network (CAN). The dongle 20 comprises a transceiver 26 configured to communicate with a short-range personal area network (PAN), using technology such as Bluetooth^™. The dongle 20 comprises a processor 28 and a memory 29. In the direction towards the vehicle, the processor 28 is configured to receive an instruction, via the PAN transceiver 26, to issue a query over the vehicle network and then to cause the OBD-II transceiver 24 to issue the query over the vehicle network. In the direction from the vehicle, the processor 28 is configured to receive a response, via the OBD-II transceiver 24, and then to cause the PAN transceiver 26 to send the response over the PAN network.

[0113] Figure 12 shows a schematic and simplified representation of a portable communications device 30 for use in the system of Figure 1. The device 30 comprises a transceiver 32 configured to communicate with a PAN. The device 30 comprises a transceiver 34 configured to communicate with a WAN or a LAN. The device 30 comprises a processor 36 and a memory 37. The device 30 comprises a user-input device 35 and a display device 37. When querying the vehicle, the device 30 forwards messages between transceiver 34 and transceiver 32. When receiving responses to queries, the device 30 forwards messages between transceiver 32 and transceiver 34. The memory 38 stores computer-executable instructions 39 which cause the computer system 600 to perform one or more of the methods described herein. In particular, the computer-executable instructions 39 comprise an application which is configured to communicate with the server 40, and to forward queries from the server 40 to the dongle 20 and responses from the dongle 20 to the server 40. The computer-executable instructions 39 comprise an application which is configured to allow a user to enter an identifier of a vehicle and to receive results of the method performed by the server 40.

[0114] While the described system uses a portable communications device 30, it is also possible to use a fixed communications apparatus in place of the portable communications device 30. For example, the portable communications device 30 could be replaced by a computer terminal with a connection to a LAN or a WAN. While the described system uses wireless communication between the portable communications device 30 and the dongle 20, it is possible to use a wired connection between the portable communications device 30 and the dongle 20, or between a fixed computer terminal and the dongle 20.

[0115] Figure 13 shows a schematic and simplified representation of a computer apparatus 600 which can be used to perform methods described herein, either alone, in combination with other computer apparatuses or as part of a network or a "cloud" computing arrangement.

[0116] The computer apparatus 600 comprises various data processing resources such as a processor 602 (in particular, a hardware processor) coupled to a central bus structure. Also connected to the bus structure are further data processing resources such as memory 604. A display adapter 606 connects a display device 608 to the bus structure. One or more user-input device adapters 610 connect a user-input device 612, such as a keyboard and/or a mouse to the bus structure. One or more communications adapters 614 are also connected to the bus structure to provide connections to other computer systems 600 and other networks.

[0117] In operation, the processor 602 of computer system 600 executes a computer program comprising computer-executable instructions that may be stored in memory 604. When executed, the computer-executable instructions may cause the computer system 600 to perform one or more of the methods described herein. The results of the processing performed may be displayed to a user via the display adapter 606 and display device 608. User inputs for controlling the operation of the computer system 600 may be received via the user-input device adapters 610 from the user-input devices 612.

[0118] While various specific combinations of components and method steps have been described, these are merely examples. Components and method steps may be combined in any suitable arrangement or combination. Components and method steps may also be omitted to leave any suitable combination of components or method steps.

[0119] The described methods may be implemented using computer executable instructions. A computer program product or computer readable medium may comprise or store the computer executable instructions. The computer program product or computer readable medium may comprise a hard disk drive, a flash memory, a read-only memory (ROM), a CD, a DVD, a cache, a random-access memory (RAM) and/or any other storage media in which information is stored for any duration (e.g., for extended time periods, permanently, brief instances, for temporarily buffering, and/or for caching of the information). A computer program may comprise the computer executable instructions. The computer readable medium may be a tangible or non-transitory computer readable medium. The term "computer readable" encompasses "machine readable".

[0120] In an implementation, the modules, components and other features described herein can be implemented as discrete components or integrated in the functionality of hardware components such as ASICS, FPGAs, DSPs or similar devices.

[0121] The singular terms "a" and "an" should not be taken to mean "one and only one". Rather, they should be taken to mean "at least one" or "one or more" unless stated otherwise. The word "comprising" and its derivatives including "comprises" and "comprise" include each of the stated features, but does not exclude the inclusion of one or more further features.

[0122] The above implementations have been described by way of example only, and the described implementations are to be considered in all respects only as illustrative and not restrictive. It will be appreciated that variations of the described implementations may be made without departing from the scope of the disclosure. It will also be apparent that there are many variations that have not been described, but that fall within the scope of the appended claims.

[0123] The present disclosure also includes a number of further examples according to the following numbered clauses:

Clause 1. A method of verifying integrity of a vehicle comprising:

sending queries for vehicle data to a plurality of different components within the vehicle;

receiving vehicle data in response to the queries;

analysing the received vehicle data for anomalies; and

generating an indication of integrity of the vehicle based on the analysing.

Clause 2. The method of clause 1 wherein the queries request vehicle data indicative of a first property of the vehicle, receiving vehicle data comprises receiving a set of vehicle data values comprising at least a first vehicle data value from a first component of the vehicle and a second vehicle data value from a second component of the vehicle, and analysing the vehicle data for anomalies comprises comparing the set of received vehicle data values.

Clause 3. The method of clause 2 wherein analysing the vehicle data for anomalies comprises determining if the set of received vehicle data values are equal, or if the set of received vehicle data lie within a threshold range of each other.

Clause 4. The method of clause 2 or 3 wherein the queries for vehicle data comprise:

a first query for vehicle data sent to a first component of the vehicle, wherein the first query is for vehicle data in the form of a first quantity which is indicative of the first property of the vehicle; and

a second query for vehicle data sent to a second component of the vehicle, wherein the second query is for vehicle data in the form of a second quantity which is also indicative of the first property of the vehicle, wherein the second quantity is different to the first quantity.

Clause 5. The method of clause 4 wherein the receiving comprises:

receiving a first vehicle data value in response to the first query, wherein the first vehicle data value is expressed in units of the first quantity; and

receiving a second vehicle data value in response to the second query, wherein the second vehicle data value is expressed in units of the second quantity,

and the method comprises converting the second vehicle data value from units of the second quantity to units of the first quantity to allow for comparison between the received data values.

Clause 6. The method of clause 5 wherein the first property of the vehicle is distance travelled and the converting (130) comprises at least one of:

converting a received data value expressed in units of a number of wheel rotations to a data value expressed in units of distance travelled;

converting a received data value expressed in units of fuel volume to a data value expressed in units of distance travelled.

Clause 7. The method of clause 5 or 6 wherein the converting uses conversion data based on the vehicle.

Clause 8. The method of any one of clauses 2 to 7 wherein analysing the vehicle data values for anomalies comprises comparing at least one of the vehicle data values, or a data value based on the received vehicle data values, with external data comprising an expected data value for the first property.

Clause 9. The method of clause 8 wherein the external data is a store of at least one of:

vehicle data indicating expected data values for a vehicle;

vehicle data recorded at a periodic vehicle inspection;

vehicle data relating to vehicle accidents;

vehicle data relating to vehicle servicing;

vehicle data relating to vehicle recalls.

Clause 10. The method of any one of clauses 2 to 9 wherein the first property of the vehicle is activation of a safety component of the vehicle and the set of vehicle data values comprises at least:

a first vehicle data value from a first component of the vehicle indicating an activation state of a safety component; and

a second vehicle data value from a second component of the vehicle indicating an activation state of a safety component, and

analysing the vehicle data for anomalies comprises comparing the set of received vehicle data values for an inconsistency in the activation state of the safety component received from the first component and the second component.

Clause 11. The method of any one of the preceding clauses wherein:

the queries request:

warning data indicative of: (i) the vehicle issuing a warning in respect of a problem with the vehicle and (ii) a clearing of the warning; and

component data for a component that requires placement in order to clear the warning,

receiving vehicle data comprises:

receiving the warning data; and

receiving the component data, and

analysing the vehicle data for anomalies comprises determining whether the component data indicates that the component has been replaced.

Clause 12. The method of clause 11 wherein the analysing uses at least one of: a build date of the component and a serial number of the component.

Clause 13. The method of any one of the preceding clauses wherein the queries request component data indicative of an age of the components and analysing the vehicle data for anomalies comprises comparing an age of the components with an age of the vehicle to determine if any of the components have been replaced. Optionally, the method compares component data for a plurality of components of the vehicle with external data indicating expected data values for the same plurality of components.

Clause 14. The method of any one of the preceding clauses wherein the queries request component data for the plurality of components, wherein the component data is indicative of at least one of origin and age of the components, and analysing the vehicle data for anomalies comprises comparing the component data with external data representing expected component data for the vehicle.

Clause 15. The method of any one of the preceding clauses wherein the queries request data indicative of a battery of an electric vehicle (EV) or a hybrid electric vehicle and the vehicle data comprises at least:

a first vehicle data value indicating a first expected range of the vehicle as computed by the vehicle; and

a plurality of second vehicle data values from the vehicle indicating properties of the battery, and

analysing the vehicle data for anomalies comprises:

computing a second expected range of the vehicle based on the second vehicle data values; and

determining if the first expected range of the vehicle computed by the vehicle is different to the second expected range of the vehicle.

Clause 16. The method of clause 15 wherein computing a second expected range of the vehicle is also based on reference data for a similar battery and vehicle.

Clause 17. The method of clause 15 or 16 wherein computing a second expected range of the vehicle is also based on journey data for the vehicle.

Clause 18. The method of any one of clauses 15 to 17 wherein the second vehicle data values comprise historical data for the battery and present data for the battery.

Clause 19. The method of any one of the preceding clauses comprising sending queries to request vehicle data indicative of at least one of:

total distance travelled;

components of the vehicle;

safety components of the vehicle;

performance or health of a battery of an electric vehicle (EV) or a hybrid electric vehicle.

Clause 20. The method of any one of the preceding clauses comprising:

receiving an identifier of the vehicle; and

sending queries in a protocol based on the identifier of the vehicle or sending queries to components of the vehicle based on the identifier of the vehicle.

Clause 21. The method of any one of the preceding clauses wherein sending queries for vehicle data comprises:

sending a query for vehicle data to a first component of the vehicle according to a first protocol and;

sending a query for the same vehicle data to a second component of the vehicle according to a second protocol which is different to the first protocol.

Clause 22. The method of any one of the preceding clauses wherein sending queries for vehicle data comprises:

sending a query for vehicle data to a first component of the vehicle according to a first protocol and;

sending a query for the same vehicle data to the first component of the vehicle according to a second protocol which is different to the first protocol.

Clause 23. The method of any one of clauses 20 to 22 comprising addressing the queries to components in the vehicle based on the identifier of the vehicle.

Clause 24. A method of verifying integrity of a battery of an electric vehicle (EV) or a hybrid electric vehicle comprising:

sending queries for vehicle data to the vehicle, the queries including queries for battery data;

receiving vehicle data in response to the queries, the vehicle data including battery data which comprises data values from the vehicle indicating properties of the battery; and

computing an expected range of the vehicle based on the battery data values and reference data for a similar battery and/or vehicle.

Clause 25. An apparatus configured to perform the method of any one of the preceding clauses.

Clause 26. A computer readable medium having instructions stored thereon which when executed by a processor cause the processor to perform a method according to any of clauses 1 to 24.

Clause 25. A system comprising an apparatus according to clause 23.

Claims

1. A method of verifying integrity of a vehicle (10) comprising:

sending (110) queries for vehicle data to a plurality of different components (61-63, 72, 74, 76) within the vehicle (10);

receiving (116) vehicle data in response to the queries;

analysing (132) the received vehicle data for anomalies; and

generating (134) an indication of integrity of the vehicle (10) based on the analysing.

2. The method of claim 1 wherein the queries request vehicle data indicative of a first property of the vehicle, receiving (116) vehicle data comprises receiving a set of vehicle data values comprising at least a first vehicle data value from a first component of the vehicle and a second vehicle data value from a second component of the vehicle, and analysing (132) the vehicle data for anomalies comprises comparing the set of received vehicle data values.

3. The method of claim 2 wherein analysing (132) the vehicle data for anomalies comprises determining if the set of received vehicle data values are equal, or if the set of received vehicle data lie within a threshold range of each other.

4. The method of claim 2 or 3 wherein the queries for vehicle data comprise:

a first query for vehicle data sent to a first component of the vehicle, wherein the first query is for vehicle data in the form of a first quantity which is indicative of the first property of the vehicle; and

a second query for vehicle data sent to a second component of the vehicle, wherein the second query is for vehicle data in the form of a second quantity which is also indicative of the first property of the vehicle, wherein the second quantity is different to the first quantity.

5. The method of claim 4 wherein the receiving (116) comprises:

receiving a first vehicle data value in response to the first query, wherein the first vehicle data value is expressed in units of the first quantity; and

receiving a second vehicle data value in response to the second query, wherein the second vehicle data value is expressed in units of the second quantity,

and the method comprises converting (130) the second vehicle data value from units of the second quantity to units of the first quantity to allow for comparison between the received data values, and optionally wherein the converting uses conversion data based on the vehicle.

6. The method of claim 5 wherein the first property of the vehicle is distance travelled and the converting (130) comprises at least one of:

converting a received data value expressed in units of a number of wheel rotations to a data value expressed in units of distance travelled;

converting a received data value expressed in units of fuel volume to a data value expressed in units of distance travelled.

7. The method of any one of claims 2 to 6 wherein analysing (132) the vehicle data values for anomalies comprises comparing at least one of the vehicle data values, or a data value based on the received vehicle data values, with external data (56) comprising an expected data value for the first property.

8. The method of any one of claims 2 to 7 wherein the first property of the vehicle is activation of a safety component (72) of the vehicle and the set of vehicle data values comprises at least:

a first vehicle data value (301) from a first component (61) of the vehicle indicating an activation state of a safety component (72); and

a second vehicle data value (302) from a second component (62) of the vehicle indicating an activation state of a safety component (72), and

analysing the vehicle data for anomalies comprises comparing the set of received vehicle data values for an inconsistency in the activation state of the safety component received from the first component (61) and the second component (62).

9. The method of any one of the preceding claims wherein:

the queries request:

warning data (331) indicative of: (i) the vehicle issuing a warning in respect of a problem with the vehicle (10) and (ii) a clearing of the warning; and

component data (87) for a component (86) that requires placement in order to clear the warning,

receiving (116) vehicle data comprises:

receiving the warning data (331); and

receiving the component data (87), and

analysing the vehicle data for anomalies comprises determining whether the component data (87) indicates that the component (86) has been replaced, and optionally wherein the analysing (130) uses at least one of: a build date of the component and a serial number of the component.

10. The method of any one of the preceding claims wherein the queries request component data indicative of an age of the components and analysing the vehicle data for anomalies comprises comparing an age of the components with an age of the vehicle to determine if any of the components have been replaced.

11. The method of any one of the preceding claims wherein the queries request data indicative of a battery (476) of an electric vehicle (EV) or a hybrid electric vehicle and the vehicle data comprises at least:

a first vehicle data value (401) indicating a first expected range of the vehicle (10) as computed by the vehicle; and

a plurality of second vehicle data values (402) from the vehicle indicating properties of the battery (476), and

analysing the vehicle data for anomalies comprises:

computing a second expected range of the vehicle based on the second vehicle data values; and

determining if the first expected range of the vehicle computed by the vehicle is different to the second expected range of the vehicle.

12. The method of any one of the preceding claims comprising:

receiving an identifier of the vehicle (10); and

sending queries in a protocol based on the identifier of the vehicle or sending queries to components of the vehicle based on the identifier of the vehicle.

13. The method of any one of the preceding claims wherein sending (110) queries for vehicle data comprises:

sending a query for vehicle data to a first component of the vehicle according to a first protocol and;

sending a query for the same vehicle data to a second component of the vehicle according to a second protocol which is different to the first protocol.

14. An apparatus configured to perform the method of any one of the preceding claims.

15. A computer readable medium having instructions stored thereon which when executed by a processor cause the processor to perform a method according to any of claims 1 to 13.

Drawing