Device for detection of external damage to chassis of a vehicle.
The present invention relates to a device, method and system for external chassis damage detection.
The automobile industry has the latest decade been promoting development of systems detecting engine failures and breakdowns to vehicles, where devices located in the vehicle reports incidents in real-time to remote operator, or to emergency services such as ambulance, road rescue or fire departments. This optimizes a service operation in that it may quickly respond and have fault correction activities lined up as soon as the vehicle comes into the workshop for repairs. Once the incident report is received the service operation can also prepare for services like rental services of substitution vehicle, hotel reservations, and other.
The sensor units in present solutions are connected to the engine surveillance modules or collision sensors (airbag, tire-pressure) already installed in the vehicle. The techniques available today is provided for providing a streamline support when the vehicle breaks down and are unable to continue, or are severely damaged.
The problem with the present technology is that it will not detect external chassis damages not affecting the operation of the vehicle, being represented by dents, scratches, minor damage to bumpers, doors, lights, other chassis parts, suspension, windows and the like.
The vehicle industry today encompasses for example car rental services, car pool cooperative operations, selfinsured multiple car owners, and others suffering from keeping track of the status of every vehicle at all time. All these operations rely heavily on manual reports of incidents and damage to the vehicles, and frequent manual control of the vehicles. Specifically this is a major issue for rental companies, and the customer of vehicle rental service. Normally all damage experienced during a rental shall be covered by the customer or the customers insurance. Often small chassis damages are not reported and not detected immediately with the result that the damage is not fixed, or the damage is blamed on the last rental customer using the vehicle before the damage was detected. This is a constant problem for the vehicle rental companies.
Unattended damages to vehicles are also a problem for the maintenance of the vehicle, and will eventually lead to deterioration of the value and may even lead to more serious damage.
In US 2014257627 A1 et system for deteksjon/varsling av skader på et kjøretøys chassis, omfattende minst en sensor, en kontroller for bearbeiding/analyse av data fra sensoren.
In GB 2527781 A it is shown a vehicle damage detection system comprising of a plurality of vibration sensors, a central control, processing and communication unit, and a GPS chip.
In US 2014156106 A1 it is shown a method for recording vehicle-relevant data, in particular for detecting and evaluating damage to a vehicle is detected and evaluated.
In DE 10235525 A1 it is shown monitoring of the state of a motor vehicle using machine learning and data mining technology to generate component models that are then used to monitor components, predict failure, etc., such analysis being useful for repair, etc.
In EP 1884414 A1 it is shown a device for evaluation of car damage.
The present invention comprises a device, method and system providing a solution of the above stated problems.
The present invention relates to the field of damage detection in vehicles.
The present invention is to be used for detecting external bodywork damage to a car bumper, screens, doors and the like. The present invention device may communicate and report to a central unit in the vehicle, and the central unit may communicate with external server.
The invention provides at least one sensor device for detection of chassis part movement as it happens and a central unit communicating with the sensor device. The central unit is configured to analyze information received from the sensor devices. The central unit may communicate the detected damage to a remote server device.
The invention further provides a method and system for detecting and analyzing external chassis damage to a vehicle originating from for example: dents, scratches, minor damage to bumpers, lights, chassis, suspension, windows and other..
The invention also provides a method and system for detecting and reporting such damages to a remote unit.
The invention is further defined by the appended claims.
The following figures are provided to illustrate some example embodiments of the invention, and shall not be representing any limitation of the invention:
Figure 1 identifies major parts of a sensor device
Figure 2 shows a car comprising sensor devices, central unit and external server
Figure 3 is a block diagram of a detection system according to the invention
Figure 4 shows an optional sensor layout and central registering/communication unit (star form)
Figure 5 is an example sample of registered noise from a sensor device
Figure 6A-F is a prototype of the sensor device in different views
Figure 7 is an example of a circuit diagram of the sensor
In the description and claims of the present invention the following words and phrases are used to comprise not only the general meaning of the same, but also:
When the phrase “piezoelectric sensor” is used it shall be understood that this is a device that uses the piezoelectric effect, to measure changes in pressure, acceleration, temperature, strain, or force by converting them to an electrical charge, and it shall be understood that the phrase shall also comprise any sensor providing similar functionality.
Vehicle – shall be understood to encompass wagons, bicycles, motor vehicles (motorcycles, cars, trucks, buses), railed vehicles (trains, trams), watercraft (ships, boats), and the like.
Chassis – shall mean any bodywork of a vehicle, parts of the vehicle such as mirrors, bumpers, lighthouse, windows, floor planes, bottom plates, etc.
Star network - in its simplest form, a star network consists of one central switch, hub or computer, which acts as a conduit to transmit messages.
Ring network - a network topology in which each node connects to exactly two other nodes, forming a single continuous pathway for signals through each node - a ring. Data travel from node to node, with each node along the way handling every packet.
The invention comprises a sensor device comprising at least one sensor that may be arranged inside the chassis part where it is intended to detect and report any damage detected on the chassis part. If there are more areas necessary to be covered, there may be installed more than one sensor devices.
The sensitivity of the sensor device, which comprise detections means for detecting damage caused by impacts that creates vibration and/or soundwaves transferred on the surface of or inside the chassis, may be configured to ignore sound and vibration originating from normal operation of the vehicle. The sensitivity level may be customized for specific vehicle type, or even individual vehicle, and for the specific location of the vehicle the sensor device is arrange. The detection means comprised in the sensor device, comprise one or more sensors of type: piezoelectric sensor, an accelerometer, gyroscope, shock detector or equivalent. When an incident is detected the sensor device will communicate the incident to a central unit or other unit in the vehicle that may process the information of the detected incident and/or optionally transfer the processed information or incident information together with metadata to a remote server. Metadata may comprise sensor device identification, timestamp, other sensor data such as temperature, humidity, battery level, SW version and other.
A central unit processing module may comprise processing module for evaluation of incident, and classification of the same. Classification criteria may be pre-set in manufacturing or distribution phase, or dynamically changed on installation or during operation. Modification of classification criteria during operation may be performed from a remotely connected server.
The classification criteria may be used to control a wakeup threshold for the sensor devices in the vehicle. It is important to set this wakeup level at a sensible level such that detected incidents originating from normal vehicle operation is not initiating an incident operation mode of the sensor device and the central unit. It is an aim to minimize unplanned reports without a real incident occurrence in order to save as much as possible battery power.
The sensor device may comprise capacitor sensors measuring capacitance changes in the chassis. In one embodiment of such capacitor sensor the chassis part may form the first of the conductive plates of the capacitor, and the sensor may provide the second conductive plate. Deformation of the chassis part will then change the capacitance parameters, which may be detected and reported as an incident. A different implementation of the capacitor based sensor is to provide a capacitor where a first conductive plate is kept stationary, and a second conductive plate is connected to the chassis part, and any movement of the chassis will be transferred to the second conductive plate, and hence change the capacitance.
The sensor device may be in a form that is easy to retrofit, or they may even be preinstalled in chassis part from vendor before vehicle assembly. Several options for powering the sensor device may be provided by the invention, although it is foreseen that energy is provided by a preinstalled long life battery. The fact that there is required very little energy for standby operation, the sensor device may operate for years without the need for battery replacement, typically 3 – 5 years. It is also possible to combine battery operation with passive circuits being powered by the signals received from a central unit. A combination of battery, signal power and external power supply may be used as sole power source or in any combination.
The invention further comprises a system comprising one or more sensor devices arranged in locations on a vehicle likely to be in the vicinity of a potential damage. Typically the sensor devices will be arranged on the inside of the chassis or integrated inside parts of the vehicle. The system may comprise a central unit comprising communication means and processing means that communicates with one or more of the sensor devices deployed in the vehicle. The processing means may be set up to record and analyze any signals being communicated from the sensor devices, originating from signals received from the chassis vicinity of the individual sensor device. The communication means may store any findings or communicate any findings to a remote server. Each incident which is detected may be stored in an event log, which resides in the sensor device, central unit or the remote server or in any combination of the three. Communication may be either wireless or for some instances by wire. In one embodiment the central unit resides with the sensor device. In another embodiment the central unit serve as communication and processing unit for other standalone sensors. Communication between sensor device and central unit may be performed using Bluetooth Low Energy (BLE) communication, or any other communication protocol, preferably a protocol requiring low energy consumption.
The remote server will typically comprise SW for linking the data communicated from the central unit to a data base or back office system. The data, when processed, may be added to previously received data and form a historical data set. The historical data set will, when data is adjusted for true and false incidents reports, be used to configure the individual vehicle implementation. The historical data set may be used to configure the sensitivity level of the central unit residing in the individual vehicle. The central unit may configure the individual sensor device such that it awakens only on incidents that are real damages. A more correct sensitivity level will optimize lifetime, and report a more accurate number of incidents.
Each sensor device may comprise a configuration setup, enabling the sensor device to be produced, transported, stored and installed without consuming any energy. The sensor device may then be set up to start functioning only after being initiated manually or by a central unit. Such initiation process may also include registering the sensor device with the central unit, and further define the chassis location of the sensor device. The central unit may be linked up to the remote server in this process, enabling the remote server to log and monitor the setup. The setup may also be arranged to be controlled from the remote server. In the latter instance the installation resource may have access to a management program running on the remote server whilst the installation/activation of the sensor devices is performed.
A further feature of the sensor devices is that they may be deactivated from central unit or remote server.
The sensor devices may also comprise capability to report end of life status to the central unit. Typically this will occur when the battery capacity is below a preset level. Other causes for end of life may be preset maximum actual time lapse reached, preset number of incidents above maximum reached, preset incident amplitude above maximum level, out of place detected, or other.
The sensor device may be set up to communicate with central unit at preset time intervals to identify that it is alive. The verification communication may be two-way, such that the sensor device also may be able to verify that the central unit is alive and able to receive communication from the sensor device.
Now a few embodiments of the invention will be discussed referring to the figures. These embodiments are examples of how the invention may be implemented, and shall not constitute any limitations to the invention scope which is defined by the associated claims.
In figure 1 it is shown an component overview of the Sensor device 1 and the printed circuit board 7, (PCB), comprising a CPU unit, wherein the casing 2 protects the assembly from damp and dust. The casing 2 itself also represents a reference point for the sensor 4, the sensor 4 being connected to the chassis via a displaceable tap 5 which protrude through the chassis 2 and touches the chassis 6. Any movement, in form of vibration or deformation will be sensed by the displaceable tap 5, which again will be transmitted to the input of the sensor 4. The sensor 4 may be mounted to the printed circuit board 7, (PCB), and on a resilient arm 8 of the PCB, enabling the sensor 4 to be further flexible in the displacement caused by a possible incident. The incident is defined by detection of an unexpected movement pattern of the chassis 6. The PCB 7 will comprise necessary logic for analyzing an input signal generated by the sensor 4, and an output module for communicating with a central unit. PCB 7 may also comprise a battery 3 for self-sustained operation of the sensor device and the CPU unit. The PCB 7 may also comprise an output channel device such as a wireless communication device and/or a physical interface for hard wired communication of the output channel. When the PCB 7 hosts wireless communication modules, the PCB may also comprise or connect to antenna devices 65 as outlined in fig.7, either integrated into the PCB, mounted to the PCB 7 or as a standalone wire connected device inside or on the outside of the casing. The casing 2 may be of any material able to maintain the operating environment requirement of the sensor 4 and CPU unit. For subsea vehicles it is envisaged that the casing 2 is air tight, and in some cases also made for withstanding substantial pressure as experienced at water depths. The casing 2 may be fastened to the chassis by any means, where such fastening means 9 may be a fastening bracket, or even a double-sided tape, for example formed around the displaceable tap 5 in a donut form. Further details of the sensor device are laid out in figure 6 A-F and 7.
The deployment of sensor devices 1 throughout the vehicle will be determined by the type of vehicle, the material and design used in the different chassis parts, and the size of each part. Shape and mounted equipment and through holes in the chassis part contributes to the chassis pat’s ability to transmit incident signals from the incident position to the closest sensor device 1. A bumper in plastic material including mounted lights and parking sensors will have a complex and very damping effect on any signals caused by an incident, and several sensor devices may be necessary to deploy, for example one in each corner and one in the middle, such as illustrated in figure 2. All sensor devices, which may be more than one, and in some cases up to 20 or more in numbers, communicate all incidents to a central unit 20. The central unit may communicate wirelessly with a remote server 30. Communication to remote server may also be solved by connecting a wired or wireless link unit (not shown) to the central unit when the vehicle is returned to home base, and the link unit can be configured to communicate with the remote server 30.
In the block diagram in figure 3, a sensor device 1 comprising a sensor is shown, comprising a Piezo electric sensor 4 inside the chassis. The sensor 4 may comprise any sensor type able to detect vibrations and/or noise frequencies, even light detectors, temperature detectors, gyro, electrical power detector, inductance detectors, capacitance detectors or other in combination with proper algorithm calculating resources for analyzing sensor output may be used. The sensor 4 may be any combination of one or more of the sensor types mentioned.
In the sensor device 1, the sensor 4 is further connected to a CPU unit, in the figure a low power CPU is mentioned, but any CPU may be used, only limited by the power requirements and power resources necessary for operation and producing the sensor device output. Typically the sensor device will wake up when occurrence of an incident and detection of a disturbance level above or equal to a preset level and/or a pattern similar to a preset pattern, pattern criteria, or to a pattern in a set of preset patterns, pattern criteria. The CPU unit may process sensor output from one or more sensors.
In figure 6A – 6F it is illustrated an embodiment of the sensor device 1 wherein the PCB 7, 8 is mounted inside a casing 2A, 2B. In the figure various parts of the casing is not drawn for illustration purpose, although the casing in real life encompass the whole sensor device. The PCB comprises the resilient arm 8, whereupon the sensor 4 is mounted. Also on the resilient arm is the displaceable tap 5 mounted on the side of the PCB 8 that faces towards the chassis of which the sensor device is being mounted to. An optional protective cover 60 is arranged around the displaceable tap 5 to protect the inner space of the sensor device 1 from dust and fluids, and also in order to make the internal of the sensor device 1 water tight.. The PCB 7 further comprises a number of spacers 63, arranged to hold the PCB stable relative the battery 3 which is mounted inside the casing 2A, 2B. A spring 64 is arranged between the outer end of the resilient arm 8 and the back side of the battery. The spring force ensures that the resilient arm 8 is biased towards the surface of the chassis that the sensor device is arranged on. In embodiments where battery 3 or energy source take other forms or are arranged elsewhere, the spring will typically be arranged at one end towards a different static point, such as the inside of the casing 2B. A battery pole contact 65 is shown in fig 6B and 6D. The battery 3 is further secured by a clamp 62, which will also serve as a contact point 9 for one of the battery poles to the PCB. The sensor device may further be arranged on a mounting bracket 9, which may comprise a glue layer or other fastening arrangement for secure mounting to a chassis part. The fastening device may well be arranged as a soldered layer, or simply as a screw and nut arrangement, where the chassis may provide a nut function.
An example of a circuit diagram of the PCB 7 compromising the CPU unit is shown in figure 7, however the electronic design of the PCB unit may be solved in a variety of ways, and can readily be redesigned by a skilled person. All such redesigns shall be encompassed by the present invention.
The CPU unit may decide whether an incidence is qualified to be reported. The CPU unit may also be preset to wake up the sensor device(s) to perform a sampling sequence. The sample sequence may periodically be reported. The CPU unit may further comprise a storage unit capable of storing some or all incidents sensed by the sensor device(s) 1.
The sensors devices 1 may primarily be set up to detect and report damages to the external part of the chassis, and the sensitivity is set to be detecting damage happening as a result of quick bumps initiating vibration, displacement, or soundwaves in the surface of the chassis, and which is detectable by the sensor devices.
The CPU unit may communicate its findings to a central unit 20 also residing on the vehicle. The central unit 20 may comprise the features described for the CPU unit, and the central unit 20 may in such instances be able to communicate directly with a sensors 4 or sensor devices 1. Typically the CPU unit will communicate with the central unit 20 over a wireless channel, such as a Bluetooth channel. Other wireless protocols may be used, and in environments with a lot of electric or magnetic noise even a fixed line may be envisaged.
The central unit 20 may comprise a storage device able to store any findings reported to the central unit 20. A central unit 20 may communicate with one or more sensors 4 or sensor devices 1.
The central unit 20 may also comprise a communication device able to connect and communicate with a remote server 30 or service point 30. Typically this communication is performed over a General Packet Radio Service , GPRS /GMS communication channel, but other communication protocols and systems may be used. Communication systems like satellite communication, AM or other radio communication or other may be used without loss of any features. The central unit may further comprise a Global Positioning System, GPS, or other localization system unit for reporting exact position when an incident occurs.
The central unit 20 may be integrated in other electronic devices installed in the vehicle, such as a drive log system, or can even be implemented as a smart phone app.
The sensor device 1 may comprise a feature for detection whether the sensor device 1 is removed from its installed position. That is in the case a sensor device 1 is mounted and initiated towards a central unit 20, the sensor device 1 comprises a sensor position detector which monitors if the sensor device 1 is removed from the vehicle. This feature may be used both as an error detector and a tamper feature. The sensor device 1 position detector will awaken the processor and send a signal to the central unit 20 if the sensor device 1 is moved out of position.
An example of a detected signal of potential incidents is shown in figure 5.
The sensor device 1 and CPU unit may be configurable in a number of ways, where some configurable parameters may be:
- Report frequency, comprising also how what frequency the sensor device will request new configuration from the central unit 20
- Sampling period, which is the time interval between each sample
- Number of samples, which is how many samples is to be taken when the sensor device 1 is awakened.
This value also decides the total wake time which will be the product of sampling period * number of samples ;- Number of samples to be taken above a HighThreshold, which is the number of samples above HighThreshold that will qualify for a report initiation to the central unit 20, and/or a sensor device initiated line item in the eventlog ;- Number of samples to be taken above a MidThreshold, which is the number of samples above MidThreshold that will qualify for a report initiation to the central unit 20, and/or a sensor device 1 initiated line item in the eventlog ;- Multiplication value, which is a value of the product of number of samples above HighThreshold * number of samples above MidThreshold that will qualify for a report initiation to the central unit 20, and/or a sensor device 1 initiated line item in the eventlog
- Type, which is what type of filtering is to be performed on the sample results in regards of number of samples or multiplication value
The sensor device 1and CPU unit may consist of a microcontroller and an amplifier circuit. The output of the amplifier circuit may wake up the microcontroller from sleep mode. When the microcontroller wakes up, it will sample the signal of the output of the amplifier circuit with configurable interval and number of samples. The result is assessed against a single result threshold and may be reported to the central unit 20. The sensor device 1 and CPU unit may be configured from the central unit 20, and parameter changes may be controlled from the remote server 30 or service point 30 by for example sending an SMS to the central unit 20. Other message or radio protocols may be used. The sensor device 1 and CPU unit will also regularly send a request for updates or the latest configuration to the central unit 20, and/or send “I am alive” status message. Update request messages and “I am alive” messages are configurable in the same manner as described above. There may be facilitated a light indicator in the sensor device 1 and CPU unit, optionally with a color coded light for signaling status such as “I am alive” with a green light, and “Incident occurred” with a red light. It is possible to combine or substitute color coding with light signal pattern.
A feature of the present invention is that the sensor device 1 and the CPU unit including a wireless link may be integrated in a casing 2A, 2B where all parts are very low power consuming parts, able to be operative for a long time on a single battery device 3, the battery device 3 may be preinstalled in the casing 2A, 2B.
A sensor device 1 and CPU unit communicating with a number of sensors 4 may be one of a number of sensor device 1 and CPU units communicating sensors output to the central unit 20 of a vehicle. The central unit 20 may implement different communication protocols for securing error free communication from all sensor device 1 and CPU units. One such communication protocol is illustrated in the star network in figure 2. It may be implemented other types of protocols, such as ring formed network, where one or more sensor device 1 and CPU units operates as a relay between another sensor device 1 and CPU unit and the central unit 20.
Figure 6 and 7 show a version of the PCB seen from different angles, highlighting the various parts.
A scenario where a sensor device is initiated for the first may look like the activities listed in sequence below:
To achieve equivalent assurance that the sensor device 1 only accepts an initiation from a truly central unit 20, assigning may comprise the steps:
1. Sensor device 1 is newly manufactured, and it has no knowledge of which central unit 20 it should communicate with.
2. Sensor device 1 will be in the lowest power mode and just wait for an awakening-interrupt from a sensor position detector.
3. When the sensor device 1 awakened by interrupts, it will verify that the product is properly fitted, i.e.
the sensor device 1/sensor 4 is in the correct position for some time, for example 1-2 minutes. If the sensor device 1 is in the correct position, the sensor device 1 may attempt to perform a sensor connect request and wait for initiation from a central unit 20.
4. If sensor device 1 find that the sensor device 1 is not in the correct position (ie the product is not installed, improperly mounted, laid back in stock etc.) the sensor device 1 will again go to the lowest power mode and wait for new interrupt, as in pt.2 above.
5. In an initiation process the central unit 20 may send a specific verification code to sensor device 1, the basis of a defined algorithm known only for the vendor, and/or the central units 20 and the sensor device 1.
6. If the verification code from the central unit 20 is accepted by the sensor device 1, the sensor device 1 store central unit's address/Id, and later only deal with this specific central unit 20. The sensor device 1 then transfer configuration data. From now on, the product goes into normal operating mode.
7. If the verification code is not approved, sensor device 1 disconnects and may continue to send sensor connect request with fixed interval, as in step 3 above.
A typical implementation of the system and device of the invention is a damage detection and report system for a rental car fleet, ran by a rental car company.
In such a setting some or all of the vehicles in the rental pool may be represented by the example vehicle in figure 2. When the car is included in the fleet, an initiation process of the sensor devices 1 may be performed.
The central unit 20 communicates performance parameters to the sensor devices 1, and the central unit 20 is in communication with the remote server 30. For every incident reported by any of the sensor devices 1, the central unit 20 reports the incident to the remote server 30. The report is sent either immediately as the incident occurs, or in predefined batches at preset time intervals, or every time the vehicle is returning back from assignment. All data received by the server 30 may be stored in a database. When the vehicle is reported back a manual inspection may be performed to verify the incidents reported during the assignment. The result of the manual inspection will when reported data in the database is corrected be that the whole system may be optimized. If too many incidents are reported for example from sensor device 1 mounted in the right half of the front bumper, the server 30 may send a correction activation limit for the specific sensor device 1 to the central unit 20, and the central unit 20 may then reconfigure the level for the activation limit by raising this for the specific sensor device 1. If damage to the vehicle is detected in the manual inspection which was not reported by the sensor device 1, the same process may be repeated but with setting the activation limit of the sensor device 1 lower.
The sensor device 1 may report incidents continuously as in an output data stream communication that starts when the incident starts, and ends when the incident ends. Itis also possible to report incidents in predefined data blocks 50. Meaning that if an incident lasts longer than the predefined block size 50 allow, then more than one data block 50 will be used to report the incident. In this case every data block 50 may include a time stamp defining when previously incident reported was sent, and if the times between the two data blocks 50 are tending towards zero, the previous data block 50 described the same incident as the current data block 50.
Another scenario can be a one user system where a person wants to keep track of what happens to the personal car. The sensor device 1 may be connected to the user’s smart phone, and bumps and scratches may be reported directly as they happen to an app designed for receiving reports from the sensor device 1. If the central unit 20 or sensor device1 comprises a position device such as a GPS module, the device may even serve as a tracking device in case of theft.
Even if the invention is described when used in combination with a vehicle to detect incidents, such as damages, to a chassis part of the vehicle, it shall also be within the scope of the invention to use the sensor devices, the sensors, the central units and remote servers to detect damages to a permanent installation of the type, but not limited to, huts and houses, storage compartment, caravans permanently installed in a location, weather stations, buoys, subsea installations, windmills, and others.
Although the various features and elements of the invention is described in certain embodiments or sequences in this document, it is within the scope of the invention to use any of the features in any combination or sequence to adapt the invention to a new environment or need. It is the attached claims only that defines the scope of the invention.