EP2646994B1

EP2646994B1 - Vehicle communications

Info

Publication number: EP2646994B1
Application number: EP20110799261
Authority: EP
Inventors: Roderick Whitlock
Original assignee: Tracker Network UK Ltd
Current assignee: Tracker Network UK Ltd
Priority date: 2010-11-29
Filing date: 2011-11-29
Publication date: 2015-05-20
Anticipated expiration: 2031-11-29
Also published as: GB201020151D0; GB2486163A; EP2646994A1; WO2012072653A1; ES2544443T3

Description

Field

The present invention is in the field of vehicle communications and particularly, but not exclusively, it relates to communications between vehicles for the purposes of information propagation.

Background

As used herein, a "vehicle" can be any kind of motor vehicle, such as a car, lorry, motor cycle, train, coach or ship. In addition, a vehicle can be any kind of container, which may be carried, for example, by any kind of motor vehicle. In the broadest sense, a vehicle can be any movable object, including inanimate objects and also humans and animals, in or on which a communications unit of the kind described herein may be mounted or carried.
Some embodiments of the present invention find application in the field of stolen vehicle recovery (SVR). Some other embodiments of the invention find application in vehicle recall, for example, when a vehicle manufacturer needs to recall a make of motor vehicle to fix a fault. Other embodiments of the invention relate to vehicle status determination.
A generally known SVR system is illustrated in FIG. 1. One kind of commercially available SVR product is TRACKER Locate™, produced and sold by TRACKER Network (UK) Limited. In such a known SVR system, a vehicle-mounted transceiver unit (VMTU) is installed into a vehicle 115, and can be activated, for example by wireless radio activation signals, when the vehicle is reported by the owner as having been stolen. Once active, the VMTU emits a periodic radio signal, which can be detected by police vehicle mounted detection units. More particularly, when informed of a vehicle theft, a central SVR control system 100 can communicate with and activate the VMTU (not shown) of the stolen vehicle 115 via a cellular network of radio transmitters 105, 110. The communications for activating a VMTU may employ a suitable kind of wireless communications, for example, GSM, GPRS or UMTS, to name only a few options, and may employ cellular technology of the kind typically associated with mobile telephone handsets.
Products such as TRACKER Locate have proved particularly successful at facilitating the detection and recovery of stolen vehicles. However, the capital cost of installing and maintaining a network of radio towers, and the per-unit costs of radio-enabled VMTUs and police-vehicle-mounted detection units, are relatively high.
US6792351 discloses a method and apparatus for multi-vehicle communication in which a message that is received at a vehicle may be relayed to other vehicles.

Summary

According to a first aspect, the present invention provides a communications apparatus for a vehicle, the apparatus comprising:

a first store to store a home vehicle identifier, for identifying a home vehicle on or in which the apparatus is operating;
a receiver to receive messages directly from message sources in the proximity of the home vehicle;
a second store to store at least one target vehicle identifier;
a transmitter to transmit messages directly to message destinations in the proximity of the home vehicle; and
the apparatus being adapted to:
- receive from a message source a message containing a target vehicle identifier and store the target vehicle identifier in the second store;
- compare a received target vehicle identifier with the home vehicle identifier in order to establish whether the home vehicle is the respective target vehicle; and
- in response to establishing that the home vehicle is not the respective target vehicle, propagate the received message to one or more message destinations;
- characterised in that the apparatus is adapted to:
  - receive a response to a propagated message from a message destination and determine on the basis of the response that the respective message destination is a target vehicle.

As used herein, 'propagate' means that a message source can over time communicate a message to multiple destinations, whereby each destination can over time communicate the message on to multiple other destinations, and so on. Each message source may communicate the same message a plurality of times, for example, repeatedly, periodically, aperiodically, randomly or in response to a trigger of some kind, so that, over time, plural different destinations have the opportunity of receiving the message. Such communications can also be referred to as 'viral communications'.

Brief Description of the Drawings

Various features and advantages of the invention will become apparent from the following description of embodiments of the invention, given by way of example only, which is made with reference to the accompanying drawings, of which:

Figure 1 is a schematic diagram of a known stolen vehicle recovery system;
Figure 2 is schematic diagram of an exemplary scenario and system suitable for performing stolen vehicle recovery according to an embodiment of the present invention;
Figure 3 is a functional block diagram of an exemplary optical initiation and reception point, according to an embodiment of the present invention;
Figure 4 is a functional block diagram of an exemplary optical vehicle mounted transceiver unit, according to an embodiment of the present invention;
Figure 5a is a diagram of an exemplary stolen vehicle recovery request message, according to an embodiment of the present invention;
Figure 5b is a diagram of an exemplary stolen vehicle recovery response message, according to an embodiment of the present invention;
Figure 5c is a diagram of an exemplary vehicle recall message, according to an embodiment of the present invention;
Figure 6a is a flow diagram representing the exemplary operation of a central computer system and an optical initiation point, according to an embodiment of the present invention;
Figure 6b is a flow diagram representing the exemplary operation of an optical vehicle mounted transceiver performing stolen vehicle recover, according to an embodiment of the present invention;
Figure 7 is a flow diagram representing the exemplary operation of an optical vehicle mounted transceiver performing vehicle recall, according to an embodiment of the present invention;
Figure 8a is a diagram of an exemplary status request message, according to an embodiment of the present invention; and
Figure 8b is a diagram of an exemplary status request message, according to an embodiment of the present invention.

Detailed Description

Various embodiments of the present invention will now be described in more detail with reference to the accompanying drawings. It will be appreciated that the invention is not limited in its application to the details of method and the arrangement of components as set forth in the following description or illustrated in the drawings. It will be apparent to a person skilled in the art that additional embodiments of the present invention not detailed in the description are possible and will fall within the scope of the present claims. Accordingly, the following description should not be interpreted as limiting in any way, and the scope of protection is defined solely by the claims appended hereto.
With reference to the diagram in Fig. 2, an SVR embodiment of the invention dispenses with a cellular network of radio towers. Radio communications are replaced in this embodiment with optical communications. SVR messages are communicated virally to optical VMTUs (OVMTUs) either by initiation points or by OVMTUs mounted on or in other vehicles. According to the embodiment, each OVMTU handles SVR messages according to basic logic, which takes the form:

For each SVR message received by an OVMTU:
- Is a target vehicle identified in the received message the vehicle in which the recipient OVMTU is mounted?
  - If 'yes', then generate and send a response message indicating that the recipient vehicle is the target vehicle (that is, the message indicates that the recipient OVMTU is mounted in a stolen vehicle);
  - If 'no', then propagate the message.

In this manner, the nature of the message, or at least a portion of it, is determined by the result of the comparison between the target vehicle identified in the received message and the identity of the vehicle in which the OVMTU is mounted. In this example, at least a target vehicle identifier would be expected to appear in both kinds of message.
Referring to Fig. 2, a central computer system 200 is in communication with at least one initiation point 210 via a network 205. The central computer system 200 is, for example, a PC-based system operating under a Windows™ operating system and performing SVR operations according to SVR application software. In operation, for example, an operator of the central computer system 200 may receive a message from an owner of a stolen vehicle, via a telephone call, and control the central computer system 200 to match the owner and vehicle registration details against a database (not shown) containing a pre-registered and associated unique vehicle identifier (for example, a vehicle identification number, or VIN). The central computer system 200 may then communicate the unique vehicle identifier to the initiation point 210, via the network 205.
In principle, for embodiments of the invention to operate, as will become apparent from the following description, it is only necessary to have a single initiation point acting as a source of message propagation. However, embodiments of the invention typically have a plurality of initiation points, distributed according to considerations such as geography, vehicle traffic characteristics and speed of detection requirements.
The network 205 may be a proprietary network or a public network such as the Internet. In some embodiments, some or all of the initiation points may be in communication with the central computer system 200 using wireless transmissions, for example employing a GSM cellular radio network (not shown), whereby the initiation points are equipped with radio receivers arranged, for example, to receive standard SMS messages or the like. As will be understood and appreciated, any alternative kind of communications standard and system could be employed to facilitate communications between a central computer system and associated initiation points.
According to the present embodiment, as will be described in further detail hereinafter, an initiation point 210 generally comprises means for receiving messages from the central computer system 200 and means for generating respective optical signals to be transmitted by an optical transmitter 215 to vehicles that pass by the initiation point 210.
Fig. 2 also illustrates an exemplary road system, including a two-way, West/East carriageway 230, on which vehicles 240 can travel from West to East on the North side of the road and from East to West on the South side of the road. The road is shown having roadside verges 225 and a central reservation 215. The road system includes a junction at which a North/South carriageway 235 joins the West/East carriageway 230 from the South.
As shown in Fig. 2, the initiation point 210 is located at the roadside 225 on the North side of the West/East carriageway 230, and the associated optical transmitter 215 is mounted on top of a mast 220 and is arranged to direct optical signals in a generally Westwardly direction into the path of vehicles 240 travelling East on the West/East carriageway 230. More generally, it will be appreciated that an optical transmitter of the kind described herein could be arranged to emit optical signals in any direction, or in substantially all directions, in order to enable receipt of optical signals by vehicles travelling in any direction in relation to the location of the initiation point. Initiation points may be at convenient fixed locations, for example at the roadside, at motorway intersections, mounted on gantries over roads, or railways, at petrol stations, at regional or national borders, or in motorway service stations. Alternatively, or in addition, initiation points may be mobile, for example employing equipment mounted in police vehicles, other emergency vehicles, haulage vehicles or the like. Of course, mobile initiation points would tend to be in communication with a central computer system via wireless communications.
There are five vehicles depicted on the road system in Fig. 2, variously acting and message sources and/or message destinations, as will be described. Of the vehicles, two (labelled A and C) are travelling East on the West/East carriageway, two (labelled B and D) are travelling West, and one is stationary (labelled E) at the junction, its having arrived from the South. For the present purposes, each of the five vehicles has on-board an OVMTU, the details of which will be described in detail hereinafter.
As shown in Fig. 2, the initiation point 210 is transmitting an optical SVR signal 250 to vehicle C. The optical signal 250 includes a stolen vehicle identify (SVID) request including an identifier I, which identifies a stolen vehicle. As will be appreciated from Fig. 2, moments before communicating with vehicle C, the initiation point 210 had transmitted the same optical SVR signal 250 to vehicle A, as vehicle A had passed the initiation point 210. Vehicles A and C are labelled as A(I) and C(I), to indicate that they have both stored the stolen vehicle identifier I, which was received from the initiation point 210. With respect to the initiation point, acting as a message source, vehicles A and C are message destinations.
Fig. 2 also shows vehicle A transmitting, via an optical SVR signal 255, an SVID request including the identifier I to vehicle D. Again, moments earlier, vehicle A had transmitted the same SVID request to vehicle B. Vehicles B and D are labelled as B(AI) and D(AI), to indicate that they have received, via vehicle A, and stored the stolen vehicle identifier I. In this scenario, vehicles B and D are message destinations with respect to vehicle A, and vehicle A is acting as a message source with respect to vehicles B and D.
Additionally, Fig. 2 shows vehicle B transmitting, via an optical SVR signal 260, the identifier I to vehicle E. Vehicle E is labelled as E(BAI) to indicate that it has received, via vehicles A and then B, and stored the stolen vehicle identifier I. In this scenario, vehicle E is a message destination with respect to vehicle B, and vehicle B is a message source with respect to vehicle E.
Finally, Fig. 2 shows vehicle E transmitting, via an optical SVR signal 265, an SVR response signal indicating that its identity matches the identity I of the stolen vehicle. In this scenario, the roles have reversed and vehicle E is a message source with respect to vehicle B, and vehicle B is a message destination with respect to vehicle E.
To summarize, as shown in Fig. 2, a stolen vehicle has been identified by a sequence comprising only four optical signals: initiation point 210 → vehicle A; vehicle A → vehicle B; vehicle B → vehicle E; and vehicle E → vehicle B. In this example, each vehicle (or, indeed, its respective OVMTU) can act as a message source or a message destination, respectively, depending on whether it is sending or receiving messages. Of course, more than four optical signals and messages may have been transmitted (but not necessarily received) in order to achieve four successfully-received transmissions.
It will be appreciated that the probability of identifying a stolen vehicle within the proximity of a single road junction, as depicted in Fig. 2, is relatively low (though not impossible!). Nevertheless, it will also be appreciated that the propagation of a stolen vehicle identity I from an initiation point and then from vehicle to vehicle could be extremely rapid, especially in metropolitan areas in which vehicle density is relatively high. Given strategic placement of one or more initiation points throughout a given geography (for example, a village, a town, a city, a state, a country or even several countries or a continent), and a reasonable number of vehicles each carrying an OVMTU, it is conceivable that an entire geography could be saturated with an identity I within a matter of hours or days. In this manner, SVR can be facilitated without the need for a network of radio transmitters, and that part of a known SVR infrastructure can therefore be entirely dispensed with.
The diagram in Fig. 3 illustrates in more detail the functional components of an exemplary initiation point 210 according to an embodiment of the present invention. As will be described later on herein, an initiation point can receive messages as well as propagate them. As shown, the initiation point 210 comprises a microprocessor (or processor) 305, an optical receiver circuit 310 driven by a photo diode 312, an optical transmitter circuit 315 driving a light emitting diode (LED) 317, main memory 320 containing at least a store 322 for SVID requests, a program memory 325 for storing program code for controlling the operation of the initiation point 210, a network interface 330 for connecting the initiation point 210 to the network 205, a management interface 335, by which an operator or service engineer can connect to the initiation point 210 for updating or maintenance purposes.
Alternatively, an operator or service engineer can communicate with the initiation point 210 via the network interface, by logging in and using a remote control console or the like in a known way.
Also provided is a real time clock 340.
The components in the exemplary initiation point 210 are connected by an appropriate interconnect or BUS arrangement 307.
The processor 305 of the initiation point 210 may be an embedded processor, which performs functions according to firmware instructions that are stored in and loaded from the program memory 325. The main memory 320 may be volatile RAM or non-volatile EEPROM, while the program memory may be non-volatile EEPROM or ROM. In some embodiments, the main memory 320 and the program memory 325 may both comprise EEPROM, which would beneficially mean that data is not lost during a power outage. In some embodiments, the entire functionality of the initiation point (apart from, perhaps, electronic components for driving the photo detector and LED) is embodied in a single bespoke application specific integrated circuit (ASIC). Of course, the functionality may instead be deployed in any appropriate manner. For example, in this or in any other embodiment, received data can be stored in processor registers in addition to, or instead of, in main memory, or in any other kind of storage element(s).
The processor 305 is programmed to receive, from the central computer system 200, SVID, requests, each including a unique SVID, and store each received SVID request in the SVID store 322. Then, periodically, the processor reads the SVID request(s) from the SVID store 322 and causes the transmitter 315 to transmit associated SVID requests to passing vehicles, in order to propagate the SVID An exemplary messaging protocol for communicating SVID requests will be described in more detail hereinafter.
It will be appreciated that one or more SVID requests, associated with stolen and not-yet-detected vehicles, may be 'active' at any time and stored by the initiation point 210, and the plural SVID requests may then be transmitted one after another to passing vehicles. In practical terms, this may of course mean that one passing vehicle only receives one, or a subset, of all active SVID requests that are being sequentially transmitted. If this is the case, then, over time, it is expected that plural passing vehicles would, between them, and in the aggregate, receive all SVID requests, in order that all SVID requests may be propagated according to embodiments of the invention.
In this exemplary embodiment, the presence of a vehicle is not detected as such and so the time between consecutive transmissions of each SVID request is arranged to be relatively short, in order to maximise the chance that all (or at least some but preferably a majority of) passing vehicles that are capable of receiving the SVID requests do so. For example, each SVID request may be transmitted ten times per second, for example, every 0.1 seconds. The time between transmitting different SVID requests may be far shorter, for example with a 0.02 second gap, to ensure that each passing vehicle receives a maximum number of different SVID requests. The frequency of the transmissions may be adjusted, however, depending on the anticipated speed of passing vehicles. For example, the period between transmissions may be longer if the initiation point is located at a junction where vehicles slow down. In contrast, the period between transmissions may be shorter if the initiation point is located next to a motorway on which vehicles travel quickly. In some embodiments, an initiation point may include a movement detector (not shown), which is capable of detecting when a vehicle is approaching the initiation point and only then triggering a transmission of the SVID requests.
According to the present embodiment, the LED 317 is a relatively high power infra-red LED operating at 940nm, and including an appropriate focusing lens and reflector arrangement to ensure that the maximum optical power is focused and transmitted in the direction of the approaching vehicle. The optical wavelength is similar to that employed by infra-red remote control devices. However, other operating wavelengths could be used, for example 880nm. Indeed, any operating wavelength of light could be employed, although it is anticipated that only wavelengths that are imperceptible to humans and animals would be employed. In other embodiments, the optical signals may be generated by modulating visible light that is emitted by standard headlamps when they are switched on. The modulation is made sufficiently fast as to be imperceptible to humans, and thereby not distracting or indicative of active signalling.
The optical communications are performed by modulating data onto an optical carrier signal. The details of such optical communications are extremely well known and will not be described herein.
The diagram in Fig. 4 illustrates in more detail the functional components of an exemplary OVMTU 400. As shown, the OVMTU 400 comprises a microprocessor (or processor) 405, a comparator 406, an optical receiver unit 410 driven by a photo diode 412, an optical transmitter unit 415 driving a light emitting diode 417, main memory 420, a program memory 425 for storing program code for controlling the operation of OVMTU, a code generator 430, a management interface 435, via which the OVMTU can be configured for installation into a particular vehicle, and an indicator 445. The indicator 445 may be any kind of audible alarm, flashing light, graphical display or similar that is suitable for notifying a driver of the vehicle that a stolen vehicle has just been detected.
The main memory 420 contains at least a store 421 for SVID requests, a store 422 for a home vehicle identifier (HVID), a store 423 for an optional coding key (CodKey) and a store 424 for a stolen vehicle register (SVREG). A HVID is the identifier of the vehicle in (or on) which the OVMTU is mounted. While according to the present embodiment a store is typically a location in a memory element, it could equally be a register in a processor element or any other suitable data retention element.
The components in the exemplary OVMTU 400 are connected by an appropriate interconnect or BUS arrangement 407.
The processor 405 and memory 420, 425 may be similarly specified to the equivalent components in the initiation point 210. HVID and CodKey data at least should be stored in non-volatile memory. Thus, if the main memory 420 comprises volatile RAM, the HVID and CodKey data may instead be stored in the program memory 425 or in an alternative (not shown) non-volatile memory store. Again, in some embodiments, all or a majority of the functionality of the OVMTU is embedded in an ASIC.
In a practical embodiment, a main part of an OVMTU 400 typically comprises a sealed casing containing a majority of the processing elements, a power input and inputs for receiving wired connections from the optical transmitter 415 and receiver 410 units. The main part of the OVMTU 400 may be concealed in any appropriate location, for example in the engine compartment, in the boot (or trunk), under the vehicle or in the passenger compartment. Alternatively, the OVMTU may form one of the standard subsystems of a vehicle, and, as such, be installed during manufacture rather than being, for example, a retro-fitted item.
Meanwhile, optical transmitter 415 and receiver 410 units are arranged so that the optical diode 412 and LED 417 are mounted within a light cluster unit, for example, of the headlights or tail lights (or both) of a vehicle. In some embodiments, the headlight and/or tail light clusters of a vehicle are manufactured to include optical transmitter and receiver units that are suitable for connection to the main part of a respective OVMTU. Of course, the transmitter and receiver units could be mounted in various different ways and in various different places. For example, as the optical transmissions are not visible, a transmitter could be mounted within the passenger compartment of a vehicle, and effectively radiate invisible light in all directions. In other embodiments, the optical transmitter and/or receiver may be mounted on or in the rear-side of a rear view mirror, facing outwardly forwards through the windshield. Other alternative arrangements can be envisaged.
According to the present embodiment, an exemplary OVMTU 400 is programmed to perform at least four operations:

SVID Reception: the OVMTU 400 acting as a message destination receives SVID requests from initiation points or from other OVMTUs and stores the requests in the SVID store 421.
SVID Comparison: the comparator 406 compares received SVIDs with the HVID and, if a received SVID is found to match the HVID of the OVMTU 400, the processor 405 generates a response transmission, to be sent to the source of the SVID request, indicating that the received SVID matches its HVID.
SVID Propagation: the OVMTU 400, acting as a message source, periodically transmits SVID requests to other OVMTUs or back to an initiation point.
SVID Notification: if, in response to having sent an SVID request to another vehicle, the OVMTU receives a response back indicating that the SVID matches an HVID of the recipient vehicle, the OVMTU causes the indicator 445 to indicate that a stolen vehicle has been detected.

On occasion, and without having propagated a particular SVID request, an OVMTU may receive from a stolen vehicle a response message indicating that an SVID matches the stolen vehicle's HVID (for example, the response may have been caused by an earlier SVID message from a different OVMTU). In this case, the recipient OVMTU still causes the indicator 445 to indicate that a stolen vehicle has been detected. In this way, any OVMTU can perform SVID notification, irrespective of whether or not it has previously received or transmitted a respective SVID request.
According to the present embodiment, as with the initiation points, the OVMTU 400 does not as such detect the presence of other vehicles, and the repetition rate of the SVID request messages is relatively high in order to ensure that other vehicles passing by are likely to receive the messages. In alternative embodiments, the OVMTU may be adapted to adjust repetition rate according to vehicle speed and/or detect other vehicles in the proximity of the vehicle in order to trigger the transmission of the SVID requests. One exemplary way of detecting home vehicle speed is to connect into a control area network (CAN) bus of the home vehicle, in order to detect a speedometer value of the home vehicle.
With regard to SVR Comparison, according to the present embodiment, an OVMTU is responsible for identifying whether it has a HVID that matches a received SVID and notifying the source of the SVID (or potentially any other passing OVMTU or initiation point) that there is a match. By adopting this approach an OVMTU can be arranged to generate a response only if there is a match, and not otherwise. This has the advantage of conserving vehicle battery power, particularly if the vehicle is not operating (for example, the engine is not running) in a manner that recharges the battery. In other embodiments, the OVMTU may instead return its HVID to the source of the SVID and leave it to the source to determine whether there is a match. In still other embodiments, the OVMTU may perform its own comparison to determine that there is a match and, in addition, confirm the match and return its HVID to the source. In general, embodiments of the present invention encompass any protocol that enables a source to perform SVR Notification.
SVR Notification in effect informs the driver of the vehicle that originated an SVID request (or which has received a response to an SVID request prompted by another OVMTU) that a stolen vehicle has been detected in the proximity of the stolen vehicle. The driver of the source vehicle is then able to, for example, contact the police or a designated call centre to provide information including the driver's location; thereby indicating the approximate location of the stolen vehicle. In some embodiments, the indicator 445 provides an indication including the SVID (or any other representation of the SVID or other identifier that can be correlated by the police or call centre operator with the stolen vehicle), which can be imparted to the police or call centre operator. It will be appreciated that, in reporting detection of the stolen vehicle, the driver does not necessarily know which car in his proximity has been stolen, and thus is not motivated to intervene or approach the stolen vehicle. Of course, over a short period of time, the stolen vehicle may communicate with a plurality of other OVMTUs, and the drivers of the respective vehicles may all contact the police or call centre. In this way, the police can map the progress of the stolen vehicle and calculate an optimal detection and interception location. In other embodiments, for example in which an OVMTU is mounted in a police car, the SVR Notification may be adapted to include details of the make and model of the detected stolen vehicle, so that a police officer can intervene, approach and recover the stolen vehicle. In yet other embodiments, the OVMTU may be adapted to respond to an SVID request, when there is a match, only if the respective vehicle has been non-operational (and stationary) for a period of time; for example for more than five minutes, or more than ten minutes. In this way, an SVR notification typically relates to a parked vehicle, and the reported location is expected to remain relatively accurate.
Other embodiments of the invention perform an additional (or alternative) operation by emitting optical stolen vehicle notification (OSVN) signals. In this operation, when an OVMTU determines, in response to a SVID request, that it is in a stolen vehicle, in addition to (or instead of) responding to the source, the OVMTU sets the SVREG register and, for as long as that register is set, repeatedly transmits an OSVN signal including the HVID/SVID, thereby effectively broadcasting an alert signal identifying that the respective vehicle has been stolen. In this way, the OVMTU proactively transmits signals (that is, it transmits plural signals without requiring an SVID request for each) indicating that the respective vehicle has been stolen. This is advantageous in a scenario in which there are plural active SVID requests in the system and not all vehicles are able to receive all SVID requests but are able to receive an OSVN signal and raise an SVR Notification. In this case, even a vehicle that has not received a particular SVID request is able to detect an OSVN signal from the respective vehicle, thereby increasing the likelihood of stolen vehicle detection and recovery. OVMTUs that operate in this way are typically also programmed to detect OSVN messages from other OVMTUs, and trigger an appropriate SVR Notification to the driver as described above. The SVREG register may remain set until the respective stolen vehicle is recovered, or it may remain set for a fixed period of time, for example an hour, which provides ample opportunity for the vehicle to be detected without draining the vehicle battery if it is parked and not operational.
Thus far, an OVMTU has been described in terms of a unit that is installed and mounted within a vehicle. In other embodiments, the functional operation of an OVMTU is performed by a standalone, portable unit, which can be attached to containers or carried by a person or animal. In some embodiments, a police officer or other official (or, in principle, anyone) who is concerned with detection, and perhaps being detected, may carry such equipment. A portable unit may operate in exactly the same way as an OVMTU, thereby extending the capability of an overall system to be used to detect stolen vehicles. One advantage of a portable unit is that it can be carried into areas that do not have a high throughput of vehicles, such as in a garage area or side-street, and can even be used to communicate SVID requests to vehicles that are parked away from the road. In some embodiments, a portable unit (or, indeed, a vehicle-mounted unit) that is carried by a police officer or other party associated with detection (rather than being detected), may dispense with SVR Comparison functionality.
The diagram in Fig. 5a illustrates the contents of an exemplary SVID, request 500. According to the present embodiment, the request 500 is generated at the central computer system 200 and comprises: an SVR designation 505, which in this embodiment indicates that the message is an SVID request 510; a target vehicle identifier 510, which, in this example, is an SVID, for example a VIN; a code 515 associated with the SVID, whereby the authenticity of the SVID can be checked; a value 520 indicating whether or not a recipient of the request should propagate the request; and an absolute end time 525.
The propagate value 520 may be YES or NO, wherein a NO means that the SVID request should not be propagated if the engine of the associated vehicle is not operating, for example, in order to conserve battery power. On the other hand, a YES means that the SVR request should be propagated even if the engine of the associated vehicle is not operating. It will be appreciated that the propagate value is an optional item of information, which may be advantageous in some embodiments for preventing a vehicle battery from being depleted.
The end time 525, which could instead be a time period or relative time rather than an absolute time, determines for how long initiation points and OVMTUs should propagate the request. When a time associated with an SVID request has expired, which is determined by reference to the real time clocks, OVMTUs and initiation points are arranged to delete the respective request. In this way, the overall system is prevented from propagating requests after a vehicle has been recovered, or in perpetuity. Requests that have not led to vehicle recovery can be re-issued by the central computer system, if desired.
The diagram in Fig. 5b illustrates the contents of an exemplary SVID response message 550, which is transmitted by an OVMTU, according to the present embodiment, if the SVID received in an SVID request matches the HVID. The response 550 includes a confirmation portion 555 indicating that the message relates to an SVR response; the HVID (for example the VIN code) 560; and a code 565 associated with the HVID, so that the authenticity of the response can be checked. In some embodiments, the SVID and/or HVID may be accompanied by a vehicle descriptor, for example a make, model, year, registration plate and/or colour.
According to embodiments of the invention, authentication of an SVID request (or, indeed, any other kind of request described herein) is advantageously performed in order to identify erroneous or fake SVID requests, which could otherwise be introduced into the system for malicious intent. Although authentication of this kind is most desirable, for example in order to prevent subversion of a system, it is not essential, and, in some embodiments, for example those which are not concerned with SVR matters, authentication may not be required. Nevertheless, for good measure, all embodiments described in detail herein employ SVID authentication of some kind in order to limit opportunities for subversion.
In some SVR embodiments, the central computer system 200 is responsible for generating and distributing the SVID or HVID code as part of an SVID request. The code may take one of many different forms, requiring various different kinds of encoding or decoding operation in order to perform authentication. For example, a code may simply be a hash code of known kind calculated over an SVID or HVID. As is well known, hash codes are typically generated as relative short, fixed length codes, which result from a numeric operation applied to an inputted SVID. Although such codes are typically not unique for all possible SVID codes, it will be appreciated that the chances of a so-called hash collision can be made sufficiently low, in order to satisfy a recipient that an SVID is genuine. In such cases, a code generator 430 of an OVMTU that receives an SVID request may apply the same hash encoding algorithm to an SVID as the central computer system, and compare the result with the received hash code in order to perform authentication (where a match indicates authentication and a non-match indicates the potential for a maliciously-introduced SVID request). In such simple cases, a CodKey 423, as such, may not be required, although the hash code generating algorithm, or at least an element of it, may be stored in non-volatile memory, in a way which allows it to be updated from time to time, for example, via the management interface 435.
In an alternative method of authentication, the code generator 430 may be arranged to perform a cryptographic hash operation, for example, employing a pre-shared encryption key (stored as CodKey 423) to generate a cryptographic hash code. The same key and algorithm would be employed by the central computer system and the recipient to generate the hash code from the SVID, in order to facilitate comparison and authentication. Again, a match would provide authentication and a non-match would indicate potentially malicious intent.
In another method still, the code may be an encoded version of the SVID, which can be decoded to reveal the original SVID. In such a case, the code generator 430 may perform the decoding operation, in order that the encoded SVID can be decoded and compared with the received and un-encoded SVID
In a further method, the SVID code may be a signature of the SVID, which is cryptographically generated by the central computer system using a secret key of a cryptographic key pair. Each OVMTU may then have the public key (stored as the CodKey 423) of the pair and be able to authenticate the certificate in a known way.
In general, data authentication techniques are well known and the skilled person would be able to apply the techniques mentioned above, and other techniques, for performing satisfactory authentication, if there is a need to.
The flow diagram in Figs. 6a and 6b exemplifies the operation of a system according to an embodiment of the present invention, in which vehicles are motor cars and SVIDs are VINs.
In a first step [block 600] a new SVID is entered into the central computer system 200, which generates [block 602] an SVID request 500 and communicates [block 604] the request to the initiation point(s) 210. In this embodiment, the SVID request includes a cryptographic hash code, which is generated by the central computer system 200. Considering just one initiation point 210 for the present purposes (though, as explained, there may be any number from one to many), it receives and stores the SVID request [block 606]. Then, periodically (for example, every 0.1 seconds), the processor 305 reads the SVID memory 322 and propagates the SVID request 608 by way of an optical signal 250. Then, the processor 305 checks [block 610] the end time 525 of the request and, if the associated end time 525 has timed-out or expired, the processor deletes [block 612] the SVID request from the memory 322. The process then iterates to block 608 to process and propagate any new and remaining SVID requests.
In a practical scenario, it will be appreciated that it is likely that there will be plural active SVID requests (that is, SVID requests that have been received and not timed-out). In this instance, the initiation points would propagate all active SVR requests in sequence.
The operation of an exemplary OVMTU 400 will now be described with reference to Fig. 6b. Each new SVID request 500 communicated by a source is received and stored [block 614] in SVID request memory 421. A new SVID request 500 may be received from an initiation point or from another OVMTU. The new SVID request 500 is authenticated [block 616], by using the code generator 430 and an associated key, which is stored in the CodKey memory 423, to perform a cryptographic hash operation over the received SVID 510 and compare the result with the received hash code 515. If the received SVID is not authentic, the associated SVID request is deleted from memory [block 618] and the process iterates to block 614 to wait for the next new SVID request. If the SVID is authentic, then the SVID 510 is compared [block 620] by the comparator 406 with the HVID, which is stored in the HVID memory 422 of the recipient OVMTU. If there is no match [block 622], then the process iterates to block 614 to wait for the next new SVID request. If, on the other hand, the SVID and HVID match, the OVMTU generates a response 550, which is communicated [block 626] in an optical signal 265, which is sent to and hopefully received by the source (either the initiation point or the other OVMTU). Finally, the process iterates to block 614 to wait for the next new SVID request. If the source does not receive the response (for example, it may be out of range by the time the response is generated and transmitted, then detection of the stolen vehicle may not happen until another OVMTU communicates the SVID to the stolen vehicle. In other embodiments, further optional actions may be adopted to increase the likelihood of stolen vehicle detection, as will be described below.
In a parallel operation, the OVMTU periodically (for example, every 0.1 seconds) reads the SVID requests 500 from the SVID request memory 421 and propagates them [block 628] in an optical signal 260 to be received by any nearby OVMTU (or initiation point that is capable of receiving signals as well as transmitting them) that is capable of receiving the requests. As part of this step, according to the present embodiment, if the vehicle engine is not running, the processor determines for each SVID request whether the respective propagate value 520 is set to YES or NO, and only propagates SVR requests that have a YES value. In any event, next, the OVMTU then determines whether a response 265 is received 630. If [block 634] there is a response 265 (that a recipient of the SVID request is the stolen vehicle), then [block 6the returned SVID 560 is authenticated as explained above against the returned SVID code 565. If the response is authenticated, then the processor 405 causes the indicator 445 to issue an SVID Notification [block 636]; otherwise the response is ignored. Next, and if there is no response, the processor 405 checks, using the real time clock 440, whether the SVID request has timed out by comparison with the end time 525. If it has timed-out then the SVID request is deleted from the SVID memory [block 640]. Whether or not the SVID request has timed-out, after a delay [block 632] of, for example, 0.1 seconds, the process iterates to block 628 in order to read and propagate the (or at least any remaining) SVID request(s).
It will be appreciated that there are many variants to the process and systems described above, which remain within the scope of the present invention.
According to embodiments of the present invention, the systems that are described above, or variants thereof, can be employed for performing other operations, such as vehicle recall (VR). In some embodiments, the respective systems are arranged to perform only vehicle recall and not SVR. According to an embodiment to be described, however, the same system and components that are described above are employed to perform vehicle recall operations in addition to SVR operations.
The operation of an exemplary OVMTU in processing a vehicle recall request will be described below with reference to the flow diagram in Fig. 7, in which the SVID memory store 421 is used in addition as a VRID memory store.
An exemplary VRID request 570 is illustrated in the diagram in Fig. 5c. The VR request 570 resembles the request 500 illustrated in Fig. 5a, except that a request designation 575 indicates 'VR' rather than 'SVR'. The request 570 includes: a target vehicle identity (in this instance a VRID) 580; a VRID code 585, for authentication; a propagate value 590; and an end time value 595.
For the purposes of VR, the target vehicle identity may be issued in terms of a class of vehicle, for example defined by car make, model and year. In this way, all vehicles in a certain batch can be recalled. Alternatively, the target vehicle identifier may be issued to a specific vehicle, for example defined by a VIN Thus, according to embodiments of the invention, an HVID stored by OVMTUs can include any or all associated vehicle identification data (for example, VIN, make, model, year, colour, engine size, etc.) to facilitate identification of groups of one or more vehicles by any appropriate identification means. According to the present VR embodiment, each OVMTU handles VR messages according to basic logic, which takes the form:

For each VR message received by an OVMTU:
- If a target vehicle identified in the received message matches the vehicle in which the recipient OVMTU is mounted, then indicate VR details to the driver;
- Propagate the message.

In greater detail, according to Fig. 7, an OVMTU receives and stores [block 700] a new VR request 570 from another OVMTU or from an initiation point. The new VR request 570 is authenticated [block 701], by using the code generator 430 and an associated key, which is stored in the CodKey memory 423, to perform a cryptographic hash operation over the received VRID 580 and compare the result with the received hash code 585. If the received VRID is not authentic, the associated VR request 570 is deleted from memory [block 702] and the process iterates to block 700 to wait for the next new VR request. If the VRID is authentic, the VRID 580 is compared [block 703] by the comparator 406 with the HVID, which is stored in the HVID memory 422 of the recipient OVMTU. If there is no match [block 704], then the process iterates to block 700 to wait for the next new VRID request. If, on the other hand, the VRID and HVID match, the OVMTU causes the indicator 445 to indicate [block 705] to the home vehicle's driver that the home vehicle should be taken to a service centre. This is in contrast with an SVID request match, which does not indicate anything to the driver of the home vehicle (who is typically a car thief), so as not to alert the driver that the system is performing SVR operations.
In a parallel operation, the OVMTU periodically (for example, every 0.1 seconds) reads the VRID requests from the VRID request memory 421 and propagates them [block 708] in an optical signal 709 to be received by any nearby OVMTU capable of receiving the requests. As before, if the engine of the vehicle is not running, then only VR requests having a YES propagation value, are propagated. Next [block 710], the processor 405 checks, using the real time clock 440, whether the VRID request has timed out by comparison with the end time 590. If it has timed-out then the VRID request is deleted from the VRID memory [block 712]. Then, whether or not the SVID request has timed-out, after a delay [block 714] of, for example, 0.1 seconds, the process iterates to block 708 in order to propagate the (or at least the remaining) VRID request(s).
Of course, although not illustrated (for ease of explanation and simplicity of the drawings and description only), the processes depicted in Figs. 6b and 7 would both be performed, typically, as a combined process in embodiments in which the same system performs both stolen vehicle recovery and vehicle recall.
A third exemplary kind of request message is illustrated in Fig. 8a and an associated response message is illustrated in Fig. 8b. The request and response messages relate to a status enquiry, for example, to determine if an identified OVMTU (for example, as illustrated in Fig. 4) is operating properly. The request message 800 has a 'STATUS REQUEST' message designation 805, so that a recipient OVMTU knows what the message is a status request; a target vehicle identifier 810; a target vehicle identifier code 815; a propagate value 820; and an end time 825. The response message 850 includes a 'STATUS RESPONSE' designation 855, so that a recipient OVMTU knows what the message is a response to a status enquiry; a RESPONSE PAYLOAD 860, which contains the status of the responding OVMTU; a vehicle identifier 865; and a vehicle identifier code 870. The codes, 815 and 870, propagate value 820 and end time 825 are for use as has already been described above.
According to an embodiment of the invention relating to a status enquiry, a request message 800 is originated by a central computer system and propagated, via at least one initiation point, to a plurality of vehicles and then from vehicle to vehicle (generally as described above). The request message, as in an SVR embodiment, may include a target vehicle identifier identifying a single vehicle, for example by using a VIN. Alternatively, the request message, as in a VR embodiment, may include a target vehicle identifier identifying a class of vehicle, for example by designating make, model and year. Alternatively, or in addition, the target vehicle identifier may identify an OVMTU (either singularly or as a category, defined in an appropriate way, for example by OVMTU serial number, model or age). In contrast, the response message 850 identifies the actual vehicle or OVMTU that is responding, in order that the status can be identified against a particular vehicle or VMTU.
When a recipient OVMTU, which has a HVID that matches the target vehicle identifier 810, receives the status request message, a diagnostic routine 426 of the OVMTU operates and provides status data to be included in the payload 860 of a response 850. The status data may simply signify that the OVMTU is operable. Alternatively, the diagnostics routine 426 may cause the OVMTU to perform a self-test. For example, the OVMTU may cause the LED 417 to transmit a burst of optical radiation, at least a small portion of which reflects off of the inside of the glass that covers a headlamp cluster in which the LED 417 is mounted (or off of the inside of a windshield) and is detected by the photo detector 412. The amount of optical radiation that is detected can be measured, for example using a simple A-D converter arrangement, and the measurement can form at least a part of the payload 860. If the same measurement is conducted periodically (for example in response to weekly or monthly status requests), a change in the amount of detected radiation (for example, the change may be a reduced amount of detected radiation) may indicate that either the LED 417 or the photo detector 412 is deteriorating and requires attention. This may lead to a vehicle recall request being issued for the vehicle. Of course, if there is no detected reflected radiation, then this may indicate that the transmitter arrangement has failed and a driver notification may be generated immediately. Many other ways of testing status will be evident to the skilled person.
After generating the status response message 850, the OVMTU stores the response in the SVID/VRID memory 421, and then periodically propagates the message, along with any other SVID and/or VRID messages that are to be propagated, to any destination OVMTU or initiation point that is capable of receiving such messages. In this way, a response message 850 will eventually be propagated back to an initiation point 210, which can receive the message via the photo diode 312 and optical receiver 310 arrangement. Then, the initiation point 210 can return the status message 850 to the central computer system, for example, via the network 205.
According to embodiments of the invention, in general, message propagation can be one-way or two-way and may be initiated at an initiation point or by a vehicle and/or VMTU. For example, an SVID request or VR request is typically initiated at an initiation point with an aim of being propagated to as many vehicles as possible, without any need to return a response to an initiation point. These are examples of one-way propagation. Alternatively, a status enquiry may be one-way or two-way. For example, an initiation point may issue a status enquiry to one or more vehicles, the enquiry being propagated, potentially via many other vehicles, to the targeted vehicle(s). On receipt of the status request, the or each targeted vehicle may generate a response, which is propagated, potentially via many other vehicles, to an initiation point (though not necessarily the same initiation point). This is an example of a two-way status enquiry. A one-way status message would arise, for example, if a status message is generated by a vehicle in response to a detected vehicle condition. In such a case, the message would be returned to an initiation point, potentially, via many other vehicles.
It will be appreciated that an OVMTU and associated systems may be enabled to perform any one or more operations including (but not limited to) SVD, VR and status monitoring.
In embodiments of the invention a priority may be applied to different received requests (or messages), wherein the priority may for example dictate which requests are propagated first or which requests are propagated most frequently. For example, an SVR request may take priority over a VR request, and the SVR request may be propagated more often than the VR request. The priority may be set by the central computer system, for example by assigning and embedding a priority value of 1-5 in a request message (where a 1 means highest priority and a 5 means the lowest priority). Then OVMTUs may be adapted to act according to the priority. In addition, or alternatively, an OVMTU may be arranged to identify and treat different requests in a different manner, according to a predetermined order of priority.
Status monitoring embodiments may, in addition, be employed to report on the status of a vehicle. For example, in embodiments in which an OVMTU is connected to a CAN of a motor vehicle, the OVMTU potentially has access to a large amount of performance and diagnostics information of the vehicle. The OVMTU can then be controlled to report elements of this information back to a central computer, according to embodiments of the present invention. In some embodiments, the information can be reported in response to associated status requests. In other embodiments, the OVMTU may be arranged to read and report the information back to the central computer system pro-actively and without needing a request. The information may then be reported back periodically (for example each week or month) or as a result of trigger events (for example, overheating or degraded petrol consumption, or simply periodically). Other information that may be reported back relates to driver performance, such as speeding or heavy braking. Such information may be useful is adjusting insurance premiums or the like. Another example of when a proactive message initiated by an OVMTU can be useful is in a situation of danger, for example kidnapping, when a driver or passenger who is a victim can (secretly) activate a panic button, to begin propagation by the OVMTU of an alarm message, which can be detected by other OVMTUs.
Thus far, embodiments of the present invention that have been described employ optical communications, for example, to initiate, propagate and respond to messages. An advantage of using optical communications is that the respective components and systems are relatively cheap, for example, by comparison to radio communications components and systems. This means that optical-based systems can become more pervasive, because additional vehicles and more people (such as traffic wardens) can be provided with an OVMTU for a relatively low cost. In addition, especially in relation to SVR, an SVR response indicating that a stolen vehicle has been detected (that is an SVID matches an HVID), which was transmitted, for example, using 'direct' (that is, point-to-point, without intervening repeating or other assistance) line-of-sight optical communications, provides a high degree of confidence that the respective stolen vehicle is in the proximity of the recipient OVMTU. In this regard, "in the proximity of' a vehicle typically means that another vehicle (or initiation point) is in the optical line-of-sight of the first vehicle. On a motorway, or on a quiet and relatively straight road, a line-of-sight might extend to 50 meters or more, but is likely to be, for practical and reliable communications purposes, about 5-20 metres.
If, in respect of SVR, long distance communications (for example, greater than 100 metres and/or employing an intervening transceiver, such as by using cellular radio technology) were used instead, receipt of an SVID response would not provide an accurate indication of stolen vehicle location, unless further additional functionality were provided, such as GPS functionality for providing accurate location information. Such additional functionality would increase the cost and decrease the cost-benefit of such a system. Nevertheless, more generally, embodiments of the present invention employ other kinds of wireless communications, such as direct, point-to-point radio communications. In respect of VR and status monitoring, for example, a greater range and not being limited to relatively short-range optical line-of-sight can be advantageous, since the location of a recipient is not as important as the ability for a recipient to propagate the message. Some embodiments of the invention employ relatively short range, direct radio communications such as, for example, communications based on Bluetooth or Wi-Fi standards, or some other kind of simple short-range point-to-point wireless standard. In any event, the power level employed for radio embodiments can be controlled so that the distance coverage is limited to coverage in the proximity of a vehicle. For example, power level can be limited so that distance coverage in free space is about 100 metres, 50 meters, 20 meters, or even less. In a built up area, coverage would naturally be limited, for example, and be bounded by buildings on either side of a road. In this way, a direct radio embodiment can still provide meaningful proximity information about stolen vehicle location. Other embodiments of the invention employ other communications, such as (and without limitation) ultrasonic or microwave communications. In some embodiments, different signal powers can be employed by the same equipment for different kinds of request. For example, an SVR request, which needs relatively accurate location information, may employ relatively low power (shorter distance) signalling. In contrast, a VR request, for which location is less important than the ability to receive and propagate messages, may employ relatively higher power (longer distance) signalling. Nevertheless, according to embodiments of the present invention, the distances covered are expected to be far shorter than those achievable using known radio communications of the kind, for example, employed in cellular mobile telephony.
In any event, the nature of a target vehicle identifier will change depending on the nature of the vehicle in or on which the OVMTU (or other alternative form of transceiver unit) is mounted. For example, if the vehicle is a train or ship, the identifier may be a unique registration number. If the vehicle is a human, the identifier may be a name and/or social security number. If the vehicle is an animal, the identifier may be an animal licence number or the like.
The above embodiments are to be understood as illustrative examples of the invention. Further embodiments of the invention are envisaged. It is to be understood that any feature described in relation to any one embodiment may be used alone, or, if the context permits, in combination with other features described, and may also be used in combination with one or more features of any other of the embodiments, or any combination of any other of the embodiments. Furthermore, equivalents and modifications not described above may also be employed without departing from the scope of the invention, which is defined in the accompanying claims.

Claims

A communications apparatus (400) for a vehicle, the apparatus (400) comprising:
a first store (422) to store a home vehicle identifier, for identifying a home vehicle on or in which the apparatus (400) is operating;

a receiver (410) to receive messages directly from message sources in the proximity of the home vehicle;

a second store (421) to store at least one target vehicle identifier;

a transmitter (415) to transmit messages directly to message destinations in the proximity of the home vehicle; and

the apparatus (400) being adapted to:
receive from a message source a message containing a target vehicle identifier and store the target vehicle identifier in the second store (421);

compare a received target vehicle identifier with the home vehicle identifier in order to establish whether the home vehicle is the respective target vehicle; and

in response to establishing that the home vehicle is not the respective target vehicle, propagate the received message to one or more message destinations;

characterised in that the apparatus (400) is adapted to:
receive from a message destination a response to a propagated message and determine on the basis of the response that the respective message destination is a target vehicle.
Apparatus (400) according to claim 1, which is arranged to propagate a message including a received target vehicle identifier only if the received target vehicle identifier matches the home vehicle identifier.
Apparatus (400) according to claim 1, which is arranged to propagate a message including a received target vehicle identifier only if the identifiers do not match.
Apparatus (400) according to any one of the preceding claims, which is arranged, if the identifiers match, to transmit a message indicating that the received target vehicle identifier matches the home vehicle identifier.
Apparatus (400) according to claim 4, which is arranged to determine that the received target vehicle identifier matches the home vehicle identifier, and upon determining a match, to transmit a message to the message source to confirm the match.
Apparatus (400) according to any one of the preceding claims, wherein a vehicle identifier comprises an identifier portion and an authentication portion to be used for authenticating the identifier portion, and wherein the apparatus (400) is arranged to authenticate a vehicle identifier on receipt thereof using the authentication portion.
Apparatus (400) according to any one of the preceding claims, being adapted to receive a message indicating that the respective message source is a vehicle that has a home vehicle identifier that matches a target vehicle identifier previously received by the same message source.
Apparatus (400) according to claim 7, comprising indicator means (445) and being arranged to cause the indicator means (445) to indicate, to an operator of the home vehicle, that a message source is a target vehicle.
Apparatus (400) according to any one of the preceding claims, wherein the second memory store (422) is for storing more than one target vehicle identifier.
Apparatus (400) according to claim 9, which is arranged to read from the second memory store (422), and transmit, plural target vehicle identifiers.
Apparatus (400) according to any one of the preceding claims, wherein a received message includes an expiry time, and wherein the associated message is not propagated if the expiry time has elapsed.
Apparatus (400) according to any one of the preceding claims, wherein a target vehicle identifier identifies a stolen vehicle.
A communications system, comprising:
a control centre (200) for issuing messages, each containing at least one target vehicle identifier;

a plurality of apparatuses (400) according to any one of claims 1 to 12; and

at least one initiation point (210), the or each initiation point having means for receiving messages from the control centre (200) and means for periodically propagating messages containing at least one target vehicle identifier to said apparatuses (400).
A communication system according to claim 13, wherein the at least one initiation point (210) comprises:
an interface (330) for receiving messages from the control centre; and

a wireless transmitter (315) for propagating messages; and

a wireless receiver (310) for receiving messages propagated by one or more of the apparatuses (400).
A method of propagating a message to a plurality of vehicles comprising:
receiving a message from a message source, the message containing a target vehicle identifier;

comparing a received target vehicle identifier with a home vehicle identifier of a recipient vehicle in order to establish whether the recipient vehicle is the respective target vehicle; and

in response to establishing that the home vehicle is not the target vehicle, propagating the received message to one or more message destinations;

characterised by

receiving from a message destination a response to a propagated message and determining on the basis of the response that the respective message destination is a target vehicle.