Field of the Invention
-
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
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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
-
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
-
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
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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
-
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
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
Dn = √ (A x A + B x B)
Where
A = [69.1 x (Xn - Xn-1)]
B = [53.0 x (Yn - Yn-1)]}
-
The accuracy provided by the above calculation may be increased if CPU 205 can
process cosine functions, whereby:
Dn = √ (A x A + B x B)
Where
A = [ 69.1 x (Xn - Xn-1) ]
B = { 69.1 x (Yn - Yn-1) x [ cos(Xn-1 / 57.3) ] }
-
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.
-
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.
-
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.
-
Alternatively, the question of step 510 is answered negatively and, in the absence of
user interrupt of step 312, control returns to step 503.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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 m505® 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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
The invention is not limited to the embodiments hereinbefore described but may be
varied in both construction and detail.
