WO2014049352A1

WO2014049352A1 - Vehicle incident detection system

Info

Publication number: WO2014049352A1
Application number: PCT/GB2013/052506
Authority: WO
Inventors: Wayne Gilbert; Jonathan Edward GILBERT; Stephen William COWPER
Original assignee: Masternaut Risk Solutions Limited
Priority date: 2012-09-26
Filing date: 2013-09-26
Publication date: 2014-04-03
Also published as: GB2506365A; GB2506365B; GB201217189D0

Abstract

The invention relates to detection of vehicle incidents, an embodiment of which includes a vehicle incident detection system (100), comprising: a vehicle; an accelerometer assembly (102) mounted on the vehicle for measuring acceleration along an axis; a vibration sensor (104) rigidly connected to a structural component of the vehicle; a signal processing module (101) connected to the vibration sensor (104) and accelerometer assembly (102) for receiving first and second respective signals therefrom and configured to detect an incident if a magnitude of the first signal exceeds the first threshold; and an event management module configured to store data from the accelerometer assembly (102) and vibration sensor (104) and data relating to the status of the vehicle on detection of the incident by the signal processing module (101).

Description

VEHICLE INCIDENT DETECTION Field of the Invention

The invention relates to detection of vehicle incidents. Background

With the emergence of insurance services based on "pay how you drive" (PHYD) and "pay as you drive" (PAYD) models, near or real time data feedback from vehicles are becoming increasingly common. Such feedback is usually obtained by monitoring parameters of a vehicle while it is being driven, for example the time, the vehicle's location and its speed, and by intermittently sending this data to an insurance provider. This may be enabled by a unit fitted to the vehicle, which is provided as part of an insurance policy. By monitoring how, where and when the vehicle is driven, an insurance provider can more accurately assess the risk of insuring the driver of the vehicle. In a typical PHYD model, the premium paid by the driver may be reduced over time if the driver is shown to drive in a safe manner, as determined by being monitored by the unit. This enables drivers that would otherwise not be able to afford or even to obtain insurance to be insured. In a typical PAYD model, the insurance premium may be determined according to how often, when and where the vehicle is driven. The driver may, for example, pay a premium that allows for a certain amount of usage, and will be billed more if the vehicle is driven more than this amount. Various other options are also available in both types of insurance models, many variants of which are already on the market.

Vehicle monitoring systems for use in PHYD models may be more or less sophisticated depending on the level of monitoring required by the insurance provider. In addition to the time, vehicle speed and location, which may be considered to be basic minimum requirements, other parameters may be monitored such as levels of acceleration or deceleration, which can provide further indications of how safely the vehicle is being driven. Such monitoring systems may also have the ability to provide feedback when the vehicle is involved in an incident such as a collision. One sign of a vehicle being involved in a collision is if an airbag system is tripped as a result of the vehicle decelerating above a certain rate. Linking such an indication with a remote monitoring system can enable an accident notification service that can potentially deliver numerous safety benefits as well as economic benefits to the driver, passengers and other parties such as the insurance providers and emergency services. These benefits may include: the emergency services being able to respond faster to a potentially serious incident with knowledge of the location and severity of the incident; the insurance provided being notified, enabling more efficient claim settlement based on clear evidence of an incident having occurred; and a clearer establishment of liability based on the monitored behaviour of the driver before the incident.

Whilst notification of the emergency services may be extremely valuable, and potentially life-saving, the possibility of false triggering can also have severe consequences, potentially overloading call centres and causing unnecessary alarm. Experience of systems currently deployed tends to show an unacceptable level of false triggering. Setting the trigger level too high, for example only when an airbag system is activated, may result in many incidents being missed. Setting the trigger too low, however, will inevitably result in far too many incidents being triggered when they should not be. Accelerometers and gyroscopes, whilst providing useful analytical data, result in problems relating to discriminating between different types of events at low accelerations (or g forces). Without knowing what type of event is occurring at such low g forces, false triggering would be inevitable.

It is an object of the invention to address one or more of the above mentioned problems.

Summary of the Invention

In accordance with a first aspect of the invention there is provided a vehicle incident detection system, comprising:

a vehicle;

an accelerometer assembly mounted on the vehicle for measuring acceleration along an axis;

a vibration sensor rigidly connected to a structural component of the vehicle; a signal processing module connected to the vibration sensor and accelerometer assembly for receiving first and second respective signals therefrom and configured to detect an incident if a magnitude of the first signal exceeds a first threshold; and an event management module configured to store data from the accelerometer assembly and vibration sensor and data relating to the status of the vehicle on detection of the incident by the signal processing module. The invention addresses the above mentioned problem of false triggering by using a combination of sensors configured to detect different parameters relating to the vehicle. While an accelerometer can detect how quickly the vehicle is decelerating, which by itself might suggest a collision, a vibration sensor connected to a structural component of the vehicle can provide confirmation an incident has in fact occurred. The vibration signals can also be used alone to determine whether an incident has occurred, with signals from the accelerometer used to confirm the type of incident. A further advantage is that the vibration sensor can provide further useful information on the type of incident. Experimental work has shown that this significantly improves accident discrimination for low g-force events, in particular for events involving accelerations having a magnitude of less than 2.5g, where the vibration sensor signal can be used to discriminate between a reportable incident and normal use.

The signal processing module may be configured to detect an incident if magnitudes of the first and second signals both exceed respective first and second thresholds. The signal processing module may also or alternatively be configured to detect an incident if the magnitude of the first signal exceeds the first threshold and a magnitude of the second signal is below a second threshold. The signal processing module may also be configured to detect an incident if the magnitude of the first signal exceeds a third threshold greater than the first threshold and the magnitude of the second signal is below the second threshold. The second threshold may for example be 2.5g.

The event management module is preferably configured to wirelessly transmit a notification of the detected incident to a remote server on or after detection of the incident, the notification optionally including data from the accelerometer assembly and/or vibration sensor and/or data relating to the status of the vehicle. In this way the incident detection system is able to transmit a notification only when an incident is detected, which can be done by the system on the vehicle rather than having to be assessed remotely. This reduces the amount of data needed to be transmitted wirelessly to the remote serve. The data, or a selected portion thereof, may be transmitted along with the notification, but this is not necessary for the notification to be effective. The notification may for example be transmitted over a cellular telephone network. The notification may include an indication of the severity or type of the detected incident, for example as determined using the combination of accelerometer and vibration readings, or from the vibration readings alone. An advantage of this is that the remote server can be configured to trigger further action only when an incident of predetermined severity or type has been notified, thereby for example providing a line of defence against notifications being unnecessarily transmitted to the emergency services, and also enabling the remote server to take different action depending on the type of incident.

The vibration sensor in the vehicle incident detection system is preferably a piezoelectric sensor. Such sensors are well known in the fields of sensing and actuation covering a wide range of applications, existing applications in vehicles being engine knock sensors, fuel injection systems and ultrasonic parking sensors. The piezoelectric sensor may be configured according to the range of frequencies of vibrations to be detected and the degree of sensitivity required. A typical piezoelectric sensor may for example be in the form of a block or ring, and configured to detect vibrations with a reasonably uniform sensitivity over a wide range of frequencies below the resonant frequency of the sensor itself. The sensor may alternatively be configured such that a resonant frequency of the sensor lies within a range of frequencies of interest, so as to increase the sensitivity of response within this range. Piezoelectric sensors are particularly advantageous because they can be configured to detect a wide range of vibration frequencies directly from the component to which the sensor is attached.

The signal processing module of the vehicle incident detection system may be configured to continuously obtain components of the first and/or second signals enabling an incident to be detected quickly and accurately.

The accelerometer assembly of the vehicle incident detection system may be configured to sense acceleration along a plurality of axes, the plurality of axes optionally including three mutually orthogonal axes, one of which may be aligned with a direction of travel of the vehicle. Detecting along more than one axis has an advantage of being able, if necessary, to discriminate acceleration/deceleration in a direction of travel or transverse to the direction of travel, thereby providing a further indication of the type of incident. The signal processing system of the vehicle incident detection system may be configured to obtain a magnitude of a force vector derived from sensed acceleration along the plurality of axes, for example from a modulus of a sum of squares of acceleration signals along the plurality of axes. An advantage of this option is that the overall magnitude of the acceleration, rather than its direction, can be quickly determined and used as part of a process of detecting an incident and determining its type and severity. The direction of maximum acceleration may also be determined, for example by resolving the magnitude of acceleration in each of the plurality of axes into a single vector. The event management module may be configured to determine and store a measure of severity of the detected incident based on the magnitude, such as the modulus of sum of squares, of the acceleration signals. The measure of severity can be in a straitforward relationship with the magnitude of the modulus, i.e. the higher the modulus the greater the severity. The relationship may for example be linear or logarithmic.

The accelerometer assembly may also be configured to sense rotation about a plurality of axes. Sensing rotation as well as direction of acceleration can be useful in, for example, determining whether the incident involves the vehicle rotating, whether this is due to a roll or a spin.

The first and/or second thresholds may be dependent on a measure of the current status of the vehicle. For example, the first (or vibration) threshold may be varied up and down depending on the speed of the vehicle, as vibration will tend to increase as the vehicle is driven faster. The current status may be one or more of vehicle speed, engine speed and systemic background noise. Systemic background noise may for example be measured by taking an average of an output of the vibration sensor over time. The detected incident is typically a collision, although other incidents may also be detected. In accordance with a second aspect of the invention there is provided a method of detecting an incident in a vehicle, comprising:

analysing a first vibration signal from a vibration sensor rigidly connected to a structural component of the vehicle;

analysing a second acceleration signal from an accelerometer assembly mounted on the vehicle;

detecting an incident if a magnitude of the first signal exceeds a first threshold; and

storing data from the accelerometer assembly and vibration sensor and data relating to the status of the vehicle on detection of the incident.

In accordance with a third aspect of the invention there is provided a vehicle incident detection unit configured to be mounted to a vehicle, the unit comprising: a signal processing module having a first input configured to receive a first signal from avibration sensor, a second input configured to receive a second signal from an accelerometer assembly and a third input configured to receive vehicle status signals, the signal processing module configured to detect an incident if a magnitude of the first signal exceeds a first threshold; and

an event management module configured to store data from the accelerometer assembly and vibration sensor and data relating to the status of the vehicle on detection of the incident by the signal processing module.

The vehicle incident detection unit may further comprise the accelerometer assembly and/or the vibration sensor, for example as part of a kit of parts configured for mounting to a vehicle. The unit may be configured to be connected to an engine management system of the vehicle, from which the unit may receive the vehicle status signals. The various optional and preferable features of the first aspect may also be applied to the second or third aspects of the invention.

Detailed Description

The invention is described in further detail below by way of example and with reference to the accompanying drawings, in which: figure 1 is a schematic block diagram of an exemplary incident detection system;

figure 2 is a flow chart illustrating an exemplary method according to an aspect of the invention;

figure 3 is a schematic representation of acceleration and vibration amplitudes as a function of time during an incident;

figure 4 is a flow chart illustrating an exemplary method of processing a reported incident based on event data;

figure 5 is a schematic diagram illustrating a system for handling reported incidents;

figure 6 are exemplary plots of measured acceleration and vibration for a test incident;

figure 7 is a schematic circuit diagram configured for detection and reporting of an incident; and

figures 7a-7d illustrate detailed partial views of the circuit diagram of figure 7.

The incident detection system as a whole can be viewed as operating on three levels. At a first level, an in-vehicle system includes a vibration sensor and an accelerometer/gyroscope array, which functions to provide event discrimination at a local level. The devices making up the in-vehicle system may be co-located or alternatively fixed at separate locations to enable ease of installation. The function of the in-vehicle system is detailed in figure 2, as described below. At a second level, the in-vehicle system connects to a remote server, which can function to provide an average or aggregated input used by the in-vehicle system to further improve event discrimination. Data exchanges between the in-vehicle system and the remote server can occur in near real time or may be scheduled, as determined by algorithms at either end This function is detailed in figure 4, as described below. At a third level, other information may be included in the connected relationship model between the in- vehicle system and the remote server, in which third party data, for example relating to environmental conditions such as weather or other risk factors such as road works or traffic information, may be aggregated into the limits provided to the in-vehicle system, thereby reflecting risk. This functionality is detailed in figure 4, as described below. Figure 1 illustrates an exemplary vehicle incident detection system 100, in which a microprocessor 101 functions as a signal processing and event management module. The microprocessor 101 receives signals from an accelerometer 102 and optionally a magnetometer 103, either or both of which may sense in up to 3 axes. The microprocessor 101 also receives a signal from a vibration sensor 104, for example a piezoelectric sensor, optionally via a filter 105 that may be configured to filter out any unwanted frequency ranges. In alternative arrangements the vibration sensor may be sampled directly by the microprocessor 101 and digitally filtered as required. The microprocessor 101 is connected to a memory module 106, such as an erasable electronically programmable read only memory (EEPROM), within which program data for the microprocessor 101 may be stored. The memory 106 may also or alternatively be used for storage of data from the sensors 102, 103, 104.

The microprocessor 101 is powered by a battery 107, preferably a rechargeable battery, which is in turn powered by a power supply unit 108, such as a power supply available in the vehicle. The rechargeable battery 107 enables the system 100 to continue functioning in the event power is cut, for example when the vehicle to which the system is connected is involved in an incident that disconnects or otherwise disables the power supply 108.

The microprocessor 101 provides one or more input/output interfaces, for example in the form of a USB (universal serial bus) interface 109 and/or an RS232 interface 1 10, either or both of which may be used to extract from or input data or programs to the system 100. An interface, such as the USB interface 109, may be used to connect the microprocessor 101 to a wireless transceiver 1 1 1 to allow the system 100 to wirelessly transmit notifications to a remote server, via an aerial 1 12. The transceiver 1 1 1 may also be able to receive data, for example in order to remotely reconfigure or reprogram the microprocessor 101 or to provide notifications to the driver of the vehicle.

Figure 2 illustrates a flow diagram of an exemplary method of operation 200, in which data relating to an event is stored and sent, for example to a remote server, in response to a threshold being triggered by one or both of a piezoelectric vibration sensing device or an accelerometer/gyroscope. Outputs from the vibration sensing device and the accelerometer/gyroscope are continually sampled and compared to predetermined limits or thresholds. In the event that a trigger is initiated by either or both signals, a pre-defined event storage algorithm captures the relevant data and prepares it for transmission to the remote server. Events detected without a sufficiently high signal from the vibration sensor may be ignored or can be stored for later evaluation.

Event data that is continually being monitored 201 for an accident or other type of event is compared 202 to a threshold 203 relating to a G event, or acceleration. If the acceleration threshold 203 is not exceeded, monitoring continues 201. Once an event is triggered by the threshold 203 being exceeded, a check 204 is made to determine whether an event is also triggered by a signal from the piezoelectric vibration sensor. If not, monitoring continues 201. If an event is triggered by a signal from the piezoelectric sensor exceeding a vibration threshold, the event is stored 205 and a notification of the event is sent 206, optionally along with the event data, to a remote server. The acceleration threshold may for example be around 2.5g. This threshold can be set lower than would otherwise be the case for a system having only acceleration detection, since the vibration sensor can be used to provide improved discrimination between normal events and reportable incidents. Alternatively the acceleration threshold may be set to be higher and the vibration sensor used to provide increased certainty of the type of event once the acceleration threshold is exceeded.

As a further optional feature, the method of operation may also include continual monitoring, or sampling, 207 of the signal from the piezoelectric vibration sensor, and comparing 208 the signal to a further threshold value 209. The further threshold value 209 may be the same as, or higher than, the vibration threshold value mentioned above in relation to the check to determine whether an event is triggered, or may be different. If this further threshold value 209 alone is exceeded, an event may be triggered, at which point the event data is stored 205 and a notification sent 206. This further optional feature may be used, for example, to detect events where accelerations are too low to trigger an event according to the acceleration threshold, but where the vibrations detected by the vibration sensor indicate that significant damage is likely to have occurred. This may, for example, be as a result of a low speed collision or another type of incident where personal injury is unlikely but where damage is likely to have occurred. A different event notification may be made for this type of event, for example by not informing the emergency services but instead informing an insurance provider so that the event may be logged in case a claim is made. Event information, such as its time, location and severity, can then be used to verify any such claim. If a claim is not made, or is not made within a certain time frame, the event information may be deleted. Figure 3 illustrates schematic plots of acceleration (figure 3a) and vibration (figure 3b) amplitudes as a function of time, illustrating the types of signals that may indicate an event having occurred that is worth reporting. At time Ts, the acceleration signal 301 , which may be a modulus of a measured acceleration in one or more directions, rises above an acceleration threshold 302. A measured vibration amplitude 303 also rises to above a vibration threshold 304. Data relating to the event, which includes the acceleration and vibration signals as well as other information such as the time and location of the vehicle, are then recorded. Once a predetermined time period has passed and the signals are no longer above the thresholds 302, 304, the event recording stops, at time Te. The time period between the start and end of the event, defined by Te and Ts, may for example be less than one second. According to the method of operation 200 illustrated in figure 2, the event information over this time period is stored and a notification is sent to a remote server, in this case indicating that a significant collision is likely to have occurred.

Figure 4 illustrates a flow diagram illustrating a mode of operation 400 when an event is triggered. The event data 401 is first assessed to determine whether the risk associated with the event is high 402. The risk may for example relate to a risk of injury of occupants of the vehicle. If the risk is assessed to be high, a first notice of loss (FNOL) process is initiated 403, since it is practically certain that one or more claims will need to be made. A high risk incident may be defined as one where the incident requires immediate action for loss mitigation, and involves a high risk of personal injury. If the risk is assessed to be medium 404, a claims process 405 is initiated. A medium risk incident may be defined as an incident requiring prompt action for loss mitigation, with a risk of personal injury and damage to the vehicle. If the risk is assessed to be low 405, an incident process is initiated 407. A low risk incident may be defined as an incident requiring no immediate action, but the incident is added to a driver record and the insurance provided awaits further input such as a claim. If none of the risk thresholds are met, the thresholds are updated 408. This process takes incoming event data and compares it to standard data models (thresholds) currently in use. If variances exist, the new values are then shared with similar instances in remote devices, thus continually improving result accuracy. The assessments of risk is preferably undertaken by a server remote from the vehicle for which the event is triggered, but may alternatively be undertaken at least in part by a system onboard the vehicle. Figure 5 illustrates schematically a system 500 incorporating various features relating to the invention. A vehicle 501 incorporating an incident detection system communicates wirelessly with a server 502 on detection of an incident or event that meets the required threshold(s). The server 502 assesses information pertinent to the risk profiles of users, obtained from third parties, and uses this information to configure the sensitivity of algorithms both on the remote target (i.e. the vehicle) and on the server 502. This may be used to compute a current risk status or be used for analysis after an event. This information may for example relate to the weather or traffic conditions at the time and location the incident is detected, and may be obtained by the server by automatic connection to respective databases 505, 506 over the internet 504. The information may be stored along with the event data by the server for future reference.

Figures 6a and 6b illustrate exemplary plots of acceleration (figure 6a) and vibration (figure 6b) as measured on a vehicle over a time period within which an incident occurred. Acceleration is measured in g, i.e. in multiples of a nominal gravitational force (i.e. 9.81 Nkg^"1 or ms^"2), while vibration is measured in arbitrary units indicating a relative signal amplitude from the vibration sensor. In this example acceleration is measured in three orthogonal axes: x, y and z. The signals from each axis to some extent overlay each other, although the signals 601 in the x and y axes can be distinguished from the signal 602 in the z axis by a slight offset in the z axis acceleration. At time Ts, indicated by line 603 in figures 6a and 6b, the acceleration readings all indicate a peak. Acceleration in the z axis has the largest peak 604, indicating that the direction of acceleration/deceleration is closest to the z axis. Subsequent smaller peaks occur before the acceleration signals fall away as the energy in the collision is dissipated. A short time after the first acceleration peak 604, this time being determined by the distance between the point of impact and the position of the sensor, the vibration signal 605 also registers a peak value 606, indicating that the collision has resulted in a significant vibrations being set up in the structural component to which the vibration sensor is attached. Compared to the background level of vibrations, which in figure 6b indicates a general level of less than 500 units, the peak 605 registers a level of between 1500 and 2000 units, i.e. over three times the maximum level established for systemic background noise. The magnitude of the vibration signal indicates that the event detected by the levels of acceleration indicated in figure 6a was caused by a collision. Since the vibration sensor can easily detect impacts to the vehicle structure, the vibration signal can be used to evaluate an impact profile, which will be indicative of the type of event recorded. Other signals, such as the vehicle speed at the time of the event (or shortly before) can be used to make an assessment of the type of event. If, for example, the vehicle is not moving when the event is recorded this will enable the event to be classified differently to one where the vehicle is moving. Other information, such as that relating to the type of road the vehicle is on and the weather, can also be useful in classifying the event.

Figure 7 is a schematic circuit diagram showing in more detail the various components of an impact sensing device (ISD) 700 for a vehicle incident detection system of the type described above and illustrated in figure 1 , in which the various components are identifiable as collections of circuit elements. Figures 7a to 7d show the same circuit diagram in more detailed partial views. A central microprocessor 701 is connected to various other circuits, including RS232 and USB interface circuits 710, 709 and a power supply circuit 708 incorporating a battery 707. The microprocessor 701 in this case is a Renesas RX62N, which provides a complete digital subsystem with internal FLASH memory, RAM and data FLASH memory. Extension of the memory system may be provided by an external 64Mb serial FLASH memory device 706 (S25FL064K). The microprocessor 701 also includes analogue to digital conversion devices and is designed to meet automotive environmental requirements. Power generation and management are provided by a switching regulator 71 1 (LM22675), inverting boost regulator 712 (SP5205) and battery management chip 703 (MAX 1555). Internal and external communications are provided by a USB slave port 714 (FT230X) and RS232 transceiver 715 (SP3232E). A magnetometer chip 716 (MAG3 1 10) is provided to assist in orienting the ISD 700.

Input from an externally located piezoelectric transducer (KPEG165, not shown) connected to input connection 718 is filtered by a low noise, low power operational amplifier 717 (MCP6286) and the filtered output fed directly to an analogue to digital input 719 on the microprocessor 701. A three-axis linear accelerometer 720 (LIS33 1HH) provides acceleration signals to the microprocessor 701. The microprocessor 701 is programmed to analyse the signals received from the piezoelectric transducer and accelerometer 720 according to the algorithms described above. Data relating to an individual vehicle's behaviour can be gathered on a remote server, allowing typical vehicle profiles to be developed. This can further be used to derive more accurate thresholds for comparison to the live data stream from a particular vehicle to continually improve the accuracy of impact detection. The vibration sensor is physically attached to a structural member of the vehicle, for example the chassis or frame of the vehicle. This requires no special orientation with respect to the vehicle axes, since vibrations will travel in all directions within the structural component. Best performance is provided with a solid physical connection to a metal component, although connection to any load bearing member should be adequate. The sensor may be attached in various ways such as by using a fast-setting adhesive such as a cyanoacrylate adhesive or epoxy resin, a magnetic attachment, a screw fixing, clamping or any other appropriate method that provides a secure fixing. The accelerometer and/or gyroscope array is preferably aligned to the axes of the vehicle, or alternatively be accommodated by the use of software supporting automatic orientation and calibration of the accelerometer. The calibration system preferably continuously monitors the sensor to ensure that the calibration accommodates the vehicle being parked on inclines in any combination of variation to pitch, roll and yaw.

Other embodiments are within the scope of the invention, which is defined by the appended claims.

Claims

1. A vehicle incident detection system, comprising:

a vehicle;

a vibration sensor rigidly connected to a structural component of the vehicle; a signal processing module connected to the vibration sensor and accelerometer assembly for receiving first and second respective signals therefrom and configured to detect an incident if a magnitude of the first signal exceeds the first threshold; and

2. The vehicle incident detection system of claim 1 wherein the signal processing module is configured to detect an incident if magnitudes of the first and second signals both exceed respective first and second thresholds.

3. The vehicle incident detection system of claim 1 wherein the signal processing module is configured to detect an incident if the magnitude of the first signal exceeds the first threshold and a magnitude of the second signal is below a second threshold.

4. The vehicle incident detection system of claim 2 wherein the signal processing module is configured to detect an incident if the magnitude of the first signal exceeds a third threshold greater than the first threshold and the magnitude of the second signal is below the second threshold.

5. The vehicle incident of any one of claims 2, 3 or 4 wherein the second threshold is 2.5g.

6. The vehicle incident detection system of any preceding claim wherein the event management module is configured to wirelessly transmit a notification of the detected incident to a remote server on or after detection of the incident, the notification optionally including data from the accelerometer assembly and/or vibration sensor and/or data relating to the status of the vehicle.

7. The vehicle incident detection system of claim 6 wherein the notification includes an indication of the severity of the detected incident.

8. The vehicle incident detection system of any preceding claim wherein the vibration sensor is a piezoelectric sensor.

9. The vehicle incident detection system of any preceding claim wherein the accelerometer assembly is configured to sense acceleration along a plurality of axes, the plurality of axes optionally including three mutually orthogonal axes.

10. The vehicle incident detection system of claim 9 wherein the signal processing system is configured to obtain a magnitude of a force vector from a modulus of a sum of squares of acceleration signals along the plurality of axes.

1 1. The vehicle incident detection system of claim 10 wherein the event management module is configured to determine and store a measure of severity of the detected incident based on the modulus of sum of squares of the acceleration signals.

12. The vehicle incident detection system of any preceding claim wherein the accelerometer assembly is configured to sense rotation about a plurality of axes.

13. The vehicle incident detection system of any preceding claim wherein the first and/or second thresholds are dependent on a measure of the current status of the vehicle.

14. The vehicle incident detection system of claim 10 wherein the current status is one or more of vehicle speed, engine speed and systemic background noise.

15. The vehicle incident detection system of any preceding claim wherein the incident is a collision.

16. A method of detecting an incident in a vehicle, comprising:

analysing a first vibration signal from a vibration sensor rigidly connected to a structural component of the vehicle; analysing a second acceleration signal from an accelerometer assembly mounted on the vehicle;

17. A vehicle incident detection unit configured to be mounted to a vehicle, the unit comprising:

a signal processing module having a first input configured to receive a first signal from a vibration sensor, a second input configured to receive a second signal from an acceleration assembly and a third input configured to receive vehicle status signals, the signal processing module configured to detect an incident if a magnitude of the first signal exceeds a first threshold; and