GB2500697A - Vehicle monitoring system tool - Google Patents

Abstract

A vehicle monitoring system tool 20 comprising a control unit and a communications unit 32, wherein the control unit is configured to communicate with at least one server 24 across a communications network 28. The communications unit is configured to communicate with a vehicle monitoring device 22 and is incorporated into a portable computing device 30 comprising at least one communications device 32 for allowing the control unit to communicate with the server across the network. The communications unit comprises a communications device (161, fig 3) for communicating with said vehicle monitoring device. The control unit supports a user interface (46, fig. 2) , and is configured to communicate with the server and/or to cause said communications unit to communicate with the vehicle monitoring device in response to user commands received by said the interface. The tool may provide a tire pressure monitoring tool.

Description

Vehicle Monitoring System Tool

Field of the Invention

The present invention relates to vehicle monitoring systems, especially wheel monitoring systems such as Tire Pressure Monitoring Systems (TPMS). The invention relates particularly to tools for communicating with wheel mounted units of such systems.

Background to the Invention

Systems have been developed for monitoring characteristics, such as tire pressure, tire (air) temperature and/or acceleration of the wheels of a vehicle, or the battery voltage of a battery in a wheel mounted unit. A wheel mounted unit comprising one or more appropriate sensor(s) is located at each wheel, typically inside the tire, which measures the relevant characteristic(s) and transmits corresponding information to a remote central monitoring station.

It is known to provide tools for communicating with the wheel mounted units while they are in situ. Conventionally, such tools, which may be referred to as service tools, comprise dedicated electronic hardware and employs low frequency (LF) transponder technology for communicating with the wheel units. These tools are relatively complex, and therefore expensive, and are not readily adaptable for use with different types of wheel mounted units, orfor the purposes of updating.

Moreover, in some jurisdictions, every passenger car has to be fitted with a tire pressure monitoring system (TPMS). With age, factory fitted OEM wheel mounted units are prone to failure or breakage when the tires are being changed, and typical units are powered by a battery with a finite life. This is fuelling a growth in aftermarket sales of wheel mounted units, which for example presently includes the EZ sensor (trade mark) provided by Schrader Electronics Limited of Antrim, Northern Ireland. Such wheel mounted units, including the EZ sensor, are configurable to allow the user to program them to emulate the OEM unit that was removed from the wheel.

Due to restrictions in available programming space, the diagnostic capabilities of this type of unit is minimal. This is a problem should a user report that the unit is not working.

Another problem is that some users order pre-programmed wheel mounted units. It is possible to get these units mixed up and a repair technician can easily fit the wrong units to a vehicle. This can make it almost impossible to diagnose what is wrong: a lest engineer has no way of knowing with what software the unit is programmed and cannot determine, for example, if it is the correct software for the make, model and year of the vehicle Ihat the unit is fitted to. Conventional LF service tools can also be difficult to use as a result of limited user interface capabilities, and require a wired connection to a PC to receive software updates and perform other maintenance tasks.

It would be desirable therefore lo provide an improved tool for communicating wilh wheel mounted units, especially one that has diagnostic capabilities, and other remote units, especially units connected in use to a vehicle, e.g. OBD (on board diagnostics) units.

Summary of the Invention

A first aspect of the invention provides a vehicle monitoring syslem tool comprising a control unit and a communications unit, the control unit being configured for communication with at least one server across a communicalions network, the communications unil being configured for communication with a vehicle monitoring device, wherein said control unit is incorporated into a portable computing device comprising at least one communications device for allowing the control unit to communicate with said at least one server across said network, and wherein said communications unit comprises at least one communications device for communicating with said vehicle monitoring device, and wherein said control unit supports a user interface and is configured to communicate with said at least one server and/or to cause said communicalions unit to communicate with said vehicle monitoring device in response lo user commands received by said user interface.

A second aspect of the invention provides the control unit for use with the lool of the first aspect of the invention.

A third aspect of the invention provides communications unit for use wilh the tool of the first aspect of the invention.

A fourth aspect of the invention provides a vehicle monitoring system comprising the vehicle monitoring system tool of the first aspect of the invention, and at least one server, the tool being configured for communication with said at least one server across a communications network, the tool being further configured for communication with a vehicle monitoring device.

A fifth aspect of the invention provides a tool control client, typically comprising computer program code, for said control unit.

Preferred features are recited in the dependent claims.

In preferred embodiments, at least some conventional hardware and software components of a smart phone, or other mobile computing device, are used to provide a relatively low cost alternative to a dedicated LF tool, e.g. a 1PM service tool. The hardware typically provided in such mobile devices is of a higher specification than any conventional LF tool and this is beneficial for preferred embodiments as well as significantly lowering costs. These benefits may include high resolution graphics, a touch screen interface, 3G/WiFi connectivity, increased memory and storage and GPS.

Computer software can also be obtained and updated by the tools embodying the invention utilising, for example, an on-line software marketplaces such as those currently provided for existing smart phone operating systems. Preferred tools embodying the invention can advantageously use internet connectivity to access and store commands, e.g. LF commands, for wheel units such as TPM devices, and preferably also obtain software loads for programmable aftermarket TPM devices or other wheel units.

Preferred embodiments of the invention mitigate at least some of the problems outlined above by supporting the performance of diagnostic procedures on the wheel unit. For example, the tool, and in particular the control unit, may be configured to allow a user to obtain (typically download and install) diagnostic computer software from a remote server.

The diagnostic software can be used in combination with the communications tool in order to obtain diagnostic information from the wheel unit. The diagnostic information can be stored on the tool and/or uploaded to a remote server for analysis.

Advantageously, the diagnostic (software) application can be configured to provide a plurality of levels of diagnostic service. For example a basic diagnostic function may quickly check the high level functions of the wheel unit. A more detailed diagnostic function may check some of the more advanced features of the wheel unit.

Further advantageous aspects of the invention will become apparent to those ordinarily skilled in the art upon review of the following description of a specific embodiment and with reference to the accompanying drawings.

Brief Description of the Drawings

An embodiment of the invention is now described by way of example and with reference to the accompanying drawings in which like numerals are used to denote like parts and in which: Figure 1 is a block diagram of a support system embodying one aspect of the invention, said system including a wheel monitoring system tool embodying another aspect of the invention; Figure 2 is a schematic diagram of the wheel monitoring system tool shown in Figure 1, the tool being shown in communication with a wheel mounted unit; Figure 3 is a block diagram of an embodiment of a control unit being part of said wheel monitoring system tool; Figure 4 is a block diagram of an embodiment of a communications unit being part of said wheel monitoring system tool and being separable from but capable of communication with the control unit of Figure 3; Figure 5 is a block diagram of an alternative embodiment of the wheel monitoring tool comprising a combined control and communications unit; Figure 6 is a flowchart showing an example of how a tool control client supported by said control unit may initialise; Figure 7 is a flowchart showing an example of how the tool control client may request data from a server; Figure 8 is a flowchart showing an example of how the tool control client may use data stored at said control unit; Figure 9 is a flowchart showing an example of how the tool control client may perform a diagnostic function; Figure 10 is a flowchart showing an example of how the tool control client may report a problem; Figure 11 is a flowchart showing an example of how the tool control client may handle bundled computer program applications; and Figures 12 and 13 show a flowchart illustrating how the tool control client may perform a diagnostic function.

Detailed description of the Drawings

Referring now to Figure 1 of the drawings there is shown a support system 10 embodying one aspect of the invention, the system 10 incorporating a wheel monitoring system tool embodying another aspect of the invention. In preferred embodiments, the tool 20 comprises a TPMS service tool.

The tool 20 is capable of communication with the or each wheel mountable unit 22 of a wheel monitoring system (not shown), especially when the wheel unit 22 is installed on a wheel (typically inside the tire). The wheel unit 22 typically comprises a tire monitoring device having one or more sensors for monitoring one or more tire characteristics, typically including tire pressure and temperature, and being equipped to transmit corresponding tire data for reception and processing by a control unit (not shown but usually comprising the vehicle's ECU) that forms part of the wheel monitoring system.

Where the tire monitoring device measures tire pressure, the wheel monitoring system is usually referred to as a Tire Pressure Monitoring System (TPMS) and the wheel mounted unit 22 may be referred to as a tire pressure monitoring device.

The tire monitor 22 typically includes a suitably powered wireless transmitter (for communicating with the control unit of the wheel monitoring system), conveniently a battery (or otherwise) powered radio frequency (RF) transmitter, an antenna and a pressure sensor for measuring the pressure of the gas (usually air) within the tire. The tire monitor 22 also includes means (not shown) for communicating wirelessly with the tool 20. This may be separate from the wireless transmitter for communicating with the control unit of the wheel monitoring system. Typically it comprises a transponder device (e.g. transponder coil), for example a low frequency (LF) transponder device, but may alternatively comprise any other suitable wireless receiver or transceiver. In the preferred embodiment described hereinafter, the RF transmitter is also used for communication with the tool 20.

The system 10 further includes at least one server 24, for example including one or more telephony server 24A and one or more data server 24B or web server 240. The telephony server(s) 24A are typically connected to one or more telephone end points 26 which may be manned by a human operator or serviced by an automated (computer) telephone operator. Human operators may provide customer support services.

Automated operators may be configured to provide customer support services and/or telephony data, including audio and/or video data. Alternatively, or in addition, human or automated operators may be provided at computer end points associated with a web server for the provision of customer services by, for example, email or other electronic message system. The data server(s) 24B or web server(s) 240 typically comprise one or more server applications supported by one or more server computers configured to provide data, including audio data, video data, other streamed or otherwise downloadable data and/or downloadable computer program(s). In the preferred embodiment, the system 10 includes a web server configured as a computer program marketplace. The tool 20 and the server(s) 24 are capable of communication with one another via a telecommunications network 28, typically comprising any one or more of: a global computer network (e.g. the Internet); a data communications network; a mobile (cellular) telephone network; and/or other telephone network e.g. a public standard telephone network. In preferred embodiments, the server(s) 24 and the tool 20 are equipped with the necessary hardware and software to enable them to communicate with each other across the network as required. The system 10 may be said to support the tool 20 in that it may receive data and computer programs from the servers 24, particularly for the purposes of configuration, updating and diagnostics, as well as allowing a user to avail of customer services.

In preferred embodiments, the tool 20 comprises a control unit 30 and a communications unit 32. The control unit 30 is configured for communication with the servers 24 across the network 28. The communications unit 32 is configured for communication with the wheel unit 22. Preferably, the control unit 30 comprises a computing device comprising a programmable processor, typically a microprocessor, computer memory and one or more communications devices for allowing the tool 20, and in particular the control unit 30, to communicate with other devices including the servers 24. Conveniently, the control unit 30 comprises a portable, preferably hand held computing device. Preferably, the computing device comprises a mobile computing platform supporting a mobile computing operating system (OS). The computing device preferably includes means for communicating with other devices via a mobile (cellular) telephone network, and may for example comprise a mobile (cellular) telephone or a tablet computer. In the illustrated embodiment, the computing device comprises a smart phone. In addition to having mobile (cellular) telephony capabilities, smart phones are internet enabled, i.e. capable of communicating with other devices, e.g. servers 24, across the internet, for example using GSM (Global System for Mobile Communications) technology. This can be achieved using a mobile (cellular) telephone network. Smart phones are typically also equipped with other telecommunications devices, e.g. a WiFi transceiver, to allow communication across the internet via other means, e.g. a public standard telephone network or data network. In alternative embodiments, the computing device may be a dedicated device designed for use in or as the wheel monitoring tool 20, e.g. a dedicated TPMS service tool. The computing device may be provided with other input devices (not shown), for example a camera, a GPS device and/or a microphone, any one or more of which can be used to obtain data that can be of use to the tool 20 and which may be sent to the server(s)24 or the unit 22, as required.

In the preferred embodiment, the control unit 30 and the communications unit 32 comprise separable units, as illustrated in Figure 2, in which the control unit 30 is illustrated in the preferred form of a smart phone. The units 30, 32 are capable of communicating with one another, typically by means of one or more data channels 34.

The communication between the units 30, 32 may be wireless and/or wired, the units 30, 32 being equipped with a wireless communication device and/or one or more ports for a wired connection, e.g. a cable, as appropriate. In the preferred embodiment, the units 30, 32 are adapted to removably interconnect with each other. To this end, each unit 30, 32 may be provided in a respective housing 36,38 (Figure 1), the housings including respective mutually interengagable connectors for establishing a releasable mechanical connection between the housings 36, 38. In the illustrated embodiment, the housing 38 for the communications unit 32 is configured to serve as a docking station for the control unit 30. For example, the housing 38 may be shaped and dimensioned to define a bed for receiving the housing 36. The bed 40 is preferably shaped to receive the reverse face (not visible) of the housing 36, the housing 38 being shaped and dimensioned to be hand held. When so fitted, the obverse face 44 of the housing 36 (which face 44 typically includes the user interface 46, e.g. a touch screen interface and/or one or more buttons) is exposed. Hence, with the control device 30 fitted to the communications unit 32, a user

B

is able to hold the housings 38 in one hand while operating the user interface 46 with the other hand. One or more retaining devices 48, e.g. clamps or clips, may be provided for releasably securing the control unit 30 to the communications unit 32. Alternatively, the housing may be adapted to receive any one of a plurality of inserts, each insert being shaped and dimensioned to receive a respective control unit housing 36. In the illustrated embodiment, the units 30, 32 may communicate during use by a wired, but disconnectable, data connection (not shown) supporting the data channel(s) 34. The connection may comprise a data cable connectable between respective data ports (e.g. USB ports) provided in each housing 36, 38, or any other convenient non-wireless connection means. Alternatively, the data channel(s) 34 may be supported by wireless communication means, e.g. respective Bluetooth devices provided in each unit 30, 32.

The communications unit 32 comprises wireless communications means for communicating with the wheel unit 22. In typical embodiments, the wireless communication means comprises a low frequency (LF) transmitter 50 for communicating with a corresponding LF receiver or transceiver (usually a transponder device) provided in the wheel unit 22. Alternatively, or in addition, the unit 32 may include any other suitable wireless transmitter(s), receiver(s) or transceiver(s) as required, for example an RF receiver 51 as shown in Figure 2. The transmitter 50 may comprise a signal generating circuit 52 coupled to an antenna 54. The receiver 51 may comprise an antenna 53 coupled to a signal receiving circuit 55. In the illustrated embodiment, it is assumed that the unit 32 sends signals to the unit 22 using the LF transmitter 50 and receives signals from the unit via the RF receiver 51.

In the preferred embodiment where the units 30,32 are separate, the communications unit 32 advantageously also comprises a processor 56, conveniently a microprocessor, configured to control the operation of the transmitter 50 and receiver 51 and also to communicate with the control unit 30 via the data channel(s) 34.

Referring now to Figure 3 there is shown a block diagram of one embodiment of the control unit 30, indicated in Figure 3 as 130, where it is assumed that the control unit is separate from the communications unit 32. The control unit 130 is assumed to comprise a smart phone and as such includes devices such as a camera 152, sensors 154 and audio devices 156 that are not necessary for the implementation of the invention and may be omitted in alternative embodiments. The control unit 130 includes one or more processors 158, typically suitable programmed microprocessors, and computer memory (including in this example RAM and flash memory for application storage) for use by the processor(s) 158. The processor(s) 158 are configured to control a display driver 162 which drives a display 164, which may be coupled with a touch screen 165 for use in the provision of a user interface. The user interface may also, or alternatively, comprise one or more keys 167. The control unit 130 further includes communications devices 161 for communicating with other devices such as the server(s) 24 and the communications unit 32. The communications devices may include any one or more of: a USB device 166 or other port device for supporting communication via a wired link; an audio socket 163; a mobile (cellular) data connection device 168, e.g. a GSM device; a Bluetooth device 170; a WiFi device 172; and a Near Field Communication (NFC) device 174. One or more antennas and/or ports (not shown) may be provided in association with the respective communications device(s) as required. A power supply 176, typically a battery, is also provided.

Referring now to Figure 4 there is shown a block diagram of one embodiment of the communications unit 32, indicated in Figure 4 as 132, where it is assumed that the control unit is separate from the communications unit. The communications unit 132 includes one or more processors 156, typically suitable programmed microprocessors, and computer memory 182 (including in this example RAM and flash memory) for use by the processor(s) 156. The communications unit 132 further includes at least one communication devices 184 for supporting data channel(s) 34 for communicating with the control unit 30, 130, and typically at least one wireless communications device 186 for communicating with the wheel unit 22 (in alternative embodiments it is possible that the same communications device(s) can be used to communicate with both the control unit 30, 130 and the wheel unit 22). In this example, the communications device 184 comprises a Bluetooth device. The communications devices 186 may typically include any one or more of: an LF transmitter or transceiver 150 (typically comprising an LF driver 152 and an LFtransponder 154); an RF receiver or transceiver 188 (typically comprising an RF driver 189 and an RF transponder 190); and a Near Field Communication (NFC) device 191. One or more antennas may be provided in association with the respective communications device(s) as required. A power supply 192, typically a battery, is also provided.

Figure 5 shows an alternative embodiment of the tool 20 in which the control unit and the communications unit are integrated, for example provided on the same computing device, e.g. smart phone or dedicated TPM service tool running a mobile operating system. In Figure 5 the control unit is indicated generally as 230 and the communications unit is indicated generally as 232. It can be seen by comparison with Figures 3 and 4, that the embodiment of FigureS is a combination of the control unit 130 of Figure 3 and the communications devices 186 of Figure 4 (which are conveniently controlled by the processor(s) 256).

The control unit 30 supports a tool control client 92 comprising one or more computer programs. The client 92 is configured to control the operation of the tool 20. In preferred embodiments, the client 92 is configured to control, facilitate and/or support, as required, any one or more of: communication between the control unit 30 and the server(s) 24; communication between the control unit 30 and the communications unit 32; the provision and operation of the tool's user interface (which typically includes rendering information to the user (e.g. via the display 164) and handling user inputs (e.g. via keys 167 and/or touch screen 165). Advantageously, the client 92 can be downloaded from a server (assumed to be web server 24C in this example) across network 28. It may conveniently be stored in local memory 160 and executed by processor(s) 158. The functionality supported by the client 92 may vary. In preferred embodiments, the client 92 may be configured to support any one or more of the following functions: 1. operate the communications unit 32 to communicate with the wheel unit 22. This may involve causing the communications unit 32 to transmit an activation signal and/or an interrogation signal and/or a configuration signal to the wheel unit and/or to receive signals from the wheel unit 22, for example signals generated by the wheel unit in response to the activation and/or interrogation signal and/or configuration signal; 2.

communicate data to the communications unit 32 for example for use in the activation and/or operation and/or interrogation and/or configuration of the wheel unit. This data may be used to configure the activation signal and/or interrogation signal and/or configuration signal as applicable; 3. receive data from the communications unit 32 for example relating to the activation and/or operation and/or interrogation and/or configuration of the wheel unit 22. This may involve obtaining data received from the wheel unit 22; 4. communicating data to the server(s) 24, for example dab relating to the activation, operation, interrogation and/or configuration of the wheel unit, optionally including the data received from the wheel unit or dab derived therefrom, and optionally comprising any other data from the control unit 30 or communications unit 32 including for example location (e.g. GPS) data, image data (e.g. a photograph), video data, audio data and/or any user inputted data; 5. rendering via the user interface (e.g. the display 164) data, for example relating to the activation, operation, interrogation and/or configuration of the wheel unit 22 optionally including the data received from the wheel unit or data derived therefrom, and/or relating to the configuration or operation of the communications unit 32; 6. obtaining via the user interface (e.g. via the touch screen 165 and/or keys 167) user input data, for example relating to the activation, operation, interrogation and/or configuration of the wheel unit 22 and/or relating to the configuration or operation of the communications unit 32; 7. obtaining from the server(s) 24 data, for example relating to the activation and/or operation and/or, interrogation and/or configuration of the wheel unit 22, and/or relating to the configuration or operation of the communications unit 32; 8.

obtaining from the server(s) 24 computer program updates for the client 92; 9. causing the control unit 30 to connect with the telephony server 24A to allow the user to communicate with a human or automated telephone operator.

It will be apparent that by supporting some or all of the aforementioned functions, the client 92 may be configured to allow the tool 20 to perform various tasks in relation to the wheel unit 22 including activation or operation of the wheel unit, configuration (e.g. programming) of the wheel unit and/or diagnostic analysis of the wheel unit. Optionally, separate clients may be provided for each task.

In a typical embodiment where the control unit 30 and communications unit 32 are separate and the communication tool 20 communicates with the wheel unit via an LF and/or RF transmitter or transceiver, the client 92 may be configured to control one of the communication devices 161 of the control unit 30, e.g. smart phone, in order to cause the communications unit 32 to transmit a low frequency electromagnetic signal modulated in such a manner that it causes activation or configuration (e.g. programming) of the wheel unit, or obtains diagnostic related data from the wheel unit. Possible communication channels may include, but are not limited to, Bluetooth, WiFi, MicroUSB, proprietary interface, Near field communication or audio socket. Depending on the communication channel used, it may also be possible to communicate information back to the control unit for display to a user or reporting to the server(s). This information may include, but is not limited to, battery condition, diagnostic information, TPM sensor RF or LF transmitted data.

Typically, the client 92 is configured to provide a menu type user interface to allow the user to obtain LF (or other, e.g. configuration settings) commands (e.g. from server 24B) for use by the communications unit 32 when communicating with the wheel unit 22, and/or to obtain software loads either stored on the control unit 30 or at a remote server (e.g. servers 24B or 240). The control unit 30 may then stream corresponding data, typically serially to modulate the communication units 32 carrier frequency, which in turn excites the transmitting device 52, 152, creating a constant or modulated signal e.g. LF field. The LF field, or other appropriate signal, in turn activates, configures or otherwise operates the wheel unit 22, as applicable.

For diagnostic purposes, the user may operate the client 92 to download, from the server(s), e.g. server 24B, a diagnostic test script and to cause same to be communicated to the wheel unit 22 via the communications unit 32. Diagnostic related data may be obtained from the wheel unit 22 by the communications unit 32 and communicated to the control unit 30. The control unit 30 may then communicate the diagnostic information, or information derived therefrom to a server 24 configured to serve a diagnostic function. The diagnostic server 24 may be configured make a determination of the nature of the fault and send the information back to the control unit 30. A suitable message can then be rendered to the user by the client 92.

The client 92 is typically configured to establish data channel 24. This may be achieved in any convenient conventional manner. For example, in a typical smart phone, assuming that a Bluetooth channel 24 is to be established, the client 92 may be configured to use the relevant API(s) (Application Programming Interfaces) provided by the operating system to set up and manage the wireless connection. Typically the client 92 calls the API and uses it to perform the following: check for valid connected devices; prompt the user to scan for devices; establish the RF communication channel between the Smart phone and communications unit 32; and transfer data wirelessly between the smart phone and unit 32.

In typical operation of a typical embodiment of the tool 20, the user uses the user interface supported by the client 92 (typically a GUI (graphical user interface)) to determine the data to be sent to the communications device 32, and/or received from or sent to a server 24. Typical processes are out lined in the flow diagrams of Figures 6 to 11.

Figure 6 is a flowchart showing an example of how the tool control client 92 may initialise.

The availability of a connection to the server 24 is checked (601). If available, updates may be checked for (602). Options that are available when connected to the network may be rendered to the user (603), including for example: request data from server; use command stored on tool 20; use software load stored on tool; initiate diagnostics; use bundled applications; and/or report a problem (604). If no connection is available, the user may be asked if he wishes to try to connect again (605, 606). Options that are available when not connected to the network may be rendered to the user (607), including for example: use command stored on tool 20; use software load stored on tool; and/or initiate diagnostics (608).

Figure 7 is a flowchart showing an example of how the tool control client 92 may request data from a server 24. The user may be prompted to select a desired data type, e.g. tool command data or software load (701 702). The user may then be prompted to provide details of the vehicle (703 to 708). The client 92 may check if the requested data is available (709). If it is not available, the user may be informed and the client returns to the main menu (710, 711). The user may be asked if he wants to store the data on the tool 20 or to use the data now (712). If the data is stored, the user may be asked if he wants to use it now (713). If the data is to be used now, the client causes the data to be obtained from the server 24, sent to the communications device 32 and transmitted to the wheel unit 22(714). The client may then check if a response has been received from the wheel unit 22 (715). If so, it may be rendered to the user (directly or after processing by the client) (716) and/or communicated to an appropriate server. The user may be asked if he wants to send the data to the wheel unit again and, if so, causes the data to be sent again and the response processed, rendered etc as required.

Figure 8 is a flowchart showing an example of how the tool control client 92 may use data stored at the control unit 30, 130. The user may be prompted to select a desired data type, e.g. tool command data or software load (801, 802). The user may then be prompted to provide details of the vehicle (803 to 808). The client 92 may check if the requested data is available (809). If it is not available, the user may be informed and the client returns to the main menu (810, 811), or asked if he wants to select new data. If the data is available, the client causes the data to be obtained (e.g. from local memory), sent to the communications device 32 and transmitted to the wheel unit 22 (814). The client may then check if a response has been received from the wheel unit 22 (815). If so, it may be rendered to the user (directly or after processing by the client) (816) and/or communicated to an appropriate server. The user may be asked if he wants to send the data to the wheel unit again and, if so, causes the data to be sent again and the response processed, rendered etc as required.

Figure 9 is a flowchart showing an example of how the tool control client 92 may initiate a diagnostic function. The user is prompted to initiate a diagnostic function and in response to user initiation the client 92 causes a diagnostic interrogation command to be transmitted to the wheel unit 22 by the communications device 32 (901 to 903). The client checks for a response from the wheel unit 22 (904). If a response is received, it may be communicated to an appropriate server 24, a response may be received from the server 24 and rendered to the user (905 to 907). Alternatively, the wheel unit response may be processed by the client 92 and a response rendered to the user. The user may be asked if he wants to initiate a diagnostic function again (908).

Figure 10 is a flowchart showing an example of how the tool control client 92 may report a problem to for example a customer support agent via the telephony server 24A. The user is prompted to identify the problem using the user interface (1001 to 1008). The problem details are communicated to the telephony server 24A (1009), whereupon it may be rendered to an operator 26. The operator may reply, especially where the tool 20 comprises a telephone, by telephoning the user, or sending a telephonic, e.g. SMS, message to the user. Alternatively, where the server 24A is a web server, the operator may reply by email or other electronic message.

Figure 11 is a flowchart showing an example of how the tool control client 92 may handle bundled computer program applications. The user may be asked to select a bundled application, e.g. a pressure converter, a tyre/wheel guide, a VIN look up and/or a rim offset calculator (1101, 1102). The user selects a bundled application and the client causes it to be instantiated on the tool 20 (1103, 1104). After use, the user may close the application (1105, 1106).

Based on the user's input, the client 92 may obtain corresponding data from a remote server 24, e.g. server 24B, and/or from local memory at the unit 30, and cause it to be sent over the data channel 24 to the communications unit 32. The unit 32 modulates the data to be transferred over an LF (or other appropriate) channel to the wheel unit. The control unit 30 may also transfer data specific to the RF frame that the wheel unit will transmit in reply. This data may include data encoding, data rate, modulation type, modulation frequency, preamble format and C.R.C. type of the RF frame. This information may be used to configure the receiver part communications unit 32. In this connection, in the embodiments of Figures 4 and 5, it is assumed that the LF transmitter is used only to transmit signals to the wheel unit and that the RF receiver 188 is used to receive signals from the wheel unit.

In response to the data received from the tool 20, the wheel unit 22 may transmit data back to the tool 20. Typically, this involves transmitting RF data frame(s). The RF data will be received and decoded by the RF receiver 188 and the data contained in the RF frame will be communicated to the control unit 30 via channel 34. The client 92 may display the status of the communication and if applicable, may transmit relevant data to the web server 24 B or store relevant data in local memory.

Figures 12 and 13 show a flow chart illustrating how a typical diagnostic session may be implemented by the client 92. If the relevant diagnostic application is not available to the tool 20, it may be downloaded from a server 24 (1201, 1203). When available, the application is instantiated and diagnostic options may be selected (1204, 1205). Where the wheel unit supports configurable software, the pre-programmed software is recorded (1206) and a diagnostic test script is loaded onto the wheel unit via the communications unit 32 (1207). The wheel unit 22 runs the test script and its response data is received by the tool 20(1208, 1209). If advanced diagnostics is required, the response data is sent to an appropriate server 24 which processes the data and sends reply data to the tool 20 (1210 to 1213). Appropriate data is rendered to the user by the tool 20(1214). If advanced diagnostics is not required, the tool, e.g. the diagnostic application or client as applicable, processes the response data and renders appropriate data to the user (1215 to 1217). Optionally, a diagnostic report may be sent to an appropriate server 24. Where applicable, the pre-programmed software may be reinstalled on the wheel unit 22 (1218, 1219). In this example, the diagnostic process is performed by a diagnostic application that is supported by the tool 20 and instantiated by the client 92. Alternatively the client 92 may be configured to perform the diagnostic process.

In addition to what is shown in the flow chart, the user could conduct a check to ensure that the correct software for the vehicle has been loaded onto the wheel unit. This could be done by either scanning the vehicle's VIN number or manually entering the make, model and year of the vehicle. The software version of the wheel unit can then be determined and a comparison made to ensure that the software that was originally downloaded onto the wheel unit is the correct version for the vehicle that it has been fitted to.

Various levels of diagnostic function could be implemented. For example, a basic diagnostic session may involve a check of battery status, temperature information, motion switch check etc. An advanced diagnostic session may include more advanced features such as analog to digital converter (ADC) check, RF crystal start up time, frequencies of internal oscillators, PLL current and so on.

Diagnostic data that is sent to the server 24B by the client 92 may be tagged with a unique identification (UID) for the wheel unit.

During the diagnostic session, the wheel unit 22 may be caused to execute a diagnostic test script (or test routine) provided to it by the tool 20 and to communicate diagnostic results data back to the tool. For programmable wheel units, such as the EZ Sensor, the existing software programmed onto the wheel unit's processor can be overwritten by the test script. The results data can be analysed by the client 92 and/or or communicated to an appropriate remote server 24. A diagnostic report and/or user advice may be displayed on the user interlace. Optionally, at the end of the diagnostic session the user may reload the original software back onto the wheel unit.

Embodiments of the invention can be further enhanced by using the smart phone hardware and operating system in conjunction with a web server 24 to create an infrastructure that allows bi-directional "always-on" communication with a central data source. This ensures that the latest software and data is always available and allows for central live management of services such as stock levels or diagnostics. This means that the user does not need to connect to a traditional computer system in order to update the software or data files on the tool 20. It also means that there is no storage limit on the tool 20, since all data is accessible via a central server 24. The always on connection allows live data to be streamed back to the central server 24 for logging and diagnostic purposes. This may be used to monitor dealer stocks and predict short term sales forecasts.

For example, computer applications (such as client 92) may be downloaded from a mobile device OS market place (e.g. Apple Appstore, Android Market, Windows Mobile Marketplace, Blackberry App World) on to the control unit 30, which is assumed to support the appropriate mobile device OS. The control unit 30 may comprise a Smartphone, a tablet computing device or dedicated computing device. Updates to the software may be pushed out to the unit 30 through the market place, ensuring users have access to the latest software and features. Using the downloaded application, the user can request relevant software loads and commands from the central data server 24 for the vehicle of their choice. This data can be stored on the unit 30/tool 20 for use if a network connection is not available, or it may be discarded depending on the users preference. When the unit 30 is successfully programmed, a message can be sent back to the central server 24 for marketing and production planning purposes. If the unit 30 is not successfully programmed, a central customer support service can interrogate the detail of the failure to help reduce unnecessary warranty returns.

It will be seen that preferred embodiments make use of smart phone (or other mobile computing device) hardware and software technology to create a lower cost TPMS LF tool, or other wheel monitoring system tool, with a richer feature set than current solutions available today. Advantageously, a colour screen and touch interface provide an improved user interface with increased flexibility. 3G and WiFi communications can allow an always on' connection to allow the most up to date LF commands and software loads to be accessed on demand.

Preferred embodiments of the invention provide a low cost solution for users who do not want to outlay the initial investment to buy the currently available tools that will enable them to program aftermarket sensors.

Advantages of preferred embodiments of the invention include: lower cost hardware (assuming that the user already owns a smart phone or other mobile device with a supported OS.); automatic updates to the client software; the user interface can change depending on a menu rather than being confined to a few fixed buttons; users can report problems or give feedback directly within the client application; the user interface is capable of providing high resolution graphics (such as OEM logos). In addition, the software application marketplace may provide feedback and ratings information.

Preferred embodiments of the invention mitigate at least some of the problems outlined above by supporting the performance of diagnostic procedures on the wheel unit. For example, the tool, and in particular the control unit, may be configured to allow a user to obtain (typically download and install) diagnostic computer software from a remote server (e.g. as client 92). The diagnostic software can be used in combination with the communications unit 32 in order to obtain diagnostic information from the wheel unit 22.

The diagnostic information can be stored on the tool and/or uploaded to a remote server for analysis.

In addition to, or instead of, communicating with a wheel unit / tyre monitor 22, embodiments of the invention may be configured to communicate with one or more other devices (represented in Figure 1 by remote device 99) via a wireless communications link, as supported by one or more of the wireless communications devices 161, or by a wired link as supported by any one or more of the wired communication devices, e.g. USB device 166. The remote device 99 may comprise a computing device, e.g. comprising a processor such as a microprocessor or microcontroller, or any other electronic device configured to communicate with another remote device, in particular the tool 20. The device 99 may include one or more wired or wireless communication devices, such as any one or more of the devices 166, 232 shown in Figure 5. The remote device 99 may be connectable to, or comprise part of, a vehicle's electronic system, for example a vehicle's electronic communication network, or wheel unit / tyre monitor 22.

For example, the device 99 may comprise an ECU, BCU or other control unit or processor included in the vehicle's electronic system or communication network.

Alternatively the device 99 may comprise a removable hardware or firmware device that is connectable to the vehicle's electronic system or communication network or wheel unit / tyre monitor 22. In particular, the remote device 99 may be connectable to, or comprise part of, a vehicle's diagnostic system. For example, the device 99 may comprise a removable OBD (on board diagnostics) dongle, or other removable device, connectable to the vehicle's electronic system.

In use, the tool 20 may communicate with the device 99 to perform any one or more of the functions described above in relation to the wheel unit 22, including any one or more of the diagnostic related functions. For example, where the device 99 is used for diagnostic purposes, diagnostic related data may be communicated to the device 99 from vehicle's electronic system or communication network or wheel unit / tyre monitor 22, as applicable, and then communicated to the tool 20. Alternatively, e.g. in the case where the device 99 is part of the vehicle's electronic system, the relevant data may be available from the device 99 itself. In any event, the data may be processed by the tool 20 and/or communicated to a server 24 for processing. Data may also be communicated to the device 99, e.g. for the purposes of activation or configuration. Similarly any other type of data, e.g. test data, status data, activation data and/or configuration data, may be communicated between the tool 20 and the device 99.

The client 92 and/or an application running on a server or client included in the system may be configured to process, and render to the user, data obtained by the tool 20 in any manner that suits the application. For example, the client 92 or other application may be used to manage data, e.g. tyre pressure measurements or other tyre data, in respect of a fleet of vehicles.

The invention is not limited to the embodiment described herein, which may be modified or varied without departing from the scope of the invention.

Claims (20)

1. CLAIMS: 1. A vehicle monitoring system tool comprising a control unit and a communications unit, the control unit being configured for communication with at least one server across a communications network, the communications unit being configured for communication with a vehicle monitoring device, wherein said control unit is incorporated into a portable computing device comprising at least one communications device for allowing the control unit to communicate with said at least one server across said network, and wherein said communications unit comprises at least one communications device for communicating with said vehicle monitoring device, and wherein said control unit supports a user interface and is configured to communicate with said at least one server and/or to cause said communications unit to communicate with said vehicle monitoring device in response to user commands received by said user interface.
2. 2. A tool as claimed in claim 1, wherein said control unit comprises a programmable processor supporting at least one tool control client, said at least one tool control client being configured for communication with said at least one server and said communications unit and to control the operation of said tool.
3. 3. A tool as claimed in claim 1 or 2, wherein said at least one communications device of said portable computing device comprises at least one wireless communications device, preferably including a GSM or other mobile (cellular) communications device.
4. 4. A tool as claimed in any one of claims 1 to 3, wherein said portable computing device comprises a mobile computing platform supporting a mobile (cellular) computer operating system, and may for example comprises a smart phone or a tablet computer or a dedicated service tool, preferably a tire pressure monitoring (TPM) service tool.
5. 5. A tool as claimed in any preceding claim, wherein said control unit and said communications unit comprise separable units, each including at least one communications device configured to enable said units to communicate with one another by a wireless and/or wired communications link.
6. 6. A tool as claimed in claim 5, wherein said units are adapted to removably interconnect with each other.
7. 7. A tool as claimed in any one of claims 1 to 4, wherein said control unit and said communications unit are incorporated into a common device, preferably a portable computing device.
8. 8. A tool as claimed in any one of claims 2 to 7, wherein said tool control client is configured to control, facilitate and/or support any one or more of: communication between the control unit and said at least one server; communication between the control unit and the communications unit; the provision and operation of said user interface.
9. 9. A tool as claimed in any preceding claim, wherein said at least one communications device of the communications unit comprises wireless communications means for communicating with the vehicle monitoring device.
10. 10. A tool as claimed in claim 9, wherein said wireless communication means comprises a low frequency (LF) transmitter and, optionally, at least one other wireless transmitter or transceiver, for example an RF transmitter or transceiver.
11. 11. A tool as claimed in any one of claims 2 to 10, wherein said tool control client is configured to operate the communications unit to communicate with the vehicle monitoring device, which operation may include causing the communications unit to transmit an activation signal and/or an interrogation signal and/or a configuration signal to the vehicle monitoring device and/or to receive signals from the vehicle monitoring device.
12. 12. A tool as claimed in claim 11, wherein said tool control client is configured to communicate data to the communications unit for use in the activation and/or operation and/or interrogation and/or configuration of the vehicle monitoring device.
13. 13. A tool as claimed in claim 11 or 12, wherein said tool control client is configured to receive data from the communications unit relating to the activation and/or operation and/or interrogation and/or configuration of the vehicle monitoring device.
14. 14. A tool as claimed in any one of claims 2 to 13, wherein said tool control client is configured to communicate data to said at least one server, preferably data relating to the activation, operation, interrogation and/or configuration of the vehicle monitoring device, optionally including the dab received from the vehicle monitoring device and/or data derived therefrom, and optionally comprising any other data from the control unit or communications unit, including location data, image data, video data, audio data and/or any data received by the user interface.
15. 15. A tool as claimed in any one of claims 2 to 14, wherein said tool control client is configured to render via the user interface data relating to the activation, operation, interrogation and/or configuration of the vehicle monitoring device, optionally including the data received from the wheel unit and/or data derived therefrom, and/or relating to the configuration or operation of the communications unit.
16. 16. A tool as claimed in any one of claims 2 to 15, wherein said tool control client is configured to obtain via the user interface user input data relating to the activation, operation, interrogation and/or configuration of the vehicle monitoring device and/or relating to the configuration or operation of the communications unit.
17. 17. A tool as claimed in any one of claims 2 to 16, wherein said tool control client is configured to obtain via one or more input device of the control unit, for example a camera, a microphone or a GPS sensor, dab for use in relation to the activation, operation, interrogation and/or configuration of the vehicle monitoring device and/or relating to the configuration or operation of the communications unit.
18. 18. A tool as claimed in any one of claims 2 to 17, wherein said tool control client is configured to obtain from said at least one server data relating to the activation, operation, interrogation and/or configuration of the vehicle monitoring device, and/or relating to the configuration or operation of the communications unit.
19. 19. A tool as claimed in any one of claims 2 to 18, wherein said tool control client is configured to obtain from said at least one server computer program products, optionally including updates for the client, and optionally to cause said computer program products to be instantiated on said control unit or on said vehicle monitoring device.
20. 20. A tool as claimed in any one of claims 2 to 19, wherein said tool control client is configured to cause the control unit to connect with a telephony server to allow the user to communicate with a human or automated telephone operator.