GB2565147A

GB2565147A - Intelligent vehicle parts

Info

Publication number: GB2565147A
Application number: GB1712585.7A
Authority: GB
Inventors: Kashif Chaudhry Mohammed; Saleem Omer; Anisur Rahman Syed; Ahmed Kabir; Clemente López Ruiz Juan
Original assignee: Carolfile Ltd
Current assignee: Carolfile Ltd
Priority date: 2017-08-04
Filing date: 2017-08-04
Publication date: 2019-02-06
Also published as: GB201712585D0

Abstract

A system for identifying and verifying a vehicle 101 intelligent part 102 comprising an identification device 104 configured to retrieve data, including an identifier, stored on a vehicle part, and vehicle data, including a vehicle identifier indicating the vehicle onto which the part is installed, and send the data to an analysis server 105; and a server which receives the data and associates it in a database for later retrieval. The intelligent part may comprise data storage and means for transmitting data to the identification device, and may comprise a processor and long-range wireless communication module. The part may monitor usage of the part and update part data stored on the part. The part may identify the vehicle it is installed in, determine if the part is suitable for installation and disable the part if it is not. The part may alter part operation based on part data. The analysis server may send an instruction to the identification device to disable the vehicle or part or both. A smart tag with data storage and transmission means may be attached to a vehicle part to make it intelligent. Also claimed is a method for identifying verifying a vehicle part as above.

Description

In a typical automobile installation and maintenance ecosystem, parts are installed in vehicles and tracked and managed through part numbers, batch numbers and serial numbers that are printed on the part and in accompanying material. Installers, such as manufacturers or mechanics, use this information to identify parts that are needed for each vehicle and install them. A typical ecosystem includes manufacturer/salesman, user and repair/maintenance providers. To identify the part installed in a vehicle a record must be kept which is typically manually entered.

For a vehicle user to identify those parts currently installed in their vehicle, a user must remove the part, identify the printed information and consult a master database using the printed information. Typically users do not have access to the part or the master database making it impossible for the vehicle user to identify the part installed. This facilitates untrustworthy activity by mechanics such as the installation of counterfeit parts or the installation of pre-used parts.

In the vehicle itself, data on parts installed is often provided to the vehicle control unit through external sensors spread throughout the vehicle. This information is usually limited to the working status of a part. Vehicle engine management systems use this information to manage vehicle operations and report faults back to the user, for example with a malfunction indicator light located on the dashboard of the vehicle. More sophisticated systems utilise an on-board diagnostics (OBD) capability. OBD systems give the vehicle owner or repair technician access to the status of the various vehicle subsystems. Real-time data can be provided with a standardised series of diagnostic trouble codes (DTCs) which allow one to rapidly identify and remedy malfunctions within the vehicle. The data is sent to and from the vehicle’s on-board computer and typically provided to external equipment using a standardised diagnostic interface.

There exists various differing systems, utilising a vehicle’s engine management system, to report faults and diagnostics detected in the vehicle however the vehicle ecosystem does not provide any means to track and manage the vehicle parts and operations.

In the existing vehicle installation and maintenance ecosystem, knowledge of vehicle status and part installation history remains with each entity of the ecosystem such that the user or consumer does not have access to information regarding the equipment they may own and there exists no facility to share information throughout the ecosystem.

SUMMARY OF THE INVENTION

The present invention relates to a system and method for managing and tracking parts within a vehicle, including for example automotive vehicles, marine vehicles or aircraft.

In a first aspect of the invention, there is provided a system for identifying and verifying a vehicle part, the system comprising an identification device. The identification device is configured to: retrieve part data stored on an intelligent vehicle part, the part data including a part identifier; retrieve vehicle data, the vehicle data including a vehicle identifier indicative of the vehicle in which the part is installed; and, send the part data and vehicle data to an analysis server. The analysis server is configured to: receive the part data and the vehicle data; and, associate the part data and the vehicle data in a database for subsequent retrieval.

The invention provides the capability for a part, a vehicle and external systems to understand various dataset information points about the part. A user, installer or other interested party is able to quickly and easily identify, track and manage those parts installed in a particular vehicle in a manner that has previously been impossible. Users are able to have knowledge of the parts installed without removing them or keeping a record of their installation.

By centrally keeping a record of the installed parts, subsequent analysis and notification is facilitated. Commercial advantages such as the notification to users of the availability of improved or upgraded parts can be facilitated by making the data available to trusted members of the wider vehicle ecosystem.

The part data may include one or more identifiers selected from a group comprising: part type; part number; serial number; batch number; fault information; manufacturer; a vehicle identifier indicative of the vehicle in which the vehicle part is installed; related installed parts information; history information; usage information; log information; life span; installation date; signed security token; and, installation agent information. Accordingly the system is able to identify and distribute useful part data to facilitate further analysis and further use cases. The benefits of the analysis include performance analysis of installed parts by the manufacturer, such as to test long term performance of the part or to influence service regimes. Users are further able to plan or predict the service requirements of vehicles which is especially useful for people operating fleets of vehicles.

Preferably, the system comprises an intelligent part configured for installation in the vehicle, the part comprising: data storage storing part data including a signed part identifier; and, means for transmitting the part data to the identification device.

The intelligent vehicle part may comprise a processor and a long-range wireless communication module. The wireless communication module may be configured to transmit data to the identification device using, for example GSM, Wi-Fi, Bluetooth or Zigbee. In this way the intelligent vehicle part may be able to communicate with a remote device to share its information and update its stored data. Such long-range communication may facilitate communication between parts and a central network.

Preferably the intelligent vehicle part is configured to monitor usage of the intelligent vehicle part and update the stored part data accordingly. In this way the user is able to identify the usage of the part quickly and easily in a manner not previously possible. The user is able to identify if the part should be replaced improving the safety, efficiency and reliability of the vehicle by consulting the analysis server to which the usage data has been sent. The usage data may be accessible on a customer device to facilitate access. Once the usage data is available on an analysis server, further analytic options are presented to enable further commercial models such as statistical analysis or wear detection or safety or recall notification.

In certain embodiments, the intelligent vehicle part may be configured to identify the vehicle in which it is installed and determine that the part is suitable for installation in the vehicle and, if the part is not suitable, disable the part. Accordingly, the safety of the vehicle is improved.

Additionally, the intelligent vehicle part may be configured to alter part operation based on the stored part data. By analysing the part data received, the safety, efficiency or durability of the vehicle may be improved.

In certain alternative embodiments the intelligent vehicle part and identification device part may be configured to communicate using NFC or RFID. Such passive communication allows for parts to communicate stored data without requiring a local power source. In addition, the identification device is able to securely interrogate and update the stored data from a short range.

The system may further comprise sensors configured to monitor usage of the part and send usage information to the identification device or the intelligent vehicle part, or both. The vehicle communication may therefore be improved and improved usage may be calculated to improve the user experience and safety and efficiency of the vehicle.

Preferably the identification device may be an on-board diagnostic device (OBD), the identification device being configured to be connected to an OBD port of the vehicle. The OBD provides for power for the identification device, provides for communication to the engine control unit and also a centralised secure location within the vehicle in which the identification device can easily communicate with the intelligent vehicle part wherever it is placed within the vehicle.

More preferably the identification device may be configured to retrieve vehicle data and send the vehicle data to the intelligent vehicle part to update the part data stored on the intelligent vehicle part. The vehicle data may be retrieved for example from the ODB capability and may enable the part to keep track of where it has been installed or any faults created in the vehicle, for example.

The vehicle data may include one or more selected from a group comprising: vehicle fault information indicative of a fault with the vehicle; part fault information indicative of a fault with the intelligent vehicle part; related part information; and, a vehicle identifier indicative of the vehicle in which the part is installed.

Even more preferably the identification device may be configured to receive one or more fault codes from an engine control unit and send the fault code to the analysis server. In this way the vehicle ecosystem can be notified of any faults within the vehicle and associate that fault with a particular part installed and not simply the type of part that has caused a fault. By identifying the actual part installed, easy fault rectification can be easily identified together with other beneficial analysis depending on the circumstances such as the installer of the part or the batch the part was from or myriad commercial models. The fault code and part data may be associated in the database.

The identification device may be further configured to send the one or more fault codes to the intelligent vehicle part. The intelligent vehicle part may thus be able to store the fault for future analysis or interrogation by external systems. If the intelligent vehicle part includes an active component, it may be able to disable or limit its operations, as above.

Advantageously the identification device and intelligent vehicle part may be configured to communicate using one or more security tokens stored on the intelligent vehicle part. Accordingly, only trusted identification devices are able to interrogate the information on the intelligent vehicle part keeping the intelligent vehicle part data secure and limiting the opportunity for untrustworthy individuals to update or modify the part data.

In certain embodiments the analysis server may be configured to check the part identifier against a list of approved parts to identify if the part is counterfeit. Thus a counterfeit part can be identified before its installation causes safety issues within the vehicle. Furthermore the system can detect parts installed in the car by querying the signed security token which can only be decrypted through trusted devices and components included the analysis server, applications and OBD devices. In such events the system may decide to alter the operations (including disabling the part) to prevent vehicle damage or safety issues.

It will be understood that the term counterfeit may refer to parts not produced or approved by vehicle manufacturer or service personnel.

In certain embodiments the analysis server may be configured to forward the part data and the vehicle data to a customer device. The user may therefore be able to identify the part installed quickly and easily from their personal device such as a smartphone, tablet or PC or operating system interface installed within the vehicle. For example, the analysis server could send information to the vehicle’s display or the dashboard panel to be displayed to the user when they are in or using the vehicle.

The analysis server may be configured to determine if the part data or the vehicle data indicates a fault, and subsequently notify the customer. The customer can accordingly seek advice or take action based on the fault notification. The notification may be sent to a service station or manufacturer.

The analysis server may additionally be configured to check the part identifier against a database of part identifiers and determine if the part is suitable for installation in the vehicle and, if the part is not suitable, notify the customer. The customer can accordingly seek advice or take action based on the fault notification. The notification may be sent to a service station or manufacturer.

The analysis server may also be configured to send an instruction to the identification device to disable the vehicle or part or both. In extreme circumstances where safety may be an issue, the remote server may be able to prevent the part or vehicle from operating.

Parts are able to receive information either directly or indirectly via the OBD on related parts within the vehicles eco-system. This allows the parts to modify their behaviour based on the vehicles eco-system. One example being high performance parts being installed in the vehicle. Parts detect other high performance components allowing them to change their operating parameters to match the capabilities and efficiencies of the vehicles ecosystem improving efficiency and performance.

The part data may include usage information and the analysis server may be configured to determine, based on the part data, if the part has reached or exceeded the recommended usage. In this way elements of the vehicle ecosystem can take action based on the part exceeding its usage such as notification, or replacement.

In a further aspect there may be provided an identification device configured for use in a system according to the first aspect. In a further aspect there may be provided an analysis server configured for use in a system according to the first aspect.

In a further aspect there may be provided a smart tag configured to be attached to a vehicle part, the tag comprising data storage and a transmission means, such that when the tag is attached to the vehicle part, the vehicle part becomes an intelligent vehicle part suitable for use in a system according to the first aspect.

In a further aspect of the invention there may be provided a method for identifying and verifying a vehicle part, the method comprising: retrieving part data stored on an intelligent vehicle part, the part data including a part identifier; retrieving vehicle data, the vehicle data including a vehicle identifier indicative of the vehicle in which the part is installed; and, associating the part data and the vehicle data in a database for subsequent retrieval.

According to this aspect, the part data may include one or more identifiers selected from a group comprising: part type; part number; serial number; batch number; fault information; manufacturer; a vehicle identifier indicative of the vehicle in which the vehicle part is installed; related installed parts information; history information; usage information; log information; life span; installation date; a signed security token; and, installation agent information.

The method may further comprise monitoring usage of the intelligent vehicle part and updating the stored part data accordingly.

The method may further comprise identifying the vehicle in which the intelligent vehicle part is installed and determining that the part is suitable for installation in the vehicle and, if the part is not suitable, disabling the part.

The method may further comprise altering part operation based on the stored part data.

The method may further comprise monitoring usage of the intelligent vehicle part and sending usage information to a customer device, vehicle device or the intelligent vehicle part, or both.

The method may further comprise retrieving vehicle data and updating the part data stored on the intelligent vehicle part.

According to this aspect, the vehicle data may include one or more selected from a group comprising: vehicle fault information indicative of a fault with the vehicle; part fault information indicative of a fault with the intelligent vehicle part; related part information; and, a vehicle identifier indicative of the vehicle in which the part is installed.

The method may further comprise receiving one or more fault codes and associating the fault code and part data in the database.

The method may further comprise updating the stored part data with the one or more fault codes.

The method may further comprise authenticating the intelligent vehicle part using one or more security tokens stored on the intelligent vehicle part.

The method may further comprise checking the part identifier against a list of approved parts to identify if the part is counterfeit.

The method may further comprise forwarding the part data and the vehicle data to a customer device.

The method may further comprise determining if the part data or the vehicle data indicates a fault, and subsequently notifying the customer.

The method may further comprise checking the part identifier against a database of part identifiers and determining if the part is suitable for installation in the vehicle and, if the part is not suitable, notifying the customer.

The method may further comprise disabling the vehicle or part or both.

According to this aspect, the part data may include usage information and the method may further comprise determining, based on the part data, if the part has reached or exceeded the recommended usage.

DETAILED DESCRIPTION

Examples of systems and methods in accordance with the invention will now be described with reference to the accompanying drawings, in which:Figure 1 shows a high-level architectural diagram of a first example system according to the present invention;

Figure 2 shows a flow diagram of an example embodiment according to the present invention;

Figure 3 shows a flow diagram of an example embodiment according to the present invention;

Figure 4 shows a flow diagram of an example embodiment according to the present invention;

Figure 5 shows a high-level architectural diagram of a second example system according to the present invention;

Figure 6 shows a flow diagram of an example embodiment according to the present invention;

Figure 7 shows a flow diagram of an example embodiment according to the present invention; and,

Figure 8 shows a flow diagram of an example embodiment according to the present invention.

As indicated above, embodiments of the present invention relate to a system and method for managing and tracking parts within a vehicle such as automotive, marine or aircraft. Embodiments provide for the capability for a part, vehicle and external system to understand various dataset information points stored on the part. For example, part numbers, manufacture information, serial number, batch numbers or more intelligent and dynamic information such as installation history, status, current usage, faults and lifespan. The part itself may be intelligent and manage itself based on dataset information provided to it through a vehicle and/or other external systems. The part may have the capability to optimise its operating parameters or disable itself based on given rules or instruction sets that can be pre-embedded or submitted securely through external interfaces.

Parts are identified, tracked and managed through a direct connection with the vehicle, external systems or through other indirect interfaces, such as an onboard diagnostics (OBD) device. In further embodiments, improvements may be provided in safety, part statistics, efficiency, economic benefit, identification and genuine, generic or counterfeit parts.

The invention provides a system that allows parts to be intelligent and given the capabilities to self-manage, automatically report faults without the need of the vehicles engine management system, and be managed and tracked independently.

The system also allows for standard/non-intelligent parts to be tracked and managed through aftermarket stickers added to parts, such as NFC or RFID tags.

Specific examples of the present invention will now be described. It will be understood that these are specific, non-limiting examples only. In the following description, two examples are given in which a vehicle part may be provided with either a passive tag or an active module. In both examples, features described may be utilised interchangeably in both exemplary systems, however for simplicity and brevity, it will be understood that certain functionality may not be repeated between each example but may be contemplated nevertheless.

Figure 1 illustrates an architectural view of an example system. The vehicle 101 is equipped with a part 102. Any part equipped into a vehicle is contemplated within the scope of this solution however, for the sake of example, the part may be a sparkplug or headlamp, etc. The part 102 may be equipped with a passive tag 103. The tag 103 may be programmed and attached to the part by a trusted agent with static information such as a part number, serial number, batch number, manufacturer, security token and lifespan.

Illustrated in Figure 1 is a computational device 104 connected to the on-board diagnostics (OBD) diagnostic connector. Most modem vehicles include a standardised interface which provides for power together with a standardised interface to the vehicle control system. In this way, a processing device 104 connected to the OBD connector can communicate with the vehicle control unit and receive appropriate power. Throughout the following description, the processing device connected to the OBD connector may be referred to as an OBD device. The OBD device may include the processor, memory and suitable wireless communication module.

Methods and processes described herein can be embodied as code e.g. software code and/or data. Such code and data can be stored on one or more computer-readable media, which may include any device or medium that can store code and/or data for use by the computer system. When a computer system reads and executes the code and/or data stored on a computer-readable medium, the computer system performs the method and processes embodied as data structures and code stored within the computer-readable storage medium. In certain embodiments, one or more of the steps of the methods and processors described herein can be performed by a processor (e.g. a processor of a computer system or data storage system). It should be appreciated by those skilled in the art that computer-readable media include removable and non-removable structures/devices that can be used for storage of information, such as computer-readable instructions, data structures, program modules, and other data used by computing system/environments. A computer-readable medium includes, but is not limited to, volatile memory such as random access memories (RAM, DRAM, SRAM); and non-volatile memory such as flash memory, various read-only memories (ROM, PROM, EPROM, EEPROM), magnetic and ferromagnetic/ferroelectric memories (MRAM, FERAM) and magnetic and optical storage device (hard drives, magnetic tape, CDs, DVDs); network devices; or other media now known or later developed that is capable of storing computer-readable information/data. Computer-readable media should not be construed or interrupted to include any propagating signals. The computer programme may include a suitable operating system upon which the program to enable the present functionality may be executed.

Returning now to Figure 1, the OBD device may communicate with the intelligent part 102 by transmitting a radio frequency signal and reading the data stored on the tag 103 accordingly. It will be understood that any passive short range communication may be utilised for the OBD device 104 to communicate with the intelligent part 102. Also illustrated in the high level architecture of Figure 1 is a cloud server 105 in communication with the OBD device 104. The cloud server 105 may include a database to store the data retrieved from the OBD device 104. The OBD device 104 may communicate with the cloud server 105 using an intermediary such as a mobile device or using any suitable long range communication such as GSM or Wi-Fi.

Communications between the OBD device 104 and the smart tag 103 may be managed securely using a security token stored on the tag. Authenticity and data exchange is therefore secured and inadvertent or unsecure data retrieval is prevented.

A series of user journeys will now be described with reference to Figures 2 to 4 which illustrate a series of steps within the flows of each illustrated swim-lane.

A first example of Figure 2 illustrates how a system is able to passively track a part and detect if the part is counterfeit. From top to bottom of the figure, the swim-lanes illustrated are: the customer equipped with a mobile application on, for example, a smartphone device; the connected OBD device, that is the processor unit described above connected to the OBD connector of a vehicle and equipped with the wireless communications module; the intelligent vehicle part, equipped with a passive tag or sticker; a cloud or analysis server; and, an installer, for example a manufacturer or a trusted agent.

First, the installer programs the tag or sticker for the part (step 201). The tag or sticker may be programmed with such data as the part number, serial number, batch number, manufacturer, a security token, or an installation date for example. The installer subsequently attaches the tag or sticker to the part (step 202). The installer may optionally send this data to the cloud server to indicate which sticker and part have been associated together (step 203). Next, the part is installed into the vehicle (step 204).

In parallel, the installed OBD device detects that it has been installed in a vehicle (or is optionally triggered to do so) and registers the vehicle information on the OBD device (step 205).

Optionally, the customer device may be updated with the vehicle details as received from the OBD device (step 206). The information may be sent via any suitable long range communication protocol such as RF, Bluetooth or GSM. Rather than updating the mobile device directly, the OBD device may update the mobile device via the cloud server as an intermediary (not shown).

Once the part has been installed into the vehicle, the OBD device may transmit an RF signal and may accordingly be able to read the data from the installed tag/sticker (step 208). In other words, the tag/sticker may send details of the part to which it is attached to the OBD device. This means of transmission and data sharing is well known to anyone familiar with RFID technology. The OBD device accordingly receives details of the part (step 209). The OBD device is then able to send details of the parts to the cloud server (step 210a). Optionally, the OBD device may send details of the part directly to the customer device so that the customer may be able to see which parts have been installed in the vehicle (step 210b, 211). If the OBD device has sent the part details to the cloud server then the cloud server may optionally then send the details to the customer device rather than the OBD device (step 212).

When the cloud server has received information regarding the part installed by associated tag as well as the vehicle on which it is installed, the cloud server may be able to identify if the part installed is genuine or used. To do so the cloud server may consult a manufacture database or a usage database (step 213). Depending upon the outcome, the cloud server may transmit a notification to the customer of the counterfeit status or of the usage information. This may be via a direct communication to a mobile app on the customer device which may be updated with details or via other notification means such as email, SMS or post (step 214). Optionally, the cloud server may transmit a notification to the connected OBD device (step 215) which may accordingly, notify the vehicle engine control unit or other vehicle control units, connected systems or components so that a decision can be made on whether to allow the part to function (step 216). Advantageously, the vehicle may disable or reduce function to the control device to maintain vehicle and passenger safety. The OBD device may notify the customer rather than the cloud server (step 217).

As will be evident, the system provides the capability for an external system to understand information regarding the part installed. A counterfeit, generic or part from a faulty batch is detected, external systems, mobile applications, vehicle or OBD device may decide to change parts operation settings or disable the part.

Figure 3 illustrates an example of how the described system can function to detect faults utilising a passive tag or sticker. In the above example, the OBD device and cloud server have received information which has enabled them to associate the part with the vehicle. That is, the details of the part associated with the tag or sticker were received by the OBD device using RF technology and transmitted to the cloud server. In this example, the bottom swim lane is no longer the installer but this time is the vehicle engine control unit. Upon receipt of notification of a part fault, the ECU provides the fault codes via the OBD connector to an installed OBD device (step 301, 302). The OBD device is then able to send the received fault codes to a cloud server (step 303). The cloud server is able to identify the part related to the fault by consulting a database (step 304). The cloud server is then optionally able to send details of the faulty part to the customer device (step 305, 306). The cloud server may be subsequently updated with the part details (step 307).

The OBD receives details of the part by interrogating the tag or sticker, or optionally from the cloud server now the ecosystem is aware of the information (step 308). The OBD device may notify the engine control unit or other systems and components (step 309). Optionally, the OBD device may update the customer rather than the cloud server (step 310). In this way, the customer and an engineer may be able to easily retrieve detailed information on the part that has been installed on a vehicle and which is generating a fault determined by the ECU.

Conventionally, the ECU will only be able to determine which part of the vehicle is faulty and generate an appropriate diagnostic code. The OBD device and cloud server of the exemplary system are operable to identify further information regarding the part and accordingly provide that to the customer and/or engineer. Previously, only the type of part was identifiable and the specifics of the actual part installed.

Figure 3 further illustrates that the OBD device may send details of the fault via RF in order to update the tag/sticker with the details of the fault (step 311, 312). In this way, when subsequently retrieved from the vehicle or at any other point, a scan of the passive tag will identify that the part may be faulty. As with the counterfeit example above, if the part is in fact found to be faulty, the OBD device or ECU may decide to disable or limit functionality of the part or vehicle in order to maintain vehicle safety and/or efficiency.

Figure 4 illustrates another example in which the system can be utilised to improve vehicle user experience. In this example, part usage is able to be monitored, tracked and managed utilising a passive tag or sticker attached to the part. First, the part is activated and used (step 401). An example part may for example be a starter motor. A sensor installed in the vehicle may detect usage of the part (step 402). The connected sensor replaces the installer and the ECU on the bottom swim lane of Figure 4 when compared to Figures 2 and 3.

The sensor detects usage of a sensor (step 402) and may optionally update the tag/sticker with usage details using RF (step 404). Preferably, however, the sensor may send details of usage to an installed OBD device (step 403). The OBD device receives the usage information from the sensor (step 405) and sends the usage information together with information on the part itself to the cloud server (step 407). The tag/sticker is subsequently updated with usage details by the OBD device using RF technology in the manner described above and is known to one familiar with NFC or RFID technology (steps 409, 410). Accordingly, the usage of a part may be subsequently retrieved even though the part may no longer to be installed within a vehicle or retrieved by any external system once appropriate security procedures have been navigated.

As with previous examples, the part details may be sent separately to the usage data. Optionally the OBD device may transmit usage data directly to the customer device and/or mobile application on the customer device (step 408). This may be dependent on proximity to the vehicle, for example.

Upon receipt of the usage information, the cloud sever may query the database to check if the part has reached its lifetime use (step 411). The usage information may be sent to the customer device or the customer in general together with an indication of expiry (step 412, 413). Further, the vehicle may decide to modify operation of, or disable, a part if an NFC or RFID tag reports usage limits or lifespan limit exceeded. To do so, the OBD device may interrogate the tag/sticker and report this to the ECU or the ECU may interrogate the tag/sticker directly.

The following is summary of several optional features that may be identified from the above exemplary systems of Figures 1 to 4 —

- An NFC and RFID tag can be powered through passive power sources.

- NFC and RFID tags store information such as (not exclusively), part number, serial number, batch number, manufacturer, security token, the vehicle it is connected to, history, usage and lifespan.

- NFC and RFID tags are programmed and attached to the part by a trusted agent with static information such as part number, serial number, batch number, manufacturer, security token and lifespan.

- Dynamic information such as ‘vehicle connected to’ and usage may be sent to the NFC or RFID tag via an external system, mobile application, vehicle or OBD device.

- NFC and RFID tags interface with the vehicle through direct or indirect connections such based on capabilities of power source.

- Parts with an NFC and RFID tag can also interface with an OBD device.

- Parts with an NFC and RFID tag authenticity and data exchange is managed securely using the security token stored on the part.

- When a part with an NFC or RFID tag is installed the part is notified what vehicle it has been installed in through direct or indirect connection (e.g. OBD device). This information is stored on the NFC or RFID tag. A log and history of installation is maintained on the NFC and RFID tag.

- Each time a part is used, the RFID or NFC tag is updated with usage information through direct or indirect connection (e.g. OBD device) with the vehicle.

- External systems, mobile applications, OBD devices or the vehicle can query the NFC tag to identify information such as (not exclusively) authenticity and usage. External systems, mobile applications, OBD devices or the vehicle may decide to perform actions based on the information such as disable the part.

- When the vehicle detects a fault it updates the NFC or RFID tag with fault information.

- The vehicle may decide to modify operation or disable a part if an NFC or RFID tag reports usage limit or lifespan limit exceeded

- If a counterfeit, generic or part from a faulty batch is detected, external systems, mobile applications, vehicle or OBD device may decide to change the part operation settings or disable the part.

Above it has been described how an intelligent vehicle part may be achieved by attaching a passive NFC or RFID tag attached to a part installed on the vehicle. Figure 5 illustrates a high level architectural diagram of a system in which the part 102 installed in a vehicle 101 is provided with an active CPU module 503. The active intelligent module, together with the part 102, provides an intelligent vehicle part.

The part may be embedded with hardware and software that provides the part with the capability to update information about themselves such as for example, part number, serial number, batch number, manufacturer, security token, vehicle information, history, usage, fault detection and lifespan. Part information such as part number, serial number, manufacturer, manufacturing date, batch number, lifespan and security token may be pre-embedded at the manufacturing stage or at another point by a trusted agent. The embedded hardware and software interface with a vehicle or OBD device 104 through direct or indirect connection such as radio interfaces (GSM, Wi-Fi, Bluetooth, Zigbee etc.).

Communications between the module 503 and the OBD device 104, or other external system, may be managed securely using a security token stored on the part.

Figures 2 to 4 illustrated, respectively, a user journey for part tracking and counterfeit part detection, part fault detection and part usage monitoring. Corresponding flows are illustrated in Figures 6 to 8 for an active part 102 which is provided with a power source and a CPU 503. The module 503 may be powered by a battery or a suitable power source. The CPU may comprise all suitable functionality to effect the functionality described such as any suitable combination of hardware and software.

Figure 6 illustrates how a system is able to track a part and detect if the part is counterfeit. From top to bottom of the figure, the swim-lanes illustrated are: the customer equipped with a mobile application on, for example, a smartphone device; the connected OBD device, that is the processor unit described above connected to the OBD connector of a vehicle and equipped with the wireless communications module; the intelligent vehicle part, equipped with a CPU; a cloud or analysis server; and, an installer, for example a manufacturer or a trusted agent.

First, the installer programs the CPU module for the part (step 601). The part may be programmed with such data as the part number, serial number, batch number, manufacturer, a security token, or an installation date for example. The installer subsequently associates the CPU module with the part (step 602). The installer may optionally send this data to the cloud server to update the data stored thereon (step 603). Next, the part is installed into the vehicle (step 604).

In parallel, the installed OBD device detects that it has been installed in a vehicle (or is optionally triggered to do so) and registers the vehicle information on the OBD device (step 605).

Optionally, the customer device may be updated with the vehicle details as received from the OBD device (step 606). The information may be sent via any suitable long range communication protocol such as RF, Bluetooth or GSM. Rather than updating the mobile device directly, the OBD device may update the mobile device via the cloud server as an intermediary (not shown).

Once the part has been installed into the vehicle, the active part may send details of the part to the OBD device and/or cloud server. The OBD device and cloud server may receive and store the data received (step 608a, 608b). Optionally, the OBD may transmit the received data to the cloud server rather than the intelligent part itself (step 610a). Similarly, the OBD may transmit the data to the customer device (step 610b) where it may be presented to the user (step 611) or this may be performed by the cloud server (step 612). In sum, the active part may transmit its details to the ecosystem for subsequent analysis and user presentation.

When the cloud server has received information regarding the part installed as well as the vehicle on which it is installed, the cloud server may be able to identify if the part installed is genuine or used. To do so the cloud server may consult a manufacture database or a usage database (step 613). Depending upon the outcome, the cloud server may transmit a notification to the customer of the counterfeit status or of the usage information. This may be via a direct communication to a mobile app on the customer device which may be updated with details or via other notification means such as email, SMS or post (step 614). Optionally, the cloud server may transmit a notification to the connected OBD device (step 615) which may accordingly, notify the vehicle engine control unit or other vehicle control units, connected systems or components so that a decision can be made on whether to allow the part to function (step 616). Advantageously, the vehicle may disable or reduce function to the control device to maintain vehicle and passenger safety. The OBD device may notify the customer rather than the cloud server (step 617).

Since the active part contains a CPU module, the hardware and software may be configured to perform certain ones of the steps performed by the OBD device or the cloud server. However, preferably, the active module remains a low power device which allows the other elements of the system to perform the analytic or notification elements such that the part merely acts as a store or performs minimal computational analysis to reduce power consumption and required circuitry.

Figure 7 illustrates an example of how the described system can function to detect faults utilising an active part. In the above example, the OBD device and cloud server have received information which has enabled them to associate the part with the vehicle. That is, the details of the part were received by the OBD device and transmitted to the cloud server. In this example, the bottom swim lane is no longer the installer but this time is the vehicle engine control unit. Upon receipt of notification of a part fault, the ECU provides the fault codes via the OBD connector to an installed OBD device (step 701, 702). The OBD device is then able to send the received fault codes to a cloud server (step 703). The cloud server is able to identify the part related to the fault by consulting a database (step 704). The cloud server is then optionally able to send details of the faulty part to the customer device (steps 705, 706). The cloud server may be subsequently updated with the part details (step 707).

The OBD receives details of the part from the active part as above, or optionally from the cloud server now the ecosystem is aware of the information (step 708). The OBD device may notify the engine control unit or other systems and components (step 709). Optionally, the OBD device may update the customer rather than the cloud server, such as my notification in car with an alarm or to a dashboard interface or by notification to the customer device (step 710). In this way, the customer and an engineer may be able to easily retrieve detailed information on the part that has been installed on a vehicle and which is generating a fault determined by the ECU.

Figure 7 further illustrates that the OBD device may send details of the fault in order to update the active part with the details of the fault (step 711, 712). In this way, when subsequently retrieved from the vehicle or at any other point, the active part will identify that the part may be faulty. As with the counterfeit example above, if the part is in fact found to be faulty, the OBD device or ECU may decide to disable or limit functionality of the part or vehicle in order to maintain vehicle safety and/or efficiency.

Figure 8 illustrates another example in which the system can be utilised to improve vehicle user experience. In this example, part usage is able to be monitored, tracked and managed utilising the active part. For example, usage of tyres may be monitored by sensor tracking wheel revolutions, or calculating distance travelled from revolutions; sparkplugs may be monitored by sensors recording the number of firings; and, headlamps may be monitored by sensors recording the period of time in use or light intensity. First, the part is activated and used (step 801). An example part may for example be a starter motor. A sensor installed in the vehicle may detect usage of the part (step 802). The sensor may be integral with the active part. The connected sensor replaces the installer and the ECU on the bottom swim lane of Figure 8 when compared to Figures 6 and 7.

The sensor detects usage of a part (step 802) and may optionally update the active part with usage details using RF (step 804). Preferably, however, the sensor may send details of usage to an installed OBD device (step 803). The OBD device receives the usage information from the sensor (step 805) and sends the usage information together with information on the part itself to the cloud server (step 807). The part is subsequently updated with usage details by the OBD device using any suitable communication technology (steps 809, 810). Accordingly, the usage of a part may be subsequently retrieved even though the part may no longer to be installed within a vehicle or retrieved by any external system once appropriate security procedures have been navigated.

As with previous examples, the part details may be sent separately to the usage data. Optionally the OBD device may transmit usage data directly to the customer device and/or mobile application on the customer device (step 808). This may be dependent on proximity to the vehicle, for example.

Upon receipt of the usage information, the cloud sever may query the database to check if the part has reached its lifetime use (step 811). The usage information may be sent to the customer device or the customer in general together with an indication of expiry (step 812, 813). Further, the vehicle may decide to modify operation of, or disable, a part if an NFC or RFID tag if it is determined that usage limits or lifespan limits have been exceeded (not shown). The active part may indeed make this determination itself. The OBD device may interrogate the part and report breaching of predetermined approved usage to the ECU or the ECU may interrogate the part directly.

The following is summary of several optional features that may be identified from the above exemplary systems of Figures 5 to 8 —

- Parts may be embedded with hardware and software that gives them the capability to update information about themselves such as (not exclusively), part number, serial number, batch number, manufacturer, security token, vehicle it is connected to, history, usage, fault detection and lifespan.

- Part information, such as part number, serial number, manufacturer, manufacturing date, batch number, lifespan and security token can be pre-embedded at the manufacturing stage or at another point by a trusted agent.

- Parts interface with vehicles through direct or indirect connections such as radio interfaces (GSM, Wi-Fi, Bluetooth, Zigbee, etc.).

- Parts can also interface with an OBD device.

- Parts authenticity and data exchange is managed securely using the security token stored on the part.

- When a part is installed, the part is notified what vehicle it has been installed in through direct or indirect connection (e.g. OBD device). This information is stored on the part. A log and history of installation is maintained on the part.

- Each time a part is used, information about usage is updated on the part.

- Parts report information about themselves to the vehicle, external system, mobile application or OBD device. The vehicle, external system, mobile application or OBD device may decide to perform some actions based on the information it has received.

- External systems, mobile applications, OBD devices or the vehicle can query the part to identify information such as (not exclusively) authenticity, usage and faults. External systems, mobile applications, OBD devices or the vehicle may decide to perform actions based on the information such as disable the part.

- When a fault occurs in the part, the part may decide to change its operations settings based on the fault or disable itself.

- When a fault occurs in the part, external systems, mobile applications, vehicle or OBD devices are notified.

- When a part reaches its usage limit or lifespan, external systems, mobile applications, vehicle or OBD devices are notified. The part may decide to change its operation settings based on the information or disable itself.

- If a counterfeit, generic or part from a faulty batch is detected, external systems, mobile applications, vehicle or OBD device may decide to change parts operation settings or disable the part. The part is also able to act on this information.

Claims

1. A system for identifying and verifying a vehicle part, the system comprising:

an identification device configured to:

retrieve part data stored on an intelligent vehicle part, the part data including a part identifier;

retrieve vehicle data, the vehicle data including a vehicle identifier indicative of the vehicle in which the part is installed; and, send the part data and vehicle data to an analysis server, and an analysis server configured to:

receive the part data and the vehicle data; and, associate the part data and the vehicle data in a database for subsequent retrieval.

2. A system according to claim 1, in which the part data includes one or more identifiers selected from a group comprising:

part type; part number; serial number; batch number; fault information; manufacturer; a vehicle identifier indicative of the vehicle in which the vehicle part is installed; related installed parts information; history information; usage information; log information; life span; installation date; a signed security token; and, installation agent information.

3. A system according to claim 1 or 2, comprising the intelligent part, the intelligent part configured for installation in the vehicle, the part comprising:

data storage, storing the part data including a signed part identifier; and, means for transmitting the part data to the identification device.

4. A system according to claim 3, in which the intelligent vehicle part comprises a processor and a long-range wireless communication module.

5. A system according to any of claim 3 or 4 in which the intelligent vehicle part is configured to monitor usage of the intelligent vehicle part and update the stored part data accordingly.

6. A system according to any of claims 3 to 5 in which the intelligent vehicle part is configured to identify the vehicle in which it is installed and determine that the part is suitable for installation in the vehicle and, if the part is not suitable, disable the part.

7. A system according to any of claims 3 to 6 in which the intelligent vehicle part is configured to alter part operation based on the stored part data.

8. A system according to any of claim 3 in which the intelligent vehicle part and identification device part are configured to communicate using NFC.

9. A system according to any of claim 3 in which the intelligent vehicle part and identification device are configured to communicate using RFID.

10. A system according to any preceding claim, the system further comprising sensors configured to monitor usage of the part and send usage information to the identification device or the intelligent vehicle part, or both.

11. A system according to any preceding claim in which the identification device is an on-board diagnostic device (OBD), the identification device being configured to be connected to an OBD port of the vehicle.

12. A system according to any preceding claim in which the identification device is configured to retrieve vehicle data and send the vehicle data to the intelligent vehicle part to update the part data stored on the intelligent vehicle part.

13. A system according to any preceding claim in which the vehicle data includes one or more selected from a group comprising: vehicle fault information indicative of a fault with the vehicle; part fault information indicative of a fault with the intelligent vehicle part; related part information; and, a vehicle identifier indicative of the vehicle in which the part is installed.

14. A system according to any of claims 11 to 13 in which the identification device is configured to receive one or more fault codes from an engine control unit and send the fault code to the analysis server.

15. A system according to claim 14 in which the identification device is further configured to send the one or more fault codes to the intelligent vehicle part.

16. A system according to any of claims 3 to 15 in which the identification device and intelligent vehicle part are configured to communicate using one or more security tokens stored on the intelligent vehicle part.

17. A system according to any preceding claim in which the analysis server is configured to check the part identifier against a list of approved parts to identify if the part is counterfeit.

18. A system according to any preceding claim in which the analysis server is configured to forward the part data and the vehicle data to a customer device.

19. A system according to any preceding claim in which the analysis server is configured to determine if the part data or the vehicle data indicates a fault, and subsequently notify the customer.

20. A system according to any preceding claim in which the analysis server is configured to check the part identifier against a database of part identifiers and determine if the part is suitable for installation in the vehicle and, if the part is not suitable, notify the customer.

21. A system according to any preceding claim in which the analysis server is configured to send an instruction to the identification device to disable the vehicle or part or both.

22. A system according to any preceding claim in which the part data includes usage information and in which the analysis server is configured to determine, based on the part data, if the part has reached or exceeded the recommended usage.

23. An identification device configured for use in a system according to any preceding claim.

24. An analysis server configured for use in a system according to any preceding claim.

25. A smart tag configured to be attached to a vehicle part, the tag comprising data storage and a transmission means, such that when the tag is attached to the vehicle part, the vehicle part becomes an intelligent vehicle part suitable for use in a system according to any of claims 3 to 22, when dependent on claim 3.

26. A method for identifying and verifying a vehicle part, the method comprising:

retrieving part data stored on an intelligent vehicle part, the part data including a part identifier;

retrieving vehicle data, the vehicle data including a vehicle identifier indicative of the vehicle in which the part is installed; and, associating the part data and the vehicle data in a database for subsequent retrieval.

27. A method according to claim 26, in which the part data includes one or more identifiers selected from a group comprising:

28. A method according to of claim 27 further comprising monitoring usage of the intelligent vehicle part and updating the stored part data accordingly.

29. A method according to any of claims 26 to 28 further comprising identifying the vehicle in which the intelligent vehicle part is installed and determining that the part is suitable for installation in the vehicle and, if the part is not suitable, disabling the part.

30. A method according to any of claims 26 to 29 further comprising altering part operation based on the stored part data.

31. A method according to any of claims 26 to 30, further comprising monitoring usage of the intelligent vehicle part and sending usage information to a customer device, a vehicle device or the intelligent vehicle part, or both.

32. A method according to any of claims 27 to 31 further comprising retrieving vehicle data and updating the part data stored on the intelligent vehicle part.

33. A method according to any of claims 26 to 32, in which the vehicle data includes one or more selected from a group comprising: vehicle fault information indicative of a fault with the vehicle; part fault information indicative of a fault with the intelligent vehicle part; related part information; and, a vehicle identifier indicative of the vehicle in which the part is installed.

34. A method according to any of claims 26 to 33 further comprising receiving one or more fault codes and associating the fault code and part data in the database.

35. A method according to claim 34 further comprising updating the stored part data with the one or more fault codes.

36. A method according to any of claims 26 to 35 further comprising authenticating the intelligent vehicle part using one or more security tokens stored on the intelligent vehicle part.

37. A method according to any of claims 26 to 36 further comprising checking the part identifier against a list of approved parts to identify if the part is counterfeit.

38. A method according to any of claims 26 to 37 further comprising forwarding the part data and the vehicle data to a customer device.

39. A method according to any of claims 26 to 38, further comprising determining if the part data or the vehicle data indicates a fault, and subsequently notifying the customer.

40. A method according to any of claims 26 to 39 further comprising checking the part identifier against a database of part identifiers and determining if the part is suitable for installation in the vehicle and, if the part is not suitable, notifying the customer.

41. A method according to claim 39 or 40 further comprising disabling the vehicle or part or both.

42. A method according to any of claims 26 to 41 in which the part data includes usage information, the method comprising determining, based on the part data, if the part has reached or exceeded the recommended usage.