WO2006137809A1

WO2006137809A1 - On-board vehicle device control system and method

Info

Publication number: WO2006137809A1
Application number: PCT/SG2006/000170
Authority: WO
Inventors: Teck Yee Lim
Original assignee: M2M Technologies Pte Ltd
Priority date: 2005-06-24
Filing date: 2006-06-23
Publication date: 2006-12-28
Also published as: SG128511A1

Abstract

A System and method for on-board controlling one or more devices installed in a vehicle. The on-board system comprises a microcontroller; a wireless communication module coupled to the microcontroller; one or more sensors installed in the vehicle and coupled to the microcontroller; wherein the microcontroller controls the one or more devices based on signals received from the wireless communication module, the sensors, or both; and wherein the microcontroller initiates a communication to an external communication device via the communication module based on signals received from the sensors.

Description

ON-BOARD VEHICLE DEVICE CONTROL SYSTEM AND METHOD

FIELD OF INVENTION

The present invention relates broadly to a system and method for on-board controlling one or more devices installed in a vehicle.

BACKGROUND

In the context of remotely controlling devices in a vehicle, existing solutions typically comprise utilising a central processing unit (CPU) together with a Global System for Mobile Communication (GSM) communication module. A command signal may be sent via Short Message Service (SMS) or Multimedia Messaging Service (MMS) message to control the appliances and a response may also be sent via SMS or MMS from the appliances using the GSM communication module. Most of the existing solutions are limited only to applications related to car alarm systems linked to call centers. A car alarm system linked to a call center is typically a system which alerts the call center via the GSM communication module if an intrusion occurs.

Some problems may arise with the usage of a CPU for controlling devices. One problem posed may be the typically high power consumption of the CPU. Another problem may be the operating conditions of the CPU being typically limited, e.g. the CPU may be damaged at relatively high operating temperatures.

Yet another problem when utilising the CPU to control a plurality of devices may be high costs being incurred due to additional circuitry that are typically required when adding devices to be controlled. SUMMARY

In accordance with a first aspect of the present invention, there is provided an on-board system for controlling one or more devices installed in a vehicle, the system comprising, a microcontroller; a wireless communication module coupled to the microcontroller; one or more sensors installed in the vehicle and coupled to the microcontroller; wherein the microcontroller controls the one or more devices based on signals received from the wireless communication module, the sensors, or both; and wherein the microcontroller initiates a communication to an external communication device via the communication module based on signals received from the sensors.

The devices may comprise a first action device; the sensors may comprise an alcohol level sensor; and the microcontroller may control the first action device based on signals received from the alcohol level tester and the microcontroller may initiate a communication to the external communication device via the communication module based on the signals received from the alcohol level sensor.

The devices may further comprise an alerting device and a second action device; the sensors may comprise a human input device; and the microcontroller may instruct a driver reaction test by activating the alerting device based on signals received from the alcohol level tester and the microcontroller may control the second action device based on signals received from the human input device.

The alerting device may comprise an optical device, a sound device, or both, and the action device may comprise a water spray device, the human input device may comprise a button, and the first action device may comprise an engine immobilizer.

The devices may comprise an alerting device and a first action device; the sensors may comprise a human input device; and the microcontroller may instruct a driver reaction test by activating the alerting device, the microcontroller may control the first action device based on signals received from the human input device and the microcontroller may initiate a communication to the external communication device via the communication module based on the signals received from the human input device.

The devices may further comprise a second action device; and the microcontroller may control the second action device based on the signals received from the human input device.

The human input device may comprise a button, the second action device may comprise an air freshener, a humidifier, or both, the alerting device may comprise an optical device, a sound device, or both, and the first action device may comprise an engine immobilizer.

The devices may comprise an alerting device; the sensors may comprise a driving characteristic sensor; and the microcontroller may control the alerting device based on signals received from the driving characteristic sensor and the microcontroller may initiate a communication to the external communication device via the communication module based on the signals received from the driving characteristic sensor.

The alerting device may comprise an optical device, a sound device, or both, and the driving characteristic sensor may comprise a speed sensor, a seatbelt sensor, or both.

The devices may comprise an action device; the sensors may comprise a carbon monoxide sensor; and the microcontroller may control the action device based on signals received from the carbon monoxide sensor and the microcontroller may initiate a communication to the external communication device via the communication module based on the signals received from the carbon monoxide sensor. The action device may comprise a window controller.

The devices may comprise an action device; the sensors may comprise a voltage monitor coupled to a battery of the vehicle; and the microcontroller may control the action device based on signals received from the voltage monitor for recharging the battery and the microcontroller may initiate a communication to the external communication device via the communication module based on the signals received from the voltage monitor.

The action device may comprise one or more of a group consisting of a starter of the vehicle engine, a gear control device, and a break control device.

The devices may comprise an alerting device; the sensors may comprise a tilt sensor and a engine-off sensor; and the microcontroller may control the alerting device based on signals received from the tilt sensor and the engine-off sensor and the microcontroller may initiate a communication to the external communication device via the communication module based on the signals received from the tilt sensor.

The devices may comprise an engine starter device; the sensors may comprise a handbrake detector and a gear shift detector; and the microcontroller may control the engine starter device based on signals received from the communication module, the handbrake detector and the gear shift detector, and the microcontroller may initiate a communication to the external communication device via the communication module based on the signals received from the handbrake detector and the gear shift detector.

The sensors may further comprise a temperature sensor; and the microcontroller may control the engine starter device based on signals received from the communication module, the handbrake detector, the gear shift detector and the temperature sensor, and the microcontroller may initiate a communication to the external communication device via the communication module based on the signals received from the handbrake detector, the gear shift detector and the temperature sensor.

The devices may comprise an offensive measure device; the sensors may comprise a panic button; and the microcontroller may control the offensive measure device based on signals received from the panic button or the communication module and the microcontroller may initiate a communication to the external communication device via the communication module based on the signals received from the panic button.

The devices may comprise an engine immobilizer unit coupled to the engine of the vehicle; the sensors may comprise a vibration sensor; and the microcontroller may control the engine immobilizer unit based on signals received from the vibration sensor and the microcontroller may initiate a communication to the external communication device via the communication module based on the signals received from the vibration sensor.

In accordance with a second aspect of the present invention, there is provided a method of on-board controlling one or more devices installed in a vehicle, the method comprising, controlling the one or more devices based on signals received from a wireless communication module, sensors installed in the vehicle, or both utilising a microcontroller; and initiating a communication to an external communication device via the communication module based on signals received from the sensors utilising a microcontroller.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will be better understood and readily apparent to one of ordinary skill in the art from the following written description, by way of example only, and in conjunction with the drawings, in which: Figure 1(a) is a top view of a microcontroller unit (MCU) mainboard in an example embodiment.

Figure 1(b) is a bottom view of a microcontroller unit (MCU) mainboard in an example embodiment.

Figure 2 is a schematic side view of devices coupled to a MCU mainboard for a Drink Driving Control function in an example embodiment.

Figure 3 is a picture showing a fingerprint reader unit mounted on a control panel in a vehicle in an example embodiment.

Figure 4 is a flowchart illustrating the process of a Drink Driving Control function in an example embodiment.

Figure 5 is a flowchart illustrating the process of a series of reaction tests in an example embodiment.

Figure 6 is a schematic side view of devices coupled to a MCU mainboard for a Drowsy Driving Control function in an example embodiment.

Figure 7 is a flowchart illustrating the process of a Drowsy Driving Control function in an example embodiment.

Figure 8 is a schematic side view of devices coupled to a MCU mainboard for a Teenage Driver Behavior Control function in an example embodiment.

Figure 9 is a flowchart illustrating the process of a Teenage Driver Behavior Control function in an example embodiment.

Figure 10 is a schematic side view of devices coupled to a MCU mainboard for a Carbon Monoxide Detection Control function in an example embodiment. Figure 11 is a flowchart illustrating the process of a Carbon Monoxide Detection Control function in an example embodiment.

Figure 12 is a schematic side view of devices coupled to a MCU mainboard for a Battery Auto Charge Control function in an example embodiment.

Figure 13 is a flowchart illustrating the process of a Battery Auto Charge Control function in an example embodiment.

Figure 14 is a schematic side view of devices coupled to a MCU mainboard for a Location Reminder Control function in an example embodiment.

Figure 15 is a schematic diagram illustrating a software database containing different groups of GPS data for use in a Location Reminder Control function in an example embodiment.

Figure 16 is a flowchart illustrating the process of a Location Reminder Control function in an example embodiment.

Figure 17 is a schematic diagram illustrating a Global Positioning System (GPS) reminder panel in an example embodiment.

Figure 18 is a flowchart illustrating the process of editing or categorising GPS data for a Location Reminder Control function in an example embodiment.

Figure 19 is a schematic side view of devices coupled to a MCU mainboard for a Tire Pressure and Anti-Tow Monitoring Control function in an example embodiment.

Figure 20 is a flowchart illustrating the process of a Tire Pressure and Anti- Tow Monitoring Control function in an example embodiment. Figure 21 is a schematic side view of devices coupled to a MCU mainboard for a Remote Start Engine Control function in an example embodiment.

Figure 22 is a flowchart illustrating the process of a Remote Start Engine Control function in an example embodiment.

Figure 23 is a flowchart illustrating the process of a Remote Start Engine Control function for cold starting an engine in an example embodiment.

Figure 24 is a schematic side view of devices coupled to a MCU mainboard for a Anti Rob / Anti Hijack Control function in an example embodiment.

Figure 25 is a schematic diagram illustrating a dual-relay switch setup for activating a spray of dye via a spray unit in an example embodiment.

Figure 26 is a schematic side view of devices coupled to a MCU mainboard for a Temporary Parking Control function in an example embodiment.

Figure 27 is a flowchart illustrating the process of a Temporary Parking Control function in an example embodiment.

DETAILED DESCRIPTION

In an example embodiment, an on-board system for remotely controlling devices in a vehicle is provided. With reference to Figure 1(a), the system utilises a microcontroller unit (MCU) mainboard 102. The MCU mainboard 102 is coupled to a single-chip MCU 104, to a GSM communication module 106, to relay switches e.g. 108, 110 and to Input/Output (I/O) ports e.g. 112, 114. With reference to Figure 1 (b), the GSM communication module 106 comprises a subscriber identity module (SIM) card holder 116. In the example embodiment, the MCU mainboard 102 is programmed to carry out control of devices of the vehicle. The MCU mainboard 102 receives feedback of information from sensors distributed about the vehicle. The control of devices and receiving feedback of information from sensors are achieved by connecting the devices and sensors to the I/O ports e.g. 112, 114. The relay switches e.g. 108, 110 are used to switch the devices on and off via the I/O ports e.g. 112, 114. The GSM communication module 106 provides wireless communication between a remote user device and the MCU mainboard 102. The remote user can control the MCU mainboard 102 via the GSM communication module 106. Therefore, the remote user can control the devices in the vehicle and receive feedback information from the sensors via the MCU mainboard 102.

In the example embodiment, the system can implement functions that can be remotely controlled by the user and the functions comprise utilising devices and sensors in the vehicle. The functions in the example embodiment are a Drink Driving Control, a Drowsy Driving Control, a Teenage Driver Behavior Control, a Carbon Monoxide Detection Control, a Battery Auto Charge Control, a Location Reminder Control, a Tire Pressure and Anti-Tow Monitoring Control, a GSM/GPS/Wi-MAX Tracking and Broadcast Control, a Remote Start Engine Control, a Anti Rob / Anti Hijack Control and a Temporary Parking Control.

In the example embodiment, communication using the GSM communication module 106 is carried out by both a voice guidance system and a SMS system. The voice guidance system guides the remote user to press different buttons on the calling device of the remote user so as to activate different devices or sensors. The SMS system allows the remote user to activate different devices or sensors of the vehicle based on keywords that are sent in the SMS messages from the remote user. Pre-recorded voice messages can also be played back to the remote user by the GSM communication module 106. In the example embodiment, the SMS system is used mainly because it consumes relatively lower power and also because SMS messages can be put on-hold if a GSM network connection is too weak to make calls or to send SMS messages. SMS messages can be put on-hold and sent when a GSM network connection is sufficiently strong.

In the example embodiment, the SIM card 116 stores preset numbers. During the occurrence of triggering events that require a communication with the remote user, the system using the GSM communication module 106 dials the stored preset numbers as stored in the SIM card 116. A first preset number in the system is a contact number of the car owner. Other preset numbers may comprise contact numbers of people known to the car owner or the police.

In the example embodiment, with reference to Figure 1(a), the single-chip MCU 104 encompasses a CPU 103, memory 105 and I/O ports 107, all coupled to an internal bus 109. It has been recognised that using a single-chip MCU in the example embodiment can provide a number of advantages compared to implementations using stand-alone components. The advantages can include lower power consumation, a greater range of operating temperatures, and a more compact and thus less complex circuit design.

It has been recognised that although a typical stand-alone CPU may provide more processing power and may deal with more complex calculations, available single-chip MCUs 104 can be used in implementing the desired functionality in the example embodiment. Furthermore, it has been recognised that using a MCU 104, the I/O ports 107 provide simple, readily available interfaces to the components such as relay switches 108, 110. This decreases the circuit design complexity and may even enable a plug-and-play design for additional components for upgrading functionality. Furthermore, another advantage of a single-chip MCU over a stand-alone CPU can be the difference in cost of using a single-chip MCU. A single-chip MCU is typically cheaper than a stand-alone CPU and may typically require lower-level programming leading to relatively easier development than using "machine language" for programming a stand-alone CPU. The various functions that are implemented by the on-board system in the example embodiment will now be described.

Drink Driving Control

For implementing the Drink Driving Control function for the system in the example embodiment, with reference to Figure 2, the MCU mainboard 102 is coupled to a fingerprint reader unit 204, to an alcohol tester 206, to an engine immobilizer unit 208, to an alarm system 210, to output speakers 212, to a pair of test buttons 214, 215, to a cold water micro spray unit 216, to a pair of Light Emitting Diodes (LEDs) 218, 220, to a microphone 222, to a Global Positioning System (GPS) unit 224, to a camera 226 and to the car audio system 228.

In the example embodiment, the engine immobilizer unit 208 can prevent the vehicle from operating by cutting off the fuel supply to the vehicle fuel pump. The pair of test buttons 214, 215 is located at the base of the vehicle steering wheel. The first test button 214 is located on the left of the steering wheel and the second test button 215 is located on the right of the steering wheel. In the example embodiment, the cold water micro spray unit 216 is located next to the support base of the steering wheel. The pair of LEDs 218, 220 is located on the display panel of the vehicle. The first LED 218 is located on the left side of the display panel while second LED 220 is located on the right side of the display panel.

In the example embodiment, the alarm system 210 comprises sounding a siren by utilising the output speakers 212 and switching on the hazard lights of the vehicle. This may allow other vehicles to be alerted.

In the example embodiment, with reference to Figure 3, the fingerprint reader unit 204 is located on the control panel 302 of the vehicle for relative ease of access by the driver. Figure 4 is a flowchart illustrating the process of the Drink Driving Control function in the example embodiment. At step 402, a driver can verify his identity and activate the Drink Driving Control function by utilising the fingerprint reader unit 204 (Figure 2). Alternatively, the Drink Driving Control function can be activated (i) by preset timing such as auto activating the Drink Driving Control function after 10 pm, (ii) through manual switch on by the driver not recognised by the fingerprint reader unit 204 (Figure 2) or (iii) with the help of a third party. At step 404, the driver takes an alcohol test by utilising the alcohol tester 206 (Figure 2). At step 406, the alcohol tester 206 (Figure 2) determines if the driver is drunk by analysing the alcohol level in the driver's breath.

If the driver passes the alcohol test at step 406 with no detected alcohol, at step 408, the engine immobilizer unit 208 (Figure 2) is deactivated and the driver retains full control of the vehicle. If the driver fails the alcohol test at step 406, at step 410, the system dials a preset number of a second user other than the driver, to inform the second user that the driver is drunk. At step 410, if the second user cannot be contacted by the system, the system dials a preset number of a third user. Similarly, preset numbers of a fourth user and a fifth user are stored in the system if the other users cannot be contacted. At step 412, the alarm system 210 (Figure 2) is activated and the engine immobilizer unit 208 (Figure 2) is then utilised to prevent the driver from operating the vehicle. In the example embodiment, the user contacted by the system can allow a designated driver to operate the vehicle while the user can remotely monitor the vehicle in real-time via the GPS unit 224. The designated driver can be a policeman or an appointed driver recognised by the user.

If the driver passes the alcohol test at step 406 but with alcohol detected in the driver's breath, at step 416, the system dials the preset number of the second user other than the driver, to inform the second user that the driver is drunk. Steps 416 and 410 are substantially identical in that more than one preset numbers may be dialled by the system. At step 418, the driver is subjected to a series of reaction tests. Detailed description of the series of reaction tests are provided later in this description. If the driver fails the series of reaction tests at step 418, at step 420, the system dials the preset number of the second user other than the driver, to inform the second user that the driver is drunk or a SMS message reading "Driver Drink Test Failed" is sent to the preset numbers. Steps 420 and 410 are substantially identical in that more than one preset numbers may be dialled by the system. At step 422, the alarm system 210 (Figure 2) is activated and the engine immobilizer unit 208 (Figure 2) is then utilised to prevent the driver from operating the vehicle. At step 424, only another user, other than the driver, can utilise the fingerprint reader unit 204 (Figure 2) to deactivate the engine immobilizer unit 208 (Figure 2). In the example embodiment, the engine immobilizer unit 208 (Figure 2) can be deactivated remotely by another user, other than the driver, by utilising a phone with one of the preset numbers.

In the example embodiment, if there is no response from the user contactable by the preset number at steps 410 or 420, e.g. after a period of about ten minutes, the system activates a critical rescue function at step 430. The critical rescue function automatically activates the remote immobilization system. Activating the remote immobilization system comprises, in an example embodiment, switching on the hazard lights of the vehicle to alert other vehicles behind and playing a voice- recorded 30-seconds countdown through the output speakers 212 (Figure 2). In the example embodiment, after the 30-seconds countdown is completed, the remote immobilization system activates the engine immobilizer unit 208 (Figure 2), forcing the vehicle to slow down and stop. The remote immobilization system then activates a siren through the output speakers 212 (Figure 2), which can alert other vehicles nearby to assist the driver. The hazard lights and the siren are not switched off in the example embodiment.

In the example embodiment, after activating the critical rescue function at step 430, the system continues to dial the preset numbers at an interval of e.g. about five minutes for a period of about 60 minutes. If no user can be contacted after the period of 60 minutes, the system sends a SMS message reading "Times up, vehicle back to normal" to the preset numbers and allows the driver to deactivate the engine immobilizer unit 208 (Figure 2). In the example embodiment, after activating the engine immobilizer unit 208 (Figure 2) at steps 412 and 422, the driver is continually subjected to the series of reaction tests. If the driver passes three consecutive reaction tests, the engine immobilizer unit 208 (Figure 2) is deactivated to allow the driver to operate the vehicle. The siren and hazard lights are switched off and the system sends a SMS message reading "Vehicle back to normal" to the preset numbers.

In the example embodiment, the user contacted by the system can remotely converse with the driver of the vehicle and can remotely take over control of the vehicle. By remotely conversing with the driver of the vehicle, the user can advise the driver to take public transport. In the example embodiment, if necessary, the user can remotely stop the vehicle and provide GPS location tracking information to services such as the police or an ambulance by utilising the GPS unit 224.

If the driver passes the series of reaction tests at step 418, at step 426, the engine immobilizer unit 208 (Figure 2) is deactivated for the driver to operate the vehicle. At step 428, a SMS message reading "Driver is OK" is sent to the preset number of the second user other than the driver.

Figure 5 is a flowchart illustrating the process of the series of reaction tests in the example embodiment. The series of reaction tests comprise a dual button interaction test in the example embodiment. The dual button interaction test is passed when a LED on one side is matched by pressing a test button on the opposite side. For example, a LED lit on the left side is matched by pressing a test button on the right.

At step 502, the system turns on the first LED 218 (Figure 2) on the left side of the display panel together with an alert sound gradually increasing in volume, the sound being outputted using the output speakers 212 (Figure 2). At step 504, a check is made to determine if the driver pressed the second test button 215 (Figure 2). If the driver pressed the second test button 215 (Figure 2) at step 504, at step 506, the system turns off the first LED 218 (Figure 2) and the alert sound. The driver is deemed to have passed a first reaction test of the series of reaction tests. After about three minutes, at step 508, the system turns on the second LED 220 (Figure 2) on the right side of the display panel and together with the alert sound gradually increasing in volume. At step 510, a check is made to determine if the driver pressed the first test button 214 (Figure 2). If the driver pressed the first test button 214 (Figure 2) at step 510, at step 512, the system turns off the second LED 220 (Figure 2) and the alert sound. The driver is deemed to have passed a second reaction test of the series of reaction tests and the series of reaction tests. In the example embodiment, the series of reaction tests starts again, ie. at step 502, after about three minutes.

In the example embodiment, the sequence of switching on either the first LED 218 (Figure 2) or the second LED 220 (Figure 2) is randomly selected at steps 506 and 508.

If the driver presses the wrong button at step 504 or at step 510, ie. the first test button 214 (Figure 2) or the second test button 215 (Figure 2) respectively, at step 514, an alert buzzer sound is outputted using the output speakers 212 (Figure 2) and a fine spray of mist from the cold water micro spray unit 216 (Figure 2) is sprayed at the driver. The fine spray of mist may keep the driver awake. At step 516, the driver is then subjected to a fresh reaction test immediately, as described in either step 506 or step 508. In the example embodiment, if the driver fails three consecutive reaction tests in the series of reaction tests, the driver is deemed to have failed the series of reaction tests. The result of the series of reaction tests is returned to the system to be processed at step 418 of Figure 4.

In summary, in relation to the series of reaction tests in the example embodiment, the driver is deemed to have failed the series of reaction tests if the driver fails three consecutive reaction tests. The driver is deemed to have passed the series of reaction tests if the driver passes two consecutive reaction tests. In the example embodiment, the series of reaction tests at step 418 (Figure 4) is repeated at about every three minutes.

In the example embodiment, by integrating the system with the car audio system 228 (Figure 2), the system can increase the car audio volume until the driver passes each reaction test.

In the example embodiment, the microphone 222 (Figure 2) allows the driver to converse with the remote user of the second preset number and the user can advise the driver to, if applicable, take public transport. The remote user can also utilise the microphone 222 (Figure 2) to communicate with members of the public, in addition to the driver. In the example embodiment, the remote user can prevent the vehicle key from being stolen by members of the public. Preventing the vehicle key from being stolen may be achieved by the remote user winding up the windows of the vehicle and locking the vehicle doors. A typical in-vehicle alarm system may be armed as well, if available in the vehicle. The remote user may disallow any other mechanisms to disarm the in-vehicle alarm system or to open the vehicle doors. The remote user may set the system to sound an alarm siren via the output speakers 212 (Figure 2) and to activate the engine immobilizer unit 208 (Figure 2) if a door to the vehicle is opened manually. The remote user may converse with the person opening the door of the vehicle by utilising the output speakers 212 (Figure 2) and the microphone 222 (Figure 2).

In the example embodiment, the GPS unit 224 (Figure 2) can provide GPS location data to the remote user. The remote user can request a photo via Multimedia Message System (MMS) by using the camera 226 (Figure 2). Communication between the remote user and the system is maintained using the MCU mainboard 102 (Figure 2). In the example embodiment, with the GPS location data, the remote user can log-in to the internet to view the location of the vehicle.

In the example embodiment, the Drink Driving Control function resets after about 4 hours upon activation. Therefore, the driver cannot disable the engine immobilizer unit 208 (Figure 2) using his mobile phone before resetting of the Drink Driving Control function.

In the example embodiment, the Drink Driving Control function can improve the safety of other road users as well as the driver of the vehicle if alcohol is detected in the driver. Based on reaction tests, prevention of accidents is enhanced if it is determined that the driver cannot pass the series of reaction tests. The Drink Driving Control function can also allow other users to remotely converse with the driver as well as remotely controlling the vehicle engine. In addition, the Drink Driving Control function can prevent other in-car passengers, other than the driver, from providing positive results to the alcohol tester 206 (Figure 2) and thereby deactivating the engine immobilizer unit 208 (Figure 2) for the driver, e.g. by utilising the fingerprint reader unit 204 (Figure 2).

Drowsy Driving Control

For implementing the Drowsy Driving Control function for the system in the example embodiment, with reference to Figure 6, the MCU mainboard 102 is coupled to the fingerprint reader unit 204, to the engine immobilizer unit 208, to the alarm system 210, to the output speakers 212, to an air freshener 602 and to an atomization humidifier 604.

In the example embodiment, the air freshener 602 and the atomization humidifier 604 are located on top of air conditioning of the vehicle and can be directed at the driver of the vehicle.

Figure 7 is a flowchart illustrating the process of the Drowsy Driving Control function in the example embodiment. At step 702, a driver can verify his identity and activate the Drowsy Driving Control function by utilising the fingerprint reader unit 204 (Figure 6). Alternatively, the Drowsy Driving Control function can be activated (i) by preset timing such as auto activating the Drowsy Driving Control function after 10 pm, (ii) through manual switch on by the driver not recognised by the fingerprint reader unit 204 (Figure 6) or (iii) with the help of a third party. At step 704, the driver is subjected to a series of reaction tests.

In the example embodiment, the series of reaction tests of the Drowsy Driving Control function is substantially similar to the series of reaction tests as described with reference to Figure 5.

If the driver fails the series of reaction tests at step 704, at step 706, the system dials a preset number of a second user other than the driver, to inform the second user that the driver is drowsy or a SMS message reading "Driver Drowsy Test Failed" is sent to the preset numbers. At step 706, if the second user cannot be contacted by the system, the system dials a preset number of a third user. Similarly, preset numbers of a fourth user and a fifth user are stored in the system if the other users cannot be contacted. The second user can then speak to the driver via the output speakers 212 (Figure 6). At step 708, the alarm system 210 (Figure 6) is activated and the engine immobilizer unit 208 (Figure 6) is then utilised to prevent the driver from operating the vehicle. At step 710, only another user, other than the driver, can utilise the fingerprint reader unit 204 (Figure 6) to deactivate the engine immobilizer unit 208 (Figure 6). In the example embodiment, the engine immobilizer unit 208 (Figure 6) can be deactivated remotely by another user, other than the driver, by utilising a phone with one of the preset numbers.

In the example embodiment, at step 712, the system activates the critical rescue function as described with reference to step 430 (Figure 4) if there is no response from the user contactable by the preset number after a period of about ten minutes. The critical rescue function automatically activates the remote immobilization system. The remote immobilization system is as described in the Drink Driving Control function. In the example embodiment, after activating the critical rescue function, the system continues to dial the preset numbers at an interval of e.g. about five minutes for a period of about 60 minutes. If no user can be contacted after the period of 60 minutes, the system sends a SMS message reading "Times up, vehicle back to normal" to the preset numbers and allows the driver to deactivate the engine immobilizer unit 208 (Figure 6).

In the example embodiment, after activating the engine immobilizer unit 208 (Figure 6) at step 708, the driver is continually subjected to the series of reaction tests. If the driver passes three consecutive reaction tests, the engine immobilizer unit 208 (Figure 6) is deactivated to allow the driver to operate the vehicle. The siren and hazard lights are switched off and the system sends a SMS message reading "Vehicle back to normal" to the preset numbers.

In the example embodiment, as is similar to the Drink Driving Control function, the user contacted by the system can remotely converse with the driver of the vehicle and can remotely take over control of the vehicle. By remotely conversing with the driver of the vehicle, the user can advise the driver to take public transport. In the example embodiment, if necessary, the user can remotely stop the vehicle and provide GPS location tracking information to services such as the police or an ambulance by utilising the GPS unit 224.

If the driver passes the series of reaction tests at step 704, at step 716, the engine immobilizer unit 208 (Figure 6) is deactivated for the driver to operate the vehicle. A SMS message reading "Driver is OK" is sent to the preset number of the second user other than the driver. If the driver passes the series of reaction tests at step 704, the series of reaction tests may be repeated, e.g. every about three minutes.

In the example embodiment, the Drowsy Driving Control function can prevent accidents by determining if the driver of the vehicle is alert enough to operate the vehicle based on reaction tests. Other users can also assist in enhancing the safety of the driver and road users by having the options of remotely stopping the vehicle and conversing with the driver.

Teenage Driver Behavior Control For implementing the Teenage Driver Behavior Control function for the system in the example embodiment, with reference to Figure 8, the MCU mainboard 102 is coupled to the fingerprint reader unit 204, to the engine immobilizer unit 208, to the alarm system 210, to the output speakers 212, to the car audio system 228, to a seat belt sensor 802 and to a speed limit monitor 804.

Figure 9 is a flowchart illustrating the process of the Teenage Driver Behavior Control function in the example embodiment. At step 902, a driver can verify his identity by utilising the fingerprint reader unit 204 (Figure 8). At step 904, system activates the Teenage Driver Behavior Control if the driver is e.g a teenager. At step 906, the seat belt sensor 802 (Figure 8) checks if the seat belt is being used on the driver. If the seat belt is being used on the driver at step 906, the system proceeds to step 908 to check if the vehicle speed limit has been exceeded by utilising the speed limit monitor 804 (Figure 8). In the example embodiment, the speed limit monitor 804 (Figure 8) determines the speed limit as having been exceeded if the excess speed above a predetermined speed is more than about 20 km/h. The speed of the vehicle can also be monitored by GPS, if available. If the seat belt is not being used on the driver at step 906, at step 910, an alert sound is output through the output speakers 212 (Figure 8). If the seat belt is not used, the alert sound is not switched off at step 910 and a SMS message reading "Driver speeding" is sent to a preset number of a second user other than the driver e.g. a parent of the driver. After step 910, the Teenage Driver Behavior Control function process continues to step 908. If the speed limit is not exceeded at step 908, the Teenage Driver Behavior Control function loops back to monitoring the speed limit.

If the speed limit has been exceeded at step 908, at step 912, an alert sound is output through the output speakers 212 (Figure 8) and the car audio system 228 (Figure 8) mutes any output. At step 914, a check is made to determine if the speed limit is still being exceeded. If the speed limit is not being exceeded at step 914, the Teenage Driver Behavior Control function process returns to speed limit monitoring at step 908. If the speed limit is still being exceeded at step 914, at step 916, the alarm system 210 (Figure 8) is activated and the system dials the preset number of the second user other than the driver e.g. the parent of the driver, to inform the second user that the driver is driving above the speed limit. At step 916, if the second user cannot be contacted by the system, the system dials a preset number of a third user. Similarly, preset numbers of a fourth user and a fifth user are stored in the system if the other users cannot be contacted. The driver can then be spoken to by e.g. the parent of the driver via the output speakers 212 (Figure 8). At step 918, the second user can activate the engine immobilizer unit 208 (Figure 8) to slow down the vehicle. At step 920, the second user can restore/un-mute the car audio system 228 (Figure 8).

In the example embodiment, the driver scans his fingerprint on the fingerprint reader unit 204 (Figure 8) at a fixed interval of about 10 minutes, in order for the system to prevent others from driving the vehicle.

In the example embodiment, the Teenage Driver Behavior Control function can allow parents of teenagers to be informed if the teenagers are driving at excessive speeds. Muting of entertainment systems such as the car audio system can remove distractions from the driver of the vehicle.

Carbon Monoxide Detection Control

For implementing the Carbon Monoxide Detection Control function for the system in the example embodiment, with reference to Figure 10, the MCU mainboard 102 is coupled to the engine immobilizer unit 208, to the output speakers 212, to the microphone 222, to the GPS unit 224, to a carbon monoxide sensor 1002, to a carbon monoxide alert LED 1004, to a window controller 1006, to an electronic compass 1008, to a wheel sensor 1010 and to a carbon monoxide alert reset button 1012. In the example embodiment, the carbon monoxide alert LED 1004 and carbon monoxide alert reset button 1012 are located on the display panel of the vehicle, within close proximity to the driver of the vehicle.

Figure 11 is a flowchart illustrating the process of the Carbon Monoxide Detection Control function in the example embodiment. At step 1102, the carbon monoxide sensor 1002 (Figure 10) detects a predetermined level of carbon monoxide. At step 1104, the system flashes the carbon monoxide alert LED 1004 (Figure 10) and plays a prerecorded voice message "Carbon monoxide reading is too high" via the output speakers 212 (Figure 10). At step 1104, the system also winds down the windows by utilising the windows controller 1006 (Figure 10). At step 1106, the system determines if the vehicle is moving or stationary by comparing the readings from GPS unit 224 (Figure 10), electronic compass 1008 (Figure 10) and the wheel sensor 1010 (Figure 10). If the vehicle is determined to be moving at step 1106, the system stops any further action other than the actions in step 1104 and at step 1116, the system allows the driver to take action as the driver may be adequately alerted by the prerecorded voice message and the wound down windows.

If the vehicle is determined to be stationary at step 1106, at step 1108, a check is made to determine if the driver has pressed the carbon monoxide alert reset button 1012 (Figure 10) after a window period of about ten seconds. If the carbon monoxide alert reset button 1012 (Figure 10) is pressed within the window period at step 1108, at step 1110, the system turns off the carbon monoxide alert LED 1004 (Figure 10) and stops playing the prerecorded voice message as described at step 1104. If the carbon monoxide alert reset button 1012 (Figure 10) is not pressed within the window period at step 1108, at step 1112, a siren is activated via the output speakers 212 (Figure 10). At step 1114, the system dials the preset number of the second user other than the driver to inform the second user that the driver is in the vehicle with high carbon monoxide level detected or a SMS message reading "High Carbon Monoxide level detected" is sent to the preset numbers. At step 1114, if the second user cannot be contacted by the system, the system dials a preset number of a third user. Similarly, preset numbers of a fourth user and a fifth user are stored in the system if the other users cannot be contacted. The driver can then communicate with the second user via the output speakers 212 (Figure 10) and the microphone 222 (Figure 10). At step 1114, the second user can opt to utilise the engine immobilizer unit 208 (Figure 10) to remotely cut off the engine of the stationary vehicle so as to reduce the carbon monoxide in the vehicle.

In the example embodiment, the Carbon Monoxide Detection Control function can assist in providing safety measures when a relatively high level of carbon monoxide is detected in the vehicle. If the driver of the vehicle cannot react due to carbon monoxide poisoning, the Carbon Monoxide Detection Control function can inform other users after adopting safety measures such as winding down the windows of the vehicle and activating a driver rescue process as described at steps 1112 and 1114 of Figure 11.

Battery Auto Charge Control

For implementing the Battery Auto Charge Control function for the system in the example embodiment, with reference to Figure 12, the MCU mainboard 102 is coupled to an engine controller 1200, to a battery voltage monitor 1202, to an engine monitor 1204, to a handbrake monitor 1206, to a gear shift monitor 1208 and to a tachometer signal monitor 1210.

In the example embodiment, the engine controller 1200 can switch on and off the vehicle engine by receiving electrical signals from an add-on ignition relay switch controlled by the MCU mainboard 102. The tachometer signal monitor 1210 can provide information as to whether the vehicle engine has been started.

In the example embodiment, a vehicle battery that is not recharged by the Battery Auto Charge Control function has a voltage in the range of about 12.6 V to 13.2 V, when the vehicle has its engine switched off. In the example embodiment, if the vehicle has its engine switched on, the vehicle battery is not recharged by the Battery Auto Charge Control function if the voltage of the vehicle battery is in the range of about 14.2 V to 14.6 V. This voltage range is typically a normal vehicle battery voltage range when the vehicle engine is started. If the voltage of the vehicle battery is detected to be below 14.2V when the vehicle engine has been started, it typically means that the vehicle alternator is faulty while if the voltage of the vehicle battery is detected to be above 14.6V when the vehicle engine has been started, it typically means that the vehicle alternator is working normally but the vehicle battery may be faulty.

Figure 13 is a flowchart illustrating the process of the Battery Auto Charge Control function in the example embodiment. At step 1302, the battery voltage monitor 1202 (Figure 12) monitors the voltage of the vehicle battery. At step 1304, the engine monitor 1204 (Figure 12) is utilised to check if the vehicle engine is switched on. If the vehicle engine is switched on at step 1304, at step 1306, the battery voltage monitor 1202 (Figure 12) is utilised to determine the voltage of the vehicle battery. If the voltage of the vehicle battery is below about 14 V at step 1306, at step 1308, a SMS message reading "Alternator Problem" is sent to the preset number of the owner/driver of the vehicle. If the voltage of the vehicle battery is above about 15 V at step 1306, at step 1310, a SMS message reading "Battery Problem" is sent to the preset number of the owner/driver of the vehicle.

If the vehicle engine is not switched on at step 1304, at step 1312, a SMS message or a call is made to the preset number of the driver, to inform the driver to remotely switch on the vehicle engine. The driver can remotely switch on the engine by utilising the engine controller 1200 (Figure 12) through the MCU mainboard 102 (Figure 12). At step 1312, if the driver cannot be contacted by the system, the system dials a preset number of a second user. Similarly, preset numbers of a third user and a fourth user are stored in the system if the other users cannot be contacted. If there are no commands to remotely switch on the vehicle engine at step 1312 after a period of about 60 minutes, at step 1316, a check is made to determine if the handbrake of the vehicle is at the "ON" position by utilising the handbrake monitor 1206 (Figure 12). At step 1318, the gear shift monitor 1208 (Figure 12) is utilised to check if the vehicle gear has been set to a parking gear e.g. "Park" position on an Auto-Transmission gear. If the handbrake of the vehicle is not at the "ON" position at step 1316 or if the vehicle gear has not been set to a parking gear at step 1318, at step 1320, a SMS message or a voice message reading "Engine Start Failed" is sent to the preset number of the driver.

If the handbrake of the vehicle is at the "ON" position at step 1316 and the vehicle gear has been set to a parking gear at step 1318, at step 1322, the vehicle engine is switched on by utilising the engine controller 1200 (Figure 12). At step 1324, a check is made to determine if a tachometer signal output can be detected by utilising the tachometer signal monitor 1210 (Figure 12) or if the voltage of the vehicle battery varies by utilising the battery voltage monitor 1202 (Figure 12). If there is no tachometer signal output detected or if the battery voltage monitor 1202 (Figure 12) does not detect an increment in battery voltage of about +0.5V at step 1324, at step 1326, a SMS message or a voice message reading "Engine Start Failed" is sent to the preset number of the driver. If a tachometer signal output is detected at step 1324 or if the battery voltage monitor 1202 (Figure 12) detects an increment in battery voltage of about +0.5V, at step 1328, a SMS message or a voice message reading "Battery Charging" is sent to the preset number of the driver and the engine monitor 1204 (Figure 12) is utilised to check if the vehicle engine stops before a preset time. The preset time in the example embodiment may be 20, 30 or 40 minutes. If the vehicle engine stops before the preset time at step 1328, at step 1330, a SMS message or a voice message reading "Battery Charging Problem" is sent to the preset number of the driver. If the vehicle engine does not stop before the preset time at step 1328, at step 1332, a SMS message or a voice message reading "Battery Charging Completed" is sent to the preset number of the driver and the vehicle engine is switched off by the system utilising the engine controller 1200 (Figure 12).

In the example embodiment, the Battery Auto Charge Control function can provide recharging of the vehicle battery if the voltage is found to be too low. Location Reminder Control

For implementing the Location Reminder Control for the system in the example embodiment, with reference to Figure 14, the MCU mainboard 102 is coupled to the output speakers 212, to the GPS unit 224, to the electronic compass 1008, to a GPS reminder panel 1402, to a GPS warning LED 1404 and to a short range wireless receiver 1406.

In the example embodiment, the GPS unit 224 is utilised together with the electronic compass 1008 by the MCU mainboard 102 so as to improve signal coverage when the GPS signal from the GPS unit 224 is weak. In the example embodiment, the Location Reminder Control function allows zone reminding when the vehicle is travelling on the road.

In the example embodiment, with reference to Figure 15, the Location Reminder Control function comprises a software database 1502 containing different groups of data. The Location Reminder Control function operates by reading GPS data from the database 1502 and comparing real-time GPS data from the GPS unit 224 (Figure 14).

Referring to Figure 15, in the example embodiment, Group A and Group B contain GPS data relating to fixed location information of speed cameras and red light cameras respectively. Group C contains both GPS data relating to location information of Electronic Road Pricing (ERP) gantries and time-based ERP fees information relating to each ERP gantry. Groups D, E and F contain user-defined GPS data relating to zonal information while Groups H, J and I contain miscellaneous GPS data relating to vehicle-inaccessible zones.

With reference to Figure 16, at step 1602, the GPS unit 224 is used to analyze the area the vehicle is travelling along. At step 1604, if a reminder is applicable based on information received by the Location Reminder Control function, a pre-recorded voice message is played by utilising the output speakers 212 (Figure 14).

In the example embodiment, the driver is alerted for the following situations. When the vehicle is about 300 meters away from a speed camera, the system plays a pre-recorded voice message "Speed Camera 80 in front" by utilising the output speakers 212 (Figure 14) to alert the driver that the speed limit is 80 km/h. When the vehicle is about 100 meters away from a junction and red light camera, the system plays a pre-recorded voice message "Careful, Junction & Red light Camera in front" by utilising the output speakers 212 (Figure 14) to alert the driver. When the vehicle is about 300 meters away from an ERP gantry, the system determines the location, time and fees from the database and plays a voice message "Prepare $2 for ERP Gantry" by utilising the output speakers 212 (Figure 14) to alert the driver.

In the example embodiment, in addition to fixed locations, the Location Reminder Control function provides reminders when the vehicle approaches zones. When the vehicle is about 100 meters away from a school fixed zone, the system plays a pre-recorded voice message "Slow down" by utilising the output speakers 212 (Figure 14) and the system flashes the GPS warning LED 1404 (Figure 14). In the example embodiment, the system repeats the pre-recorded voice message after about 5 seconds if the vehicle moves within the school zone. If the vehicle is approaching a landslide high-risk zone, the system plays a pre-recorded voice message "Be careful, Landslide high-risk zone" by utilising the output speakers 212 (Figure 14) and the system flashes the GPS warning LED 1404 (Figure 14). The system repeats the pre-recorded voice message after about 5 seconds if the vehicle moves within the landslide high-risk zone.

In the example embodiment, the Location Reminder Control function provides speed limit control with regards to different speed zones. In the example embodiment, the system turns on the GPS warning LED 1404 (Figure 14) if the speed of the vehicle exceeds the zone speed limit by more than 10km/h. In the example embodiment, the system flashes the GPS warning LED 1404 (Figure 14) when the speed of the vehicle exceeds the zone speed limit by more than 20km/h. When the speed of the vehicle exceeds the zone speed limit by more than 30km/h, the system plays a pre-recorded voice message "You are driving too fast now", in the example embodiment.

In the example embodiment, besides utilising the GPS unit 224 (Figure 14), the MCU mainboard 102 (Figure 14) can also utilise the short range wireless receiver 1406 (Figure 14) to communicate using wireless technologies such as Bluetooth, Radio Frequency Identification (RFID) and Wi-Fi.

In the example embodiment, the system can utilise the short range wireless receiver 1406 (Figure 14) to communicate with a RFID transponder attached to a school gate or to a bus stop. The Location Reminder Control function can detect the type of zone the vehicle is in and sends an appropriate warning to the driver. In addition, the MCU mainboard 102 (Figure 14) can receive a Cell-ID broadcast from a GSM/CDMA Location Base if applicable and the Location Reminder Control function can then detect the type of zone the vehicle is in through the Cell-ID broadcast and send an appropriate warning to the driver, in the example embodiment.

In the example embodiment, GPS data can be downloaded to the system by utilising the GPS unit 224 (Figure 14) via GPRS or SMS from a central data station. In the example embodiment, the driver can also edit or categorise the GPS data and store the modified GPS data into the system for use by the Location Reminder Control function.

In the example embodiment, GPS data can be edited or categorised with the aid of the GPS reminder panel 1402 (Figure 14). With reference to Figure 17, the GPS reminder panel 1402 comprises a Record button 1702, a Cancel button 1704, a Location button 1706, speed buttons e.g. 1708 and a Warning button 1710. Figure 18 is a flowchart illustrating the process of editing or categorising GPS data for use by the Location Reminder Control function in the example embodiment. At step 1802, the Location Reminder Control function receives GPS data from the GPS unit 224 (Figure 14). At step 1804, the driver presses the Record button 1702 (Figure 17) to input new GPS data. At step 1806, the driver presses the Location button 1706 (Figure 17) to add the current zone to Group D of the database of the Location Reminder Control function. At step 1808, the driver presses the relevant speed button e.g. 1708 (Figure 17) to add the location speed to Group E of the database of the Location Reminder Control function. At step 1810, the driver presses the Warning button 1710 (Figure 17) to add the location warning to the Location Reminder Control function. In the example embodiment, the driver may cancel the modifying process by pressing the Cancel button 1704 (Figure 17). At step 1812, at a later time when the driver is in the vicinity of the recorded location, the system flashes the GPS warning LED 1404 (Figure 14) at about 200 meters away from the preset point. In the example embodiment, data in Group D of the database of the Location Reminder Control function comprises GPS data relating to zones such as traffic junctions, school zones, traffic lights, bus-stops, transport stands and pedestrian crossings. Data in Group E of the database of the Location Reminder Control function comprises road names and corresponding speed limits.

In the example embodiment, data may be entered into Group F of the database of the Location Reminder Control function by receiving SMS messages containing updated information from a GSM subscription database. In the example embodiment, the user of the vehicle may also utilise the GPS reminder panel 1402 (Figure 17) to enter data into Group F of the database of the Location Reminder Control function. By pressing the Location button 1706 (Figure 17) for about 3 seconds, the system generates a request SMS message to an external GSM central database server. The external GSM central database server may send new or updated data via SMS messages back to the MCU mainboard 102 (Figure 14). Based on the SMS messages received, voice-recorded messages may be played back to report any new data updates. An example of a voice-recorded message may read "Accident at the expressway 29km in the direction heading towards Changi Airport and before exit 28. Landslide at North-South Highway 302km mark, North- South Highway now closed".

In the example embodiment, the Location Reminder Control function provides a personalised customisation of a GPS-based guiding alerting system. The Location Reminder Control function can also provide directions to a personalised recorded location.

Tire Pressure and Anti-Tow Monitoring Control

For implementing the Tire Pressure and Anti-Tow Monitoring Control for the system in the example embodiment, with reference to Figure 19, the MCU mainboard 102 is coupled to the output speakers 212, to the microphone 222, to the engine monitor 1204, to a tilt sensor 1902, to a tire pressure reader 1904, to a tire temperature reader 1906 and to a dedicated in-car liquid crystal display (LCD) 1908.

In the example embodiment, the tilt sensor 1902 is relatively more sensitive than typical vibration sensors and is activated if the vehicle is being tilted, ie. lifted at one end.

Figure 20 is a flowchart illustrating the process of the Tire Pressure and Anti- Tow Monitoring Control function in the example embodiment. At step 2002, the Tire Pressure and Anti-Tow Monitoring Control function is activated if the tire pressure readings from the tire pressure reader 1904 (Figure 19) exceeds a preset range or if the tire temperature readings from the tire temperature reader 1908 (Figure 19) exceeds a preset range. In the example embodiment, the tire pressure monitoring range is from about 1.0 Bar pressure to about 4.5 Bar pressure while the tire temperature monitoring range is from about -^40⁰C to about 125⁰C.

At step 2004, a check is made to determine if the vehicle engine is switched on by utilising the engine monitor 1204 (Figure 19). If the vehicle engine is switched on at step 2004, then at step 2005, the Tire Pressure and Anti-Tow Monitoring Control function sounds an alarm by outputting the alarm via the output speakers 212 (Figure 19) and allows the driver to monitor the tire conditions of the vehicle by displaying information on the dedicated in-car LCD 1908 (Figure 19). If the vehicle engine is switched off at step 2004, at step 2006, the Tire Pressure and Anti-Tow Monitoring Control function checks to determine if the tilt sensor 1902 (Figure 19) has been activated. If the tilt sensor 1902 (Figure 19) has not been activated at step 2006, at step 2008, a SMS message comprising the tire condition readings from the tire pressure reader 1904 (Figure 19) and/or the tire temperature reader 1908 (Figure 19) is sent to the preset numbers of the system.

In the example embodiment, the dedicated in-car LCD 1908 (Figure 19) or the SMS messages display the tire condition readings in the following standard display format:

"Warning

Vehicle No.XXXX

<Tire Position> NG

<Tire 3 reading e.g. 2.50> <Tire 4 reading e.g. 2.50>"

In the example embodiment, with reference to the standard display format, the tire position of a tire with out-of-range pressure and/or temperature readings is indicated by left anterior, right anterior, right posterior and left posterior. The tire condition comprises a selection from Fast Leakage, Slow Leakage, Low Pressure Alarm, High Pressure Alarm and High Temperature Alarm. In addition, for ease of reference, the dedicated in-car LCD 1908 (Figure 19) can display different icons for different tire conditions.

In the example embodiment, Fast Leakage refers to a drop in tire pressure of about 0.2 Bar pressure in about one minute while Slow Leakage refers to a drop in tire pressure of about 0.2 Bar pressure in a range of about two to ten minutes. In the example embodiment, the Low Pressure Alarm is triggered if the tire pressure reading is less than about 25% of the standard tire pressure while the High Pressure Alarm is triggered if the tire pressure reading is more than about 20% of the standard tire pressure. In the example embodiment, the High Temperature Alarm is triggered if the tire temperature exceeds a value of about 75⁰C. In the example embodiment, if the tire temperature exceeds a value of about 85⁰C, the alarm sound is replaced by a relatively louder alarm siren being outputted via the output speakers 212 (Figure 19).

If the tilt sensor 1902 (Figure 19) has been activated at step 2006, at step 2010, an alarm siren is sounded via the output speakers 212 (Figure 19) and a SMS message is sent to the preset numbers of the system. At step 2012, the system dials a preset number of a first user to allow the first user to listen to any sounds of the car through the microphone 222 (Figure 19). If the first user cannot be contacted by the system, the system dials a preset number of a second user. Similarly, preset numbers of a third user, fourth user and a fifth user are stored in the system if the other users cannot be contacted. In the example embodiment, the SMS message is displayed in the following standard display format:

"Warning

Vehicle No.XXXX

Vehicle moving

Without engine on"

In the example embodiment, the Tire Pressure and Anti-Tow Monitoring Control function can allow the driver of the vehicle to be aware of the tire pressure of the tires of the vehicle. The Tire Pressure and Anti-Tow Monitoring Control function can provide security monitoring if the vehicle is being towed away without the knowledge of the driver.

Remote Start Engine Control

For implementing the Remote Start Engine Control for the system in the example embodiment, with reference to Figure 21, the MCU mainboard 102 is coupled to the GPS unit 224, to the carbon monoxide sensor 1002, to the electronic compass 1008, to the wheel sensor 1010, to the engine controller 1200, to the engine monitor 1204, to the handbrake monitor 1206, to the gear shift monitor 1208, to the tachometer signal monitor 1210, to an In-vehicle temperature sensor 2102, to an ultrasonic detector 2104, to an engine temperature sensor 2106 and to the battery voltage monitor 1202.

In the example embodiment, the ultrasonic detector 2104 can detect intrusions by monitoring differences in sound waves in the vehicle. In the example embodiment, the engine controller 1200 is coupled to an ACC relay switch, an ON relay switch and a START relay switch. The ACC relay switch, the ON relay switch and the START relay switch are located next to the vehicle ignition switch or the vehicle ignition wire at the vehicle fuse box.

In the example embodiment, the process of switching on the vehicle engine in the Remote Start Engine Control function is substantially similar to the process as described in the Battery Auto Charge Control function

Figure 22 is a flowchart illustrating the process of the Remote Start Engine Control function in the example embodiment. At step 2202, the driver can either dial into the system or send a SMS message to activate the Remote Start Engine Control function. At step 2204, the system utilises the gear shift monitor 1208 (Figure 21) and the handbrake monitor 1206 (Figure 21) respectively to check whether the handbrake is engaged and whether the vehicle gear has been set to a parking gear e.g. "Park" position on an Auto-Transmission gear. If either the handbrake is not engaged or the vehicle gear has not been set to a parking gear at step 2204, at step 2206, a SMS message or a prerecorded voice message reading "Remote Start Failed" is sent to the driver. If both the handbrake is engaged and the vehicle gear has been set to a parking gear at step 2204, at step 2208, the ACC relay switch, the ON relay switch and the START relay switch are turned on. The START Relay switch is turned on for about 0.5 second to simulate starting a vehicle. At step 2210, a check utilising the engine monitor 1204 (Figure 21), the battery voltage monitor 1202 (Figure 21) and the tachometer signal monitor 1210 (Figure 21) is made to determine if the vehicle engine has been started. If the tachometer signal monitor 1210 (Figure 21) does not give an output at step 2210 or the battery voltage monitor 1202 (Figure 21) does not detect an increase of at least +0.5V in the vehicle battery voltage, at step 2212, the START Relay switch is turned on for about 0.75 second. If the tachometer signal monitor 1210 (Figure 21) does not give an output at step 2212 or the battery voltage monitor 1202 (Figure 21) still does not detect an increase of at least +0.5V in the vehicle battery voltage, at step 2214, the START Relay switch is turned on for about 1 second. If the tachometer signal monitor 1210 (Figure 21) does not give an output at step 2214 or the battery voltage monitor 1202 (Figure 21) does not detect an increase of at least +0.5V in the vehicle battery voltage for the third time, a SMS message or a prerecorded voice message reading "Remote Start Failed" is sent to the driver.

If the tachometer signal monitor 1210 (Figure 21) provides a tachometer output at steps 2210, 2212 or 2214, or the battery voltage monitor 1202 (Figure 21) detects an increase of at least +0.5V in the vehicle battery voltage, at step 2216, a SMS message or a prerecorded voice message reading "Engine Started" is sent to the driver. At step 2218, after a preset timing of the system for remote starting the vehicle engine, the vehicle engine is switched off by the system utilising the engine controller 1200 (Figure 21) and a SMS message or a prerecorded voice message reading "Engine Stop" is sent to the driver. If the preset timing of the system for remote starting the vehicle engine has not expired before the driver wishes to operate the vehicle at step 2218, the system returns control of the vehicle to the driver when the vehicle key is inserted into the ignition.

In the example embodiment, the preset timing of the system for remote starting the vehicle engine can be set up to one hour. The driver may request the system to send the reading of the In-Vehicle temperature sensor 2102 (Figure 21) via SMS so that the temperature conditions in the vehicle can be monitored. In the example embodiment, precaution steps are taken after the vehicle engine is turned on. By utilising the electronic compass 1008 (Figure 21), the GPS unit 224 (Figure 21) and the wheel sensor 1010 (Figure 21), if the vehicle is determined to have moved for more than about 0.5 cm or the angle of the wheels has changed by more than 5 degrees within about 0.1 second, the system switches off the vehicle engine.

In the example embodiment, for security reasons, if the ultrasonic detector 2104 (Figure 21) determines that there is an intrusion, the vehicle engine is switched off by the system. In the example embodiment, if the handbrake monitor 1206 (Figure 21) determines that the handbrake is being disengaged without disabling the Remote Start Engine control function, the system switches off the vehicle engine.

In the example embodiment, if the carbon monoxide sensor 1002 (Figure 21) determines that there is a high level of carbon monoxide in the vehicle, the system sends the reading of the carbon monoxide sensor 1002 (Figure 21) via a SMS message to inform the driver and the system may switch off the vehicle engine.

In the example embodiment, based on the readings of the engine temperature sensor 2106 (Figure 21), the driver can opt to remote start the vehicle engine.

With reference to Figure 23, at step 2302, the engine temperature sensor 2106 (Figure 21) detects that the engine temperature is below O⁰C. At step 2304, the system sends a SMS message reading "Cold Start Engine needed" to the driver. At step 2306, the driver remotely starts the vehicle engine to warm up the vehicle engine. At step 2308, the system switches on the vehicle engine and sends a SMS message "Cold start now, Temperature reading 0⁰C" to inform the driver.

In the example embodiment, if the driver does not remotely start the vehicle engine, the system activates the Remote Start Engine Control function if the temperature remains at 0⁰C for more than 5 minutes in the example embodiment. The system repeats the process described above with reference to Figure 23 for 24 hours in the example embodiment. The system resets after 24 hours and sends a SMS message "Cold Start Reset" to the driver. For example, if the driver sends a SMS message command reading 'No Cold Start' to the system, the system waits for 24 hours to reset Remote Start Engine Control function. In the example embodiment, the driver can activate or deactivate the Remote Start Engine Control function anytime.

In the example embodiment, the Remote Start Engine Control function can allow a vehicle engine to be started so that the air-conditioning of the vehicle is activated. Starting the air-conditioning of the vehicle is useful in lowering the in- vehicle temperature as well as reducing pollutants in the vehicle which may have come about due to rising temperatures, thus improving the comfort level of the driver. The Remote Start Engine Control function can also provide a cold start option to the driver in the event if the driver decides to warm up the vehicle engine remotely when the vehicle engine is at a low temperature, for example at O⁰C.

Anti Rob / Anti Hijack Control

For implementing the Anti Rob / Anti Hijack Control for the system in the example embodiment, with reference to Figure 24, the MCU mainboard 102 is coupled to the engine immobilizer unit 208, to the output speakers 212, to the cold water micro spray unit 216, to the microphone 222, to an electronic stun pad 2402 and to a Panic button 2404.

In the example embodiment, the electronic stun pad 2402 is located under the seat of the driver as an offensive measure. The Panic button 2404 is located on the display panel of the vehicle and in close proximity to the driver.

In the example embodiment, the owner/driver of the vehicle can utilise the Anti rob / Anti Hijack Control function to remotely stop the vehicle in the event if the vehicle has been stolen. In the example embodiment, the owner/driver may remotely utilise the engine immobilizer unit 208 (Figure 24) to disable the fuel pump of the vehicle for a plurality of times with an increasing interval between each time the engine immobilizer unit 208 (Figure 24) is activated. After a preset number of times of activating the engine immobilizer unit 208 (Figure 24), the system switches off the vehicle engine completely by utilising engine immobilizer unit 208 (Figure 24). This may provide the impression to an intruder that the vehicle possesses engine problems. In the example embodiment, the owner/driver can listen to any sound in the vehicle by utilising the microphone 222 (Figure 24).

In the example embodiment, the owner/driver can also remotely communicate with an intruder by dialing into the system by utilising the MCU mainboard 102 (Figure 24). Communication can be carried out by utilising the output speakers 212 (Figure 24) and the microphone 222 (Figure 24). In the example embodiment, the remote immobilization system can be activated by the owner/driver. Activating the remote immobilization system comprises switching on the hazard lights of the vehicle for 5 seconds to alert other vehicles behind and playing a voice-recorded 30-seconds countdown through the output speakers 212 (Figure 24). In the example embodiment, after the 30-seconds countdown is completed, the remote immobilization system activates the engine immobilizer unit 208 (Figure 24), forcing the vehicle to slow down and stop. The remote immobilization system then activates a siren through the output speakers 212 (Figure 24), which can alert other vehicles nearby to assist the driver.

In the example embodiment, after the remote immobilization system is activated, a colour dye containing pepper spray can be sprayed at the intruder by the owner/driver.

In the example embodiment, a dual relay-switch setup is utilised for spraying the colour dye containing pepper spray. With reference to Figure 25, a first relay switch 2502 and a second relay switch 2504 are provided. The first relay switch 2502 is switched on to connect the colour dye to the cold water micro spray unit 216 (Figure 24). The cold water micro spray unit 216 (Figure 24) sprays out the colour dye containing pepper spray after the second relay switch 2504 is switched on. In the example embodiment, the first relay switch 2502 is switched on after about 35 seconds after the engine immobilizer unit 208 (Figure 24) is activated by the remote immobilization system. The second relay switch 2504 may be triggered immediately after the first relay switch 2502 is switched on or may be remotely triggered by the owner/driver. The second relay switch 2504 may also be programmed to be triggered when the intruder turns on the ignition switch of the vehicle after the engine immobilizer unit 208 (Figure 24) is activated.

The owner/driver can remotely utilise the cold water micro spray unit 216 (Figure 24) for this function. The owner/driver can also remotely activate the electronic stun pad 2402 (Figure 24) with a high voltage to deter any intruders. In the example embodiment, the electronic stun pad 2402 (Figure 24) can immobilise an intruder while, the colour dye containing pepper spray can assist in identifying the intruder in the event if the intruder manages to escape.

In the example embodiment, if the owner/driver is in the vehicle when the vehicle has been hijacked, the Anti rob / Anti Hijack Control function can be utilised to remotely stop the vehicle.

In the example embodiment, when the vehicle is hijacked with the owner/driver in the vehicle, the owner/driver can press the Panic button 2404 (Figure 24). The Panic button 2404 (Figure 24) is a press and hold button so as to prevent any false alarms. When the owner/driver presses and holds the Panic button 2404 (Figure 24) for about 2 seconds, the system dials a preset emergency number. The remote user, e.g. the police or a friend, can opt to remotely stop the vehicle by utilising the engine immobilizer unit 208 (Figure 24). The remote user can also listen to any sound in the vehicle by utilising the microphone 222 (Figure 24).

In the example embodiment, the Anti Rob / Anti Hijack Control function can provide security measures when an intruder has taken control of the vehicle. The vehicle can be stopped remotely and offensive measures can be taken against the intruder. The remote user can also monitor events happening in the vehicle as well as communicate with the intruder.

Temporary Parking Control

For implementing the Temporary Parking Control for the system in the example embodiment, with reference to Figure 26, the MCU mainboard 102 is coupled to the output speakers 212, to the tilt sensor 1902 and to the vibration sensor 2602.

Figure 27 is a flowchart illustrating the process of the Temporary Parking Control function in the example embodiment. At step 2702, the driver may decide to park the vehicle temporarily and activates the Temporary Parking Control function by sending a SMS message reading "Park with Engine on" to the system. At step 2704, the system plays back a pre-recorded message via the output speakers 212 (Figure 26) so that the driver checks that the handbrake is engaged and the vehicle gear has been set to a parking gear e.g. "Park" position on an Auto-Transmission gear. At step 2706, after the driver removes the vehicle key from the ignition and closes the door of the vehicle, the system locks the doors of the vehicle after about 10 seconds. At step 2708, the system checks to determine if either the vibration sensor 2602 (Figure 26) or the tilt sensor 1902 (Figure 26) has been activated. If either the vibration sensor 2602 (Figure 26) or the tilt sensor 1902 (Figure 26) has been activated at step 2708, an intrusion is deemed to have occurred. At step 2710, the vehicle engine is switched off by the system by utilising the engine immobilizer unit 208 (Figure 26) and an alarm is activated. At step 2712, a SMS message reading "Alarm Activated" is sent to the driver. At step 2714, the system dials the preset number of the driver and allows the driver to listen to any sound in the vehicle by utilising the microphone 222 (Figure 26). In the example embodiment, if there is no intrusion detected at step 2708, the system returns control of the vehicle to the driver once the vehicle door is unlocked with the vehicle key.

In the example embodiment, the Temporary Parking Control function can allow the driver of the vehicle to leave the vehicle temporarily and can allow security measures to be taken if an intrusion occurs.

In the example embodiment described above, the system can provide an intelligent response system that may perform different functions based on user commands sent remotely. The system can also perform different functions automatically in the absence of user commands.

It will be appreciated by a person skilled in the art that numerous variations and/or modifications may be made to the present invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respects to be illustrative and not restrictive.

Claims

1. An on-board system for controlling one or more devices installed in a vehicle, the system comprising, a microcontroller; a wireless communication module coupled to the microcontroller; one or more sensors installed in the vehicle and coupled to the microcontroller; wherein the microcontroller controls the one or more devices based on signals received from the wireless communication module, the sensors, or both; and wherein the microcontroller initiates a communication to an external communication device via the communication module based on signals received from the sensors.

2. The system as claimed in claim 1 , wherein the devices comprise a first action device; the sensors comprise an alcohol level sensor; and wherein the microcontroller controls the first action device based on signals received from the alcohol level tester and the microcontroller initiates a communication to the external communication device via the communication module based on the signals received from the alcohol level sensor.

3. The system as claimed in claim 2, wherein the devices further comprise an alerting device and a second action device; the sensors comprise a human input device; and wherein the microcontroller instructs a driver reaction test by activating the alerting device based on signals received from the alcohol level tester and the microcontroller controls the second action device based on signals received from the human input device.

4. The system as claimed in claim 3, wherein the alerting device comprises an optical device, a sound device, or both, and wherein the action device comprises a water spray device, the human input device comprises a button, and the first action device comprises an engine immobilizer.

5. The system as claimed in claim 1 , wherein the devices comprise an alerting device and a first action device; the sensors comprise a human input device; and wherein the microcontroller instructs a driver reaction test by activating the alerting device, controlling the first action device based on signals received from the human input device and the microcontroller initiates a communication to the external communication device via the communication module based on the signals received from the human input device.

6. The system as claimed in claim 5, wherein the devices further comprise a second action device; and the microcontroller controls the second action device based on the signals received from the human input device.

7. The system as claimed in claim 6, wherein the human input device comprises a button, the second action device comprises an air freshener, a humidifier, or both, the alerting device comprises an optical device, a sound device, or both, and the first action device comprises an engine immobilizer.

8. The system as claimed in claim 1 , wherein the devices comprise an alerting device; the sensors comprise a driving characteristic sensor; and wherein the microcontroller controls the alerting device based on signals received from the driving characteristic sensor and the microcontroller initiates a communication to the external communication device via the communication module based on the signals received from the driving characteristic sensor.

9. The system as claimed in claim 8, wherein the alerting device comprises an optical device, a sound device, or both, and the driving characteristic sensor comprises a speed sensor, a seatbelt sensor, or both.

10. The system as claimed in claim 1, wherein the devices comprise an action device; the sensors comprise a carbon monoxide sensor; and wherein the microcontroller controls the action device based on signals received from the carbon monoxide sensor and the microcontroller initiates a communication to the external communication device via the communication module based on the signals received from the carbon monoxide sensor.

11. The system as claimed in claim 10, wherein the action device comprises a window controller.

12. The system as claimed in claim 1, wherein the devices comprise an action device; the sensors comprise a voltage monitor coupled to a battery of the vehicle; and wherein the microcontroller controls the action device based on signals received from the voltage monitor for recharging the battery and the microcontroller initiates a communication to the external communication device via the communication module based on the signals received from the voltage monitor.

13. The system as claimed in claim 12, wherein the action device comprises one or more of a group consisting of a starter of the vehicle engine, a gear control device, and a break control device.

14. The system as claimed in claim 1, wherein the devices comprise an alerting device; the sensors comprise a tilt sensor and a engine-off sensor; and wherein the microcontroller controls the alerting device based on signals received from the tilt sensor and the engine-off sensor and the microcontroller initiates a communication to the external communication device via the communication module based on the signals received from the tilt sensor.

15. The system as claimed in claim 1, wherein the devices comprise an engine starter device; the sensors comprise a handbrake detector and a gear shift detector; and wherein the microcontroller controls the engine starter device based on signals received from the communication module, the handbrake detector and the gear shift detector, and the microcontroller initiates a communication to the external communication device via the communication module based on the signals received from the handbrake detector and the gear shift detector.

16. The system as claimed in claim 15, wherein the sensors further comprise a temperature sensor; and wherein the microcontroller controls the engine starter device based on signals received from the communication module, the handbrake detector, the gear shift detector and the temperature sensor, and the microcontroller initiates a communication to the external communication device via the communication module based on the signals received from the handbrake detector, the gear shift detector and the temperature sensor.

17. The system as claimed in claim 1 , wherein the devices comprise an offensive measure device; the sensors comprise a panic button; and wherein the microcontroller controls the offensive measure device based on signals received from the panic button or the communication module and the microcontroller initiates a communication to the external communication device via the communication module based on the signals received from the panic button.

18. The system as claimed in claim 1, wherein the devices comprise an engine immobilizer unit coupled to the engine of the vehicle; the sensors comprise a vibration sensor; and wherein the microcontroller controls the engine immobilizer unit based on signals received from the vibration sensor and the microcontroller initiates a communication to the external communication device via the communication module based on the signals received from the vibration sensor.

19. A method of on-board controlling one or more devices installed in a vehicle, the method comprising, controlling the one or more devices based on signals received from a wireless communication module, sensors installed in the vehicle, or both utilising a microcontroller; and initiating a communication to an external communication device via the communication module based on signals received from the sensors utilising a microcontroller.