Field of the Invention
[0001] The present invention relates to a system and method for distributing vehicle maintenance
data. More particularly, the present invention relates to collecting vehicle maintenance
data and distributing said data to remote vehicle service providers.
Background of the invention
[0002] Systems are known with which to report the accurate location, operational parameters
or a combination thereof of a vehicle to its user or to a remote monitoring station.
[0003] A proportion of such vehicle-based systems are further known, which make use of the
satellite-based Global Positioning System to determine said accurate location at any
precise time. Accurate vehicle location is useful in such applications as facilitating
vehicle navigation throughout a journey, vehicle stopping and retrieving when taken
without consent or simply tracking for delivery time estimation and, more recently,
matching vehicle location to proximate services required by its user with making use
of geo-fencing parameters.
[0004] The data distribution functionality of such systems is usually restricted to broadcasting
GPS location data expressed as latitudinal and longitudinal co-ordinates, or other
location data such as cell location in a mobile phone network, to a remote processing
unit such as a network server, which is then processed for correlation with map data
in order to output and send back the relevant information, whether it be street names
or service provider names and addresses.
[0005] For instance, in the case of a remote monitoring station tracking a stolen vehicle
or a delivery vehicle, a user at said monitoring station sends a processing command
or simply a text-based communication to said vehicle-based system, whereby said GPS
co-ordinates or cell location are sent back for mapping in response. In the case of
location matching applications, a vehicle user enters journey or services parameters
with activating keys of a vehicle-mounted keypad or user interface, whereby GPS co-ordinates
or cell location are sent back to a network server for mapping, matching and broadcasting
results back to said user.
[0006] In the context of the above prior art, a problem exists in that many vehicle users
fail to regularly maintain their vehicle in optimum working order with timely mechanical
maintenance, opting instead for punctual, as-needed maintenance, for instance as a
result of uncertainty as to what frequency should said maintenance take place.
[0007] Indeed, whereas the above applications may be useful in locating a vehicle service
provider in close vicinity or specialising in the vehicle make or model itself, they
rely upon vehicle user-input at the time of the decision to carry out vehicle maintenance,
such as search parameters for maintenance providers. Such systems therefore require
the vehicle user to remain aware of vehicle service intervals and requirements throughout
the useful life of the vehicle, whether such intervals are based upon the total distance
covered by the vehicle, the total running time of its mechanical components or a combination
thereof, which is a difficult and time-consuming task. A user may for example travel
few miles in a given period but spend most of said period in urban traffic, whereby
maintenance should take place based upon cumulative running time of the vehicle engine
in that period rather than total distance travelled, but said user opting instead
to maintain the vehicle at mileage intervals, such that engine wear is compounded
by lack of timely maintenance.
[0008] It is known to provide a unit to connect to an odometer of the vehicle to monitor
the mileage of the vehicle to indicate when a service is due, for example such a unit
is supplied by the car manufacturer BMW. However a problem with this type of unit
is that the unit gives an unreliable reading as to when a maintenance of the vehicle
is due because it depends on distance travelled only and does not take account of
when the odometer is not working properly, either due to a fault or deliberately tampered
with. Additionally the odometer does not take account of when a vehicle has its engine
running and stationary or other parameters, for example the average speed the vehicle
was travelled. A more sophisticated solution is disclosed in Canadian patent publication
number CA2359887 by 'Road Inc' wherein vehicle maintenance-related services are provided
from a server over a wide area network, such as the Internet. A server that is accessible
over the wide area network through a wireless communication link is provided. An apparatus
is provided in a vehicle to collect, over a data bus in the vehicle, data relating
to an operation of the vehicle. The data received from the data bus is then communicated
to the server over the wireless communication link. Based on the data received at
the server, the maintenance-related services is then initiated. The operation data
of the vehicle can be collected from various subsystems of the vehicle. A problem
with the Road Inc. solution is that it is reliant on the various subsystems of the
vehicle to gather data, which are not accurate. Additionally the Road Inc solution
is difficult to install as a data bus must be provided to connect to each sub-system
in the vehicle in order to gather data, which is technically difficult to achieve
[0009] Moreover, a second problem exists in that vehicle service providers remain unaware
of many variables, such as required maintenance points, stock of parts and staffing
levels until vehicle users have contacted them to arrange vehicle maintenance and
have been queried about their driving habits to determine maintenance points and parts.
It is therefore difficult for said vehicle service providers to forecast any of the
above variables with accuracy, thus providing their services economically and profitably,
which detriments the user with, for instance, vehicle immobilisation for unnecessary
lengths of time whilst maintenance is carried out (e.g. if awaiting parts).
Object of the Invention
[0010] A vehicle maintenance system and method is therefore required, which distributes
vehicle maintenance data to vehicle maintenance professionals in advance of maintenance
thresholds in order to regularly maintain said vehicle in optimum working order with
timely mechanical servicing, such that said servicing is carried out more economically
for both the user and the service provider.
Summary of the Invention
[0011] According to an aspect of the present invention, as set out in the appended claims,
a system for distributing vehicle maintenance data is provided, which includes at
least one module configured with self-locating means, local processing means, memory
means and communicating means for attachment to a vehicle and remote processing means
configured with communication means, wherein said self-locating means acquires vehicle
location data at time intervals; said memory means stores instructions, threshold
data and said acquired data; said local processing means is configured by said instructions
to process said acquired data into cumulative data and compare said cumulative data
to said threshold data according to comparison parameters; whereby upon said data
comparison returning a match, said local processing means instructs said communication
means to broadcast said cumulative data to said communication means of said remote
processing means.
[0012] According to another aspect of the present invention, a method of distributing vehicle
maintenance data is provided, said method comprising the steps of acquiring vehicle
location data at time intervals with self-locating means in at least one module configured
with self-locating means, local processing means, memory means and communicating means
attached to a vehicle; storing instructions, threshold data and said acquired data
in said memory means; configuring said processing means with said instructions to
process said acquired data into cumulative data; comparing said cumulative data to
said threshold data according to comparison parameters and upon said data comparison
returning a match, instructing said communication means to broadcast said cumulative
data to communicating means of remote processing means.
[0013] According to another aspect of the present invention, a computer system programmed
to execute stored instructions is provided such that in response to said stored instructions
said system is configured to acquire vehicle location data at time intervals from
self-locating means; store threshold data and said acquired data in memory means;
process said acquired data into cumulative data; compare said cumulative data to said
threshold data according to comparison parameters and, upon said data comparison returning
a match, instruct communication means to broadcast said cumulative data to communicating
means of a remote terminal.
[0014] According to another aspect of the present invention, a computer-readable memory
system having a plurality of data fields stored therein representing a data structure,
wherein said data structure includes vehicle location data at time intervals, cumulative
data and threshold data and further having instructions configured to process said
vehicle location data at time intervals into said cumulative data; compare said cumulative
data to said threshold data according to parameters and broadcast said cumulative
data to a remote terminal upon said data comparison returning a match.
[0015] According to an aspect of the present invention, a module for attachment to a vehicle
for distributing vehicle maintenance data is provided, which includes self-locating
means, local processing means, memory means and communicating means, wherein said
self-locating means acquires vehicle location data at time intervals; said memory
means stores instructions, threshold data and said acquired data; said local processing
means is configured by said instructions to process said acquired data into cumulative
data and compare said cumulative data to said threshold data according to comparison
parameters; whereby upon said data comparison returning a match, said local processing
means instructs said communication means to broadcast said cumulative data.
[0016] According to an aspect of the present invention, a kit of parts for distributing
vehicle maintenance data is provided, said parts including at least one module configured
with self-locating means, local processing means, memory means and communicating means
for attachment to a vehicle and remote processing means configured with communication
means, wherein said self-locating means acquires vehicle location data at time intervals;
said memory means stores instructions, threshold data and said acquired data; said
local processing means is configured by said instructions to process said acquired
data into cumulative data and compare said cumulative data to said threshold data
according to comparison parameters; whereby upon said data comparison returning a
match, said local processing means instructs said communication means to broadcast
said cumulative data to said communication means of said remote processing means.
[0017] It will be appreciated that the self-locating means acquires the data independent
of vehicle operating characteristics. The invention does not rely on measuring parameters
of the vehicle to acquire the data, which has the advantage that the data acquired
is not reliant on the vehicle itself, which can be unreliable. The invention also
provides the advantage of facilitating automated vehicle management which allows vehicle
maintenance operators take full control of their customers maintenance requirements.
[0018] In a preferred embodiment of the present invention, said threshold data and cumulative
data is a distance, which may be expressed in any unit of measure such as imperial
miles or metric kilometers or sub-divisions thereof. In another preferred embodiment
of the present invention, said module is further configured with sensor means for
determining whether a vehicle engine is powered up or down, wherein said threshold
data and cumulative data also includes engine running time, which may be expressed
in any unit of measure of time such as a combination of days, hours, minutes and seconds.
[0019] In a preferred embodiment of the present invention, said memory means includes first
non-volatile and second volatile random access memory, wherein said threshold data
and cumulative is stored in first non-volatile RAM and acquired location data is stored
in said second volatile RAM.
[0020] In a preferred embodiment of the present invention, said local processing means is
further configured by said instructions to receive and process read requests from
said remote processing means, whereby upon receiving a cumulative data read request
from said remote processing means, said local processing means instructs said communication
means to broadcast said cumulative data to said communication means of said remote
processing means.
[0021] The self-locating means is preferably a Global Positioning System device receiving
time and location data from orbiting satellites. Suitably the communication means
is a modem configured to exchange data packets over a wireless network, such as the
Global System for Mobile Communication ('GSM') or General Packet Radio Service ('GPRS')
networks. In yet another preferred embodiment of the present invention, said cumulative
data and read request are respectively communicated as text messages using Short Message
Service ('SMS') protocol over said wireless network. Preferably, said remote processing
means parse said text messages and store cumulative data therein in a database.
[0022] In yet another preferred embodiment of the present invention, said remote processing
means are located at one or a plurality of vehicle maintenance providers. Preferably,
said threshold data is updated when said vehicle is maintained by any of said vehicle
maintenance providers.
Brief Description of the Drawings
[0023] The invention will be better understood upon consideration of the following detailed
description and the accompanying drawings, in which:
Figure 1 shows a preferred embodiment of the present invention in an environment, including
at least one vehicle to which a module is attached and at least one vehicle service
provider equipped with a terminal;
Figure 2 shows the module of Figure 1 in further detail, including memory means;
Figure 4 details the processing steps according to which the module of Figures 1 and 2 operates, including a step of processing data at runtime;
Figure 4 illustrates the contents of the memory means shown in Figure 2 during the data processing step shown in Figure 3;
Figure 5 further details the data processing step of Figure 4, including a step of data comparison and a data broadcasting step;
Figure 6 further details the data comparing step of Figure 5;
Figure 7 further details the data broadcasting step of Figure 5;
Figure 8 provides an example of the terminal at the vehicle service provider shown in Figure 1, which includes processing means, memory means and communicating means;
Figure 9 details the processing steps according to which the terminal of Figures 1 and 8 operates, including a step of updating a database and a step of processing database
data according to user input;
Figure 10 illustrates the contents of the memory means of the terminal of Figures 1, 8 and 9 according to the present invention, including an application and a database;
Figure 11 provides an example of the database shown in Figure 10;
Figure 12 shows a graphical user interface of the application shown in Figure 10;
Figure 13 further details the database updating step of Figure 9;
Figure 14 further details the database data processing step of Figure 9; and
Figure 15 shows the graphical user interface of Figure 12 upon performing either of the processing steps described in Figures 13 and 14.
Detailed Description of the Drawings
[0024] A preferred embodiment of the present invention is shown in an environment in Figure
1, which includes at least one vehicle
101, for instance a car, to which a module
102 is attached and at least one vehicle service provider
103 equipped with a terminal
104. Module
102 combines Global Positioning System (GPS) data processing functionality and wireless
telecommunication emitting and receiving functionality, such as over a cellular telephone
network configured according to the Global System for Mobile Communication ('GSM')
or General Packet Radio Service ('GPRS') network industry standards. In yet another
preferred embodiment of the present invention, said cumulative data and read request
are respectively communicated as text messages using Short Message Service ('SMS')
protocol. Module
102 receives GPS latitudinal data, longitudinal data and time data from GPS satellite
105 over wireless data transmission
106 by means of vehicle aerial
107, preferably every second. Module
102 receives or emits voice and/or text data encoded as a digital signal over wireless
data transmission
108 by means of the same vehicle aerial
107 or another dedicated aerial, wherein said signal is relayed respectively to or from
module
102 in vehicle
101 by the geographically-closest communication link relay
109 of a plurality thereof. Said text data is preferably encoded as a SMS message, although
it will be readily understood by those skilled in the art that the present invention
is not limited thereto.
[0025] The plurality of communication link relays allows said digital signal to be routed
between module
102 and its intended recipient or from its remote emitter, in the example terminal
104 of vehicle service provider
103, by means of a remote gateway
110. Gateway
110 is for instance a communication network switch coupling digital signal traffic between
wireless telecommunication networks, such as the network within which wireless data
transmission
108 takes place, and a wide area network (WAN)
111, an example of which is the Internet. Said gateway
110 further provides protocol conversion if required, for instance if module
102 uses Wireless Application Protocol to distribute data to and optionally receive from
terminal
104, which is itself only connected to the WAN
111.
[0026] The user of vehicle
101 preferably has the use of either a mobile communicating device
112 configured to at least receive text data encoded as a digital signal over a wireless
data transmission
113, such as a mobile telephone, or a terminal
114 connected to said WAN
111 and configured with electronic mail receiving and emitting functionality, or both.
Thus, the potential exists for data exchange between any of module
102, mobile communicating device
112 and terminals
104 and
113, by way of wireless data transmissions
108,113 and the Internet
111 interfaced by gateway
110.
[0027] In the example, many other vehicles shown as
115 are likewise respectively equipped with a module
102, whereby the potential exists for likewise data exchange between any of said many
modules
102, terminal
104 and the respective wireless or WAN-connected communication devices (not shown) of
said vehicles owners.
[0028] The module
102 is shown in Figure 2 in further detail. Module
102 includes self-locating means
201 in the form of a GPS receiver containing an analogue-to-digital converter
202, which receives analogue positional and time data through aerial
107 from satellite
105 and processes it into digital data, and a processor
203 for outputting said converted data into latitude (Xn), longitude (Yn) and elevation
(Zn) integers and time data into clock-time data (Tn). In the preferred embodiment
of the present invention, said elevation (Zn) data is not processed, because the data
processing and module cost overheads required to do so are not offset by the gain
in module output accuracy, given that the output variation between processing Xn,
Yn data as opposed to Xn, Yn, Zn is minimum. In an alternative embodiment of the present
invention depending upon the available processing capacity within module
102, however, said elevation (Zn) data may also be processed in order to further increase
the accuracy of the output of module
102. Xn, Yn data is regularly output by receiver
201 at time Tn and stored in memory means
204, which includes non-volatile random-access memory (NVRAM) totalling
512 kilobytes in this embodiment. NVRAM
204 provides non-volatile storage for processing means
205, which is a Central Processing Unit (CPU) such as a general-purpose microprocessor,
acting as the main controller of module
102.
[0029] Said GPS receiver
201, NVRAM
204 and CPU
205 are connected by a data input/output bus
206, over which they communicate and to which further components of module
102 are similarly linked in order to provide wireless communication functionality and
receive user interrupts and configuration data. Accordingly, communication functionality
is provided by a modem
207, which provides the interface to external communication systems, such as the GSM or
GPRS cellular telephone network shown in Figure 1. A user interrupt may be received
from data input interface
208, which is a switch. In this embodiment, a second interface
209 is provided as an industry-standard RS-
232 data input port for attachment to an external data input device, wherefrom input
data configuring or upgrading module
102 for use may be stored in NVRAM
204. Power may be provided to module
102 by an electrical converter
210 connected to the battery
211 of the vehicle or, alternatively, by an internal module battery
212 included as a redundant power source in the electrical circuit of module
102 in case of battery
211 failing.
[0030] The processing steps according to which module
102 operates are described in Figure 3. In order to distribute vehicle maintenance data
to vehicle maintenance professionals in advance of maintenance thresholds, it is preferable
to input threshold data in module
102, for instance at first when a vehicle is new and, subsequently, every time said vehicle
is maintained.
[0031] Upon completing the assembly of the vehicle
101 at a manufacturing facility, module
102 is configured to power up at step
301 when battery
211 is first connected to the electrical circuit thereof, whereby NVRAM
204 is initialised at step
302. At said manufacturing facility still or, alternatively, upon a vehicle service provider
104 taking delivery of said new vehicle, the external data input device described in
Figure 2 is connected thereafter to second interface
209, whereby instructions for CPU
205 and reference data for receiver
201 may be uploaded into NVRAM
204 at step
303. The processing of said CPU instructions starts at the next step
304 with first generating, then initialising a reference key in NVRAM
204 at steps
305, 306 respectively. In this embodiment, said reference key is a 3-bit key, but it will
be understood by those skilled in the art that the present description is not limited
thereto, as indeed even a 1-bit key or a key using much more than 3 bits may be usefully
implemented instead. Moreover, in an alternative embodiment of the present invention,
the referencing function of the above key is performed with several data accumulators
instead.
[0032] The initialising of said reference key at said step
306 permits data input through interface
209, which is otherwise not permitted. Said instructions optionally allow receiver
201 to be calibrated for location and/or time accuracy at step
307. At step
308, maintenance threshold data Dα is input, preferably as a distance, for instance expressed
in imperial miles or metric kilometres, whereby it is permanently stored in NVRAM
204. In another embodiment of the present invention, maintenance threshold data Tα is
then input at step
309, preferably as a period of time, for instance expressed in days, hours, minutes or
any combination thereof, whereby it is also permanently stored in NVRAM
204. Upon completing this threshold input, the external device may then be disconnected
from interface
209 at the next step
310, whereby module
102 now operates at runtime at step
311, with processing location and time data according to the instructions loaded at step
303.
[0033] A question is asked at step
312, as to whether a user interrupt has been received from switch
208. If the question of step
312 is answered positively, such as when vehicle
101 is being maintained upon reaching or approaching said maintenance thresholds Dα and/or
Tα and a vehicle service provider activates switch
208 as a maintenance point, control proceeds to step
306, whereby the reference key first generated at step
305 is again initialised and new maintenance threshold data Dα and/or Tα may thus be
input as previously described. Alternatively, the question of step
312 is answered negatively and the runtime processing of step
311 continues.
[0034] The contents of NVRAM
204 are shown in Figure 4 upon starting the runtime step
311. Memory
204 first contains an application
401 embodying the set of CPU instructions previously described, thus which processes
positional data, time data, distributed and distributable data. Preferably, application
401 is configured to process local data as detailed below, packet and broadcast said
data or receive remote data with modem
207, wherein said distributed data is for instance encoded in a SMS text message. In order
to identify the module
102 of vehicle
101 amongst the many modules
102 of vehicles
115, memory
204 also stores a unique device ID
402, which may for instance be a sequential integer ID or a vehicle-specific ID such as
the registration number or VIN chassis number of vehicle
101.
Memory
204 next contains distance maintenance threshold data Dα
403 and, optionally, time maintenance threshold data Tα
404. Stored cumulative distance data D is shown at
405 and optional stored cumulative time data T is shown at
406. Calculated distance data Dn is shown at
407, which is processed from Xn, Yn data according to the present invention. Optional
calculated time data Tn is shown at
408, which is processed from Tn data according to the present invention. The 3-bit reference
key of steps
305, 306 is shown at
409 as three bits initialised at zero, which may be respectively set to one by application
401 upon data D
405 or optional data T
406 meeting parameters relative to Dα
403 or Tα
404 respectively, which will be further described herein. Memory
204 next contains at least one communication address
410 of a remote recipient, such as the phone number or address in WAN
111 of terminal 104 of service provider
103, in order for module
102 to distribute data thereto via modem
207. GPS reference data is shown at
411 and Xn, Yn, and Tn location data communicated by processor
203 over bus
206 is preferably stored in a portion of memory
204 configured as a First-In-First-Out (FIFO) buffer
412. Said location data is stored as a sequential collection of locations (Xn, Yn)
413, 414 sampled at respective, regular time intervals Tn
414, 415 which are preferably very short, such as one second in the example. For practical
and costs purposes, the accuracy of said (Xn, Yn) data
413, 414 is two-times distance root mean square (2drms) plus or minus 5 meters.
[0035] The declared size of buffer
412 determines the amount of samples
413, 414 stored at any one time
414, 415 in memory
204, which may thus vary according to whether a larger or smaller amount of NVRAM is provided
and/or coding or compiling optimisation reduces the physical size of application
401 and/or the GPS data requirements for distance calculation. In the embodiment, it
is preferable to store FIFO buffer
412 in NVRAM
204 as opposed to a volatile random access memory, to ensure successive samples provide
accurate location and time data without interruption, irrespective of whether vehicle
101 is under power or not when its location changes, for instance for vehicle security
purposes or, optionally, to compare total distance travelled D
405 against total engine running time T
406.
[0036] The data processing step
311 is further detailed in Figure 5. Location and time data (Xn, Yn, Tn)
413 to
416 is regularly output by processor
203 at step
501 over bus
206 during runtime step
311, whereby it is queued in buffer
412 in memory
204 according to said one-second sampling interval at step
502. At step
503, application
401 fetches said location data (Xn, Yn)
413 and (Xn+
1, Yn+
1)
414 from said queue at times Tn
415 and Tn+
1 416 respectively. A first question is asked at step
504, as to whether a difference exists between said selected sets of location data
413, 414, thus whether vehicle
101 has travelled in the sampling interval. If the question of step
504 is answered positively, application
401 calculates the distance Dn
407 travelled between said selected sets of location data
413, 414. Examples of distance calculation are provided below for descriptive purposes, but
it will be readily understood by those skilled in the art that the present description
is not limited thereto.

Where


[0037] The accuracy provided by the above calculation may be increased if CPU
205 can process cosine functions, whereby:

Where


[0038] The above calculation is described for distances in imperial miles, but coefficients
may be appropriately substituted for distances in metric kilometres or any other measurement
system and/or subdivisions thereof. Likewise, the calculation described is relatively
simple and thus very economic in processor usage, but greater accuracy may be obtained
without departing from the scope of the present invention and will be dependent upon
the processing capacity of CPU
205, notably floating point mathematical accuracy, particularly double-precision floating
point calculation. In particularly advantageous embodiment of the present invention,
said distance Dn is adjusted for errors using GPS-based speed and heading filters,
wherein said filters are Least Squares adjustment filters, for instance Kalman filters,
which are known in the art of kinetic GPS data processing. Optionally, application
401 also calculates the time Tn
408 elapsed between said selected sets of location data
413, 414 based upon time data
415, 416 at said step
505.
[0039] At the next step
506, to which control also proceeds directly if question
504 is answered negatively, a second question is asked as to whether the vehicle engine
is under power, in order to determine whether to update D
405 and optionally T
406. Question
506 is answered for instance with polling an industry standard engine sensor device returning
a binary response of zero (engine off) or one (engine on). If the question of step
506 is answered positively, application
401 updates the cumulative distance D
405 at step
507 with adding the distance Dn
407 calculated at step
505 to it. Optionally, application
401 also updates the cumulative running time D
406 at said step
507 with adding the elapsed time Tn
408 calculated at said step
505.
[0040] At the next step
508, to which control also proceeds directly if question
506 is answered negatively, a third is asked as to whether a remote data request has
been received by module
102. In the embodiment, it is possible for a user at terminal
104 of service provider
103 to poll module
102 for distance data D
405 and, optionally, time data T
406. Said poll is preferably, but not necessarily, a function call encoded as a SMS message
which, when received by modem
207 and then processed by application
401, simply triggers the broadcasting function of said application
401 as will be further described below. If the question of step
508 is answered negatively, application
401 next compares the stored cumulative distance D
405, possibly updated according to step
507, with the stored maintenance threshold Dα
403 at step
509, in order to determine whether a maintenance broadcasting event is triggered, the
parameters of which may vary and examples of which will be provided further herein.
Optionally, application
401 also compares the stored cumulative time T
406, possibly updated according to step
507, with the stored maintenance threshold Tα
404 at said step
509 for the same purpose. A fourth and final question is thus asked at step
510, as to whether a maintenance broadcasting event is triggered by the comparison of
step
509 which, if answered positively, triggers the broadcasting function of said application
401 at step
511, as would be the case if the previous question
508 was answered positively instead.
[0041] Alternatively, the question of step
510 is answered negatively and, in the absence of user interrupt of step
312, control returns to step
503.
[0042] The data comparing step
509 is further detailed in Figure 6. In the embodiment, it is preferred that module
102 broadcasts cumulative distance D
405 at set ratios of the distance maintenance threshold Dα
403, notably when said distance D
405 respectively reaches a third of threshold Dα
403, two thirds of threshold Dα
403 and said threshold Dα
403. At step
601, a first question is asked at to whether the value of cumulative distance D
405 exceeds a third of distance maintenance threshold Dα
403. If the question of step
601 is answered negatively, control proceeds to the question of step
510, which is answered negatively also. Alternatively, the question of step 601 is answered
positively, whereby a second question is asked at step
602 as to whether the bit in reference key
409 corresponding to the condition asked in question
601 is set, in the example the first bit of said key. If the question of step
602 is answered negatively, application
401 sets said first bit to one at step
603 and control proceeds to step
610, wherein an event is declared which answers question
510 positively and triggers a broadcast. Upon the questions of steps
601, 602 being both answered positively, said first condition is ignored for the purpose of
deciding whether to broadcast distance D
405, thus avoiding unnecessary, repeated duplication of said broadcast and control proceeds
to the next step
604.
[0043] At step
604, a third question is asked at to whether the value of cumulative distance D
405 exceeds two-thirds of distance maintenance threshold Dα
403. If the question of step
604 is answered negatively, control proceeds to the question of step
510, which is answered negatively also. Alternatively, the question of step
604 is answered positively, whereby a fourth question is asked at step
605 as to whether the bit in reference key
409 corresponding to the condition asked in question
604 is set, in the example the second bit of said key. If the question of step 605 is
answered negatively, application
401 sets said first bit to one at step
606 and control again proceeds to step
610, wherein an event is declared which answers question
510 positively and triggers a broadcast. Upon the questions of steps
601, 602, 604 and
605 being all answered positively, said first and second conditions are ignored for the
purpose of deciding whether to broadcast distance D
405, thus avoiding unnecessary, repeated duplication of said broadcast and control proceeds
to the next step
607. At step
607, a fifth question is asked at to whether the value of cumulative distance D
405 exceeds distance maintenance threshold Dα
403. If the question of step
607 is answered negatively, control proceeds to the question of step
510, which is answered negatively also. Alternatively, the question of step
607 is answered positively, whereby a sixth question is asked at step
608 as to whether the bit in reference key
409 corresponding to the condition asked in question
607 is set, in the example the third bit of said key. If the question of step
608 is answered negatively, application
401 sets said first bit to one at step
609 and control again proceeds to step
610, wherein an event is declared which answers question
510 positively and triggers a broadcast. Upon the questions of steps
601, 602, 604, 605, 607 and
608 being all answered positively, said first, second and third conditions are ignored
for the purpose of deciding whether to broadcast distance D
405, thus avoiding unnecessary, repeated duplication of said broadcast.
[0044] In the embodiment, vehicle maintenance takes place shortly upon broadcasting that
the third condition is met, whereby the reference key is reset and a new value for
Dα
403 is input, such that the above algorithm may be recycled for the next optimum maintenance
threshold. In an alternative embodiment using data accumulators as opposed to a reference
bit key or in conjunction therewith, cumulative distance data
405 is accumulated in at least one data accumulator stored in NVRAM
204, which is compared to a distance broadcast threshold Dβ, for instance
2,000 miles or a metric equivalent, at step
601. Upon said accumulator data exceeding said broadcast threshold Dβ, control proceeds
to step
610 and the accumulator data is reinitialised for further accumulation and comparison
to threshold Dβ until such time as the condition is again met, and so on and so forth.
[0045] It will be understood by those skilled in the art that the above ratios are provided
herein by way of example only, and that the present description is not limited thereto.
Indeed, the reference key
409 may be implemented with more or less bits to accommodate respective number of differing
ratios, such as successive quarters or tenths of said threshold Dα
403. Likewise, said comparison is limited to distance data for the purpose of not unnecessarily
obscuring the present description, but it should be understood that it may instead
or also incorporate comparison of running time data T
406 against respective threshold Tα
404 to optimise vehicle maintenance intervals. Broadcasting cumulative distance D
405 to vehicle service provider
103 according to the present invention allows said provider to initiate maintenance proceedings
with the user of vehicle
101, removing the need for said user to remain aware of vehicle service intervals and
requirements throughout the useful life of the vehicle. Moreover, broadcasting cumulative
distance
D 405 according to ratios of threshold Dα
403 to vehicle service provider
103 allows said provider to accurately forecast numerous variables, such as vehicle maintenance
points based upon mileage, corresponding parts to order, required staffing levels
and expected amount of business over given periods.
[0046] The data broadcasting step
511 is further detailed in Figure 7. Irrespective of whether a broadcasting event is
declared as a result of step
610 or upon receiving a data request at step
508, application
401 first fetches relevant data from memory
204 at step
701. Preferably, emitting module identification data
402, distance maintenance threshold data Dα
403 and cumulative distance data
D 405 are retrieved. Optionally, time maintenance threshold data Tα
404 and cumulative time data T
406 are retrieved also or instead. At step
702, application
401 outputs said retrieved data as formatted ASCII text, which it then encodes for broadcast
at step
703 by way of packing said formatted ASCII text into communicable data packets, preferably
but not necessarily as a SMS text message. At step
704, application
401 instructs modem
207 to dial phone number
410 and a question is asked at step
705 as to whether said modem
207 has successfully establishing a connection to the cellular telephone network. If
the question of step
705 is answered negatively, a wait instruction elapses an arbitrary time period at step
706 before control returns to said question
705, until it is eventually answered positively, whereby said data packets are sent to
the recipient over wireless data transmission
108, i.e. terminal
104 of vehicle service provider
103 at step
707. In the example, said data packets are relayed as a digital signal from module
102 in vehicle
101 by the geographically-closest communication link relay
109 of a plurality thereof. Said plurality of communication link relays allows said digital
signal to be routed between module
102 and terminal
104 by means of remote gateway
110.
[0047] An example of the terminal
104 at the vehicle service provider
103 shown in Figure 1 is provided in Figure 8. Terminal
104 is a computer terminal configured with a data processing unit
801, data outputting means such as video display unit (VDU)
802, data inputting means such as a keyboard
803 and a pointing device (mouse)
804 and data inputting/outputting means such as WAN connection
805, magnetic data-carrying medium reader/writer
806 and optical data-carrying medium reader/writer
807. Within data processing unit
801, a central processing unit (CPU)
808, such as an Intel Pentium
4 manufactured by the Intel Corporation, provides task co-ordination and data processing
functionality. Instructions and data for the CPU
808 are stored in main memory
809 and a hard disk storage unit
810 facilitates non-volatile storage of data and several software applications. A modem
811 provides a wired connection to the Internet
111. A universal serial bus (USB) input/output interface
812 facilitates connection to the keyboard and pointing device
803, 804. All of the above devices are connected to a data input/output bus
813, to which said magnetic data-carrying medium reader/writer
806 and optical data-carrying medium reader/writer
807 are also connected. A video adapter
814 receives CPU instructions over said bus
813 for outputting processed data to VDU
802.
[0048] In the embodiment, data processing unit
801 is of the type generally known as a compatible Personal Computer ('PC'), but may
equally be any device configured with data inputting, processing and outputting means
providing at least the functionality described above. Any such device may include,
but is not limited to, an iMac® computer manufactured by the Apple® Corporation of
Cupertino, California, USA; a Portable Digital Assistant (PDA) such as a Palm m
505® manufactured by PalmOne® Inc. of Milpitas, California, USA; a Portable Digital Computer
(PDC) such as an IPAQ® manufactured by the Hewlett-Packard® Company of Palo Alto,
California, USA; or even a mobile phone such as a Nokia
9500 manufactured by the Nokia® Group in Finland, all of which are generally configured
with processing means, output data display means, memory means, input means and wired
or wireless network connectivity.
[0049] Processing steps are described in Figure 9 according to which terminal
104 operates. Terminal
104 is first switched on at step
901. At step
902, the operating system is loaded which provides said terminal
104 with basic functionality, such as initialisation of data input and/or output devices,
data file browsing, keyboard and/or mouse input processing, video data outputting,
network connectivity and network data processing. At step
903, an application is loaded into memory
809, which is a set of instructions for configuring CPU
808 to process data according to rules described hereafter. A database is next loaded
at step
904, which organises application data referenced therein according to relational parameters.
[0050] A first question is asked at step
905, as to whether a broadcast has been received from a module
102, such as sent at vehicle
101 according to step
511. If the question of step
905 is answered positively, the application loaded at step
903 updates the database with the data received in said broadcast and notifies said update
to the user of terminal
104 at step
906, for instance with generating a database record form summarising vehicle details and
output to VDU
802, a user-selectable portion of which allows said user to notify the vehicle owner that
maintenance is required. Control proceeds to the next step
907, as it would if the question of step
905 was answered negatively, whereby a second question asked as to whether user input
has been received, for instance from keyboard
803 or mouse
804.
[0051] If the question of step
907 is answered negatively, control returns to step
905, whereby the next database update may then take place upon receiving another broadcast.
Alternatively, the question of step
907 is answered positively and a third question is asked at to whether the user input
corresponds to a request for a vehicle current distance D
405 or, optionally, current running time T
406. Such user input may for instance be provided as the selection a particular vehicle
or a criteria-based selection thereof in the database or even with selecting a 'refresh'
query instructing the application to poll every vehicle referenced therein, in the
absence of any module-initiated broadcast.
[0052] If the question of step
908 is answered positively, the application loaded at step
903 polls one or a plurality of modules
102 for broadcasting back said requested data at step
909, as previously described in steps
508, 511 of Figure 5, according to whether said user has selected one vehicle
101 or a plurality of vehicles
101,115. In the embodiment, said application broadcasts said poll command sequentially for
each vehicle if many were chosen, whereby a question is asked after each poll at step
910, as to whether another poll remains to be performed. If the question of step
910 is answered positively, control returns to step
909 whereby the next poll command is performed. Alternatively, question
910 is eventually answered negatively, whereby control returns to step
905. If the question of step
908 is answered negatively, however, control proceeds to step
911, wherein the application of step
903 processes database data according to user input and outputs said processed data to
VDU
802. Such user input may for instance be provided as the initialising of a new database
vehicle record when a new vehicle is sold, the selection of a 'forecast' query instructing
the application to select every vehicle referenced in the database, the respective
distance D
405 and/or threshold Dα of which matches forecasting parameters or, in accordance with
the above description, the selection of a vehicle user notification command.
[0053] A question is therefore asked at step
912, as to whether said user input is a user notification command. If question
912 is answered affirmatively, control proceeds to step
909 such that a broadcast may be sent to said user, with retrieving said user contact
details in said database and calling upon modem
811 to send a SMS text message requesting the arrangement of vehicle maintenance. In
an alternative embodiment of the present invention, the application of step
903 is configured to send an electronic mail message to the electronic mail address of
said user over the Internet, which is preferably also stored in said database. Alternatively,
question
912 is answered negatively, whereby a final question is asked at step
913, as to whether said user input is an application close command. If the question of
step
913 is answered negatively, control returns to step
905, whereby the next database update may then take place upon receiving another broadcast.
Alternatively, the question of step
913 is answered positively and the application is closed and unloaded from memory
809 at step
914. Terminal
104 may thus be eventually switched off at step
915. It will be understood by those skilled in the art that the above-described types
of user input are provided by way of example only and are not limited thereto.
[0054] The contents of the memory
809 of terminal
104 are shown in Figure 10 further to carrying out the database loading step
904 and whilst application closing step
914 is not selected, i.e. at application run time. Memory
809 first contains an operating system
1001 as loaded according to step
902, embodying the set of basic CPU instructions previously described in Figure 9. Memory
809 next contains a communications manager
1002 also loaded according to step
902, embodying the set of CPU instructions required to call upon the functionality of
modem
811 and emit and receive network data. Memory
809 also contains an application
1003 as loaded according to step
903, embodying the set of CPU instructions according to which data broadcast by module
102 and referenced in database
1004 is processed. In a particular embodiment of the present invention, application
1003 is known as AutoCall© and manufactured and distributed by the present Assignee. Said
data received from any module
102 at step
905 is shown at
1005 as incoming SMS text messages and at
1006 as parsed runtime data, which is the data extracted from message
1005 by application
1003 with which it updates database
1004 at step
906. Database data processed according to the user input of steps
908, 911, for instance according to the processing parameters declared in the various database
queries described in Figure 9, is shown at
1007. Memory
809 also stores data broadcast by application
1003 as either module polls
1008 according to steps
908, 909, outgoing SMS text messages
1009 to vehicle users according to steps
912, 909 and in an alternative embodiment, electronic mail
1010 to vehicle users.
[0055] An example of the database
1004 is described in Figure 11. Database
1004 is shown in a table form, which references and organises stored and received vehicle
data in relation to the unique module ID
402 of each module
102. Each of the plurality of vehicles
115 respectively configured with modules
102 is thus referenced in database
1004 as an individual record with a unique identifier in the [vehicle_ID] column
1101, in the example identifiers
402, 1102, 1103 and
1104. In order to facilitate the various aspects of vehicle maintenance, which may vary
according to the make, model and usage history of any vehicle, it is preferable for
database
1004 to reference said make, model, cumulative distance D
405, maintenance threshold distance Dα
403 and vehicle owner contact details in respective columns [make]
1105, [model]
1106, [cumul_ dist]
1107, [threshold_dist]
1108 and [contact]
1109. In an alternative embodiment, database
1004 also references cumulative running time T
406 and maintenance threshold time Tα
404 in respective columns [cumul_ time]
1110 and [threshold_time]
1111. Preferably, stored distance data and optional time data is formatted in respective
columns
1107, 1108 and
1110, 1111 according to the format in which said data is stored and broadcast by module
102.
[0056] The graphical user interface (GUI) of application
1003 is shown in Figure 12 upon completing the database loading step
904 of Figure 9. GUI
1201 is output to VDU
802 by CPU
808 outputting data to video adapter
814. GUI
1201 first includes a device pointer
1202 having two-dimensional (x,y) screen co-ordinates, which the user of terminal
104 may translate by imparting a two-dimensional (x,y) motion to mouse
804, whereby said two-dimensional (x,y) motion input data is routed by OS
1001 to application
1003 for processing and then updating said screen co-ordinates if required. GUI
1202 is preferably subdivided into a variety of user-selectable menu commands, for instance
on-screen graphical representations of the various queries described in Figure 9.
Upon said user translating pointer
1202 over any of said menu commands and providing an interrupt, such as with effecting
a mouse button click or a key stroke, application
1003 processes motion input data, correlates the position of said pointer with on-screen
menu command positions, then processes database data according to the parameters of
the selected query. In the example, a non-exhaustive variety of processing functions
provided of application
1003 are represented in GUI
1201 as user-selectable menu commands 'Add Car'
1203, 'Query Car'
1204, 'Query All Cars'
1205, Forecast'
1206 and Notify'
1207. Processed data is thus output to VDU
802 according to step
911.
[0057] The database updating step
906 is further detailed in Figure 13. At step
1301, application
1003 parses an incoming broadcast
1005 to generate runtime data
1006, which it may process. The received unique ID
402 of the emitting module
102, cumulative distance D
405 and threshold distance Dα
403 are thus read and, optionally, the cumulative running time T
406 and the threshold distance Tα
404 are also read or read instead.
[0058] At the next step
1302, application
1003 matches the unique ID
402 of the emitting module
102 to its corresponding database record with looking up the [vehicle_ID] column
1101. Upon establishing said match, a first question is asked at step
1303, as to whether the value of the received cumulative distance
D 405 exceeds the corresponding value stored in the column [cumul_dist]
1107. If the question of step
1303 is answered positively, application
1003 replaces the value stored in the column [cumul_ dist]
1107 with the value of said received cumulative distance D
405 at step
1304, such that the record of the vehicle in the database is updated. Alternatively, the
question of step
1303 is answered negatively, whereby a second question is asked at step
1305 as to whether the value of the received threshold distance Dα
403 exceeds the corresponding value stored in the column [threshold_dist]
1108. If the question of step
1305 is answered positively, application
1003 replaces the value stored in the column [threshold_dist]
1108 with the value of said received threshold distance Dα
403 at step
1306, such that the record of the vehicle in the database is updated. For instance, question
1305 is answered positively after a vehicle has been maintained and a new Dα value has
been input at step
308, thus avoiding the need for double data entry and the inherent risk of discrepancy
between then two entries. Alternatively, the question of step 1305 is answered negatively
whereby, in an alternative embodiment, a third question is asked at step
1307 as to whether the value of the received cumulative running time T
406 exceeds the corresponding value stored in the column [cumul_ time]
1110. If the question of step
1307 is answered positively, application
1003 replaces the value stored in the column [cumul_ time]
1110 with the value of said received cumulative running time T
406 at step
1308, such that the record of the vehicle in the database is updated. Alternatively, the
question of step
1307 is answered negatively, whereby a fourth question is asked at step 1309 as to whether
the value of the received maintenance threshold time Tα
404 exceeds the corresponding value stored in the column [threshold_time]
1111. If the question of step
1305 is answered positively, application
1003 replaces the value stored in the column [threshold_time]
1111 with the value of said received threshold running time Tα
404 at step
1310, such that the record of the vehicle in the database is updated. Again, question
1309 is answered positively after a vehicle has been maintained and a new Tα value has
been input at step
309. Upon completing the above data updating, application
1003 generates a database record form at step
1311, which it populates with all or a relevant portion of the data relating to the matched
unique ID
402 of the emitting module
102 and subsequently outputs to VDU
802 at the next step
1312, an example of which is described further below.
[0059] The database data processing step
911 is further detailed in Figure 14. At step
1401, a first question is asked as to whether the user input identifies a command to create
a new record, such as when a new vehicle is sold. If the question of step
1401 is answered positively, application
1003 increments the database record count, wherein a new unique ID
402 is generated in the [vehicle_ID] column
1101 and keyboard input is read in order to update columns [make]
1105, [model]
1106, [threshold_dist]
1108 and [contact]
1109 at step
1402. In an alternative embodiment, keyboard input is read in order to update column [threshold_time]
1111. It is preferable for the user not to be allowed to input data to be referenced in
columns [cumul_dist]
1107 and [cumul_time]
1110, as such data should only be generated by module
102 to circumvent any form of odometer tampering. According to the present invention,
correlation between distance data broadcast by module
102 stored in database
1004 and actual odometer value in vehicle
101 is not required, as trials of the preferred embodiment have shown the error to be
normally not greater than
1.52%, thus wherein module
102-generated distance data is in the order of
1.52% less than vehicle odometer data, i.e.
152 miles in every
10,000 miles, which is trivial. Control subsequently proceeds to step
912.
[0060] Alternatively, the question of step
1401 is answered negatively, whereby a second question is asked at step
1403, as to whether the user input identifies a command to process database data to retrieve
records according to parameters, such as when a forecast database query is selected.
If the question of step
1403 is answered positively, application
1003 processes said database data according to said parameters. In the example, application
1003 returns database records where the difference between cumulative distance D
405 and maintenance threshold distance Dα
403 represents a percent or less of said maintenance threshold distance Dα
403, i.e. when a vehicle will shortly require maintenance. It will be understood by those
skilled in the art that this example is not limitative and may indeed be extended
to the alternative running time-based embodiment herein described, or to many more
parameters and/or subdivisions and/or combinations thereof. Again, control proceeds
to step
912.
[0061] Alternatively, the question of step
1403 is answered negatively, whereby a third question is asked at step
1405, as to whether the user input identifies a command to notify a vehicle user that vehicle
maintenance is required. If the question of step
1405 is answered negatively, user input is ignored and control again proceeds to step
912. Alternatively, the question of step
1405 is answered positively, whereby application
1003 processes said database data according to said parameters at step
1406. In the example, application
1003 looks up the [vehicle_ID]
1101 value of the user-selected database record and generates a message, preferably filling
a pre-existing template with corresponding record data read from columns [make]
1105, [model]
1106, [cumul_dist]
1107 and [threshold_dist]
1108. Application
1003 then provides the data stored in the corresponding column [contact]
1109 to the communications manager
1002 with a command to broadcast the message according to steps
909, 910 at step
1407, whereby control proceeds to step
912.
[0062] The graphical user interface
1201 of application
1003 is shown in Figure 15 upon performing either of the processing steps
906, 911. In the example, the user of terminal
104 calls application
1003 to process database data according to a forecast query as described at steps
1403, 1404 with translating pointer
1202 over menu command
1206 and effecting a mouse click. Application
1003 thus processes database data according to step
911, whereby results are output to VDU
802 in GUI
1201 as a table
1501 of matching records. Each of said matching records is uniquely identified by its
unique ID
402, 1102, 1104 in column [vehicle_ID]
1101. Moreover, the respective, relevant maintenance data of each of said matching records
is output in columns [cumul_ dist]
1107 and [threshold_dist]
1108, such that the user of terminal
104 may prioritise vehicle user notification according to the variation between said
cumulative and maintenance distances, if required. Application
1003 preferably outputs said table
1501 with a user-selectable Notify' menu command
1502 for each matching record, whereby the user of terminal
104 may translate device pointer
1202 over any such menu command
1502 and provide an interrupt as previously described, in order to answer the question
of step
1405 positively. In the example the module
102 having a unique device ID
1103 in column [vehicle_ID]
1101 broadcasts an update to terminal
104 according to step
511, for instance having met the distance comparison condition asked at question
604. Accordingly, application
1003 receives and processes said update according to steps
905, 906, whereby a database record form is generated at step
1311, populated with the unique ID
1103 of the emitting module
102 in column [vehicle_ID]
1101 and maintenance data of the vehicle in columns [cumul_ dist]
1107 and [threshold_dist]
1108. Said form is subsequently output as form
1503 within GUI
1201 to VDU 802 at the next step
1312. Preferably, said form is a pop-up form or window (if OS
1001 supports multiple windowed tasks) to focus the attention of the terminal user upon
the event. Preferably still, application
1003 configures form
1503 with user-selectable 'Notify' menu commands
1504 and 'Cancel'
1505, whereby the user of terminal
104 may translate device pointer
1202 over menu command
1504 and provide an interrupt as previously described, in order to answer the question
of step
1405 positively. In the example, the user translates device pointer
1202 over menu command
1505 and provides an interrupt as previously described in order to answer the question
of step
1405 negatively, as the vehicle does not yet require maintenance.
[0063] It will be appreciated that the operation of the invention is not limited to GPS
systems, other positioning systems can be used, for example GNSS and Galileo are systems
which can be used to implement the present invention. Furthermore the invention can
be carried out using any self locating system, for example technology used in Mobile
phone telecommunication technology. Additionally the invention should not be limited
to vehicles per se as the invention can be incorporate into mobile machinery or equipment
which require maintenance.
[0064] It will also be appreciated that some aspects of the present invention can be used
to assist in customer retention, mileage certification for use in example determining
business miles travelled, insurance purposes, NCT or MOT testing purposes. The data
gathered can be used for forecasting when a parts replacement is due in a vehicle.
[0065] The words "comprises/comprising" and the words "having/including" when used herein
with reference to the present invention are used to specify the presence of stated
features, integers, steps or components but does not preclude the presence or addition
of one or more other features, integers, steps, components or groups thereof.
[0066] The embodiments in the invention described with reference to the drawings may comprise
a computer apparatus and/or processes performed in a computer apparatus. However,
the invention also extends to computer programs, particularly computer programs stored
on or in a carrier adapted to bring the invention into practice. The program may be
in the form of source code, object code, or a code intermediate source and object
code, such as in partially compiled form or in any other form suitable for use in
the implementation of the method according to the invention. The carrier may comprise
a storage medium such as ROM, e.g. CD ROM, or magnetic recording medium, e.g. a floppy
disk or hard disk. The carrier may be an electrical or optical signal which may be
transmitted via an electrical or an optical cable or by radio or other means.
[0067] The invention is not limited to the embodiments hereinbefore described but may be
varied in both construction and detail.