Keywords

1 Introduction

Despite many efforts taken by different governmental and non-governmental organizations all around the world to make people aware against careless driving, vehicle accidents still take place every now and then. Many accidents are fatal enough to claim human life or handicap them for the rest of their lives. Many precious lives could have been saved if medical assistance could be provided to the victim well in time. Research suggests that the first one hour after an accident accounts for nearly 75 % of all accidental deaths. It is also the period during which maximum number of lives could be saved if medical help was provided within time [1]. This requires information about the fatality to reach the family and friends of the victim as soon as possible.

Research work has been going on in this direction by academicians, scientists, researchers as well as automotive industry. However, very few stand-alone mobile applications are available which can handle post-accident scenarios. All existing technologies and major research works are vehicle bound; that is, they work only if a person meets an accident while in that particular vehicle. Our proposed application is not vehicle bound. It is installed on a smartphone which remains with a person even if she moves to another vehicle which is not equipped with accident detection system. Existing technologies/applications extensively utilize the video camera and the display screen, thereby draining the battery. Our proposed mechanism does not utilize the camera/screen extensively. It is therefore battery friendly. Existing technologies are display based. The user has to keep an eye on the display screen to see the warnings and alerts. Moreover, the driver may be distracted because of this divided attention [2, 3]. Our proposed application does not have any such requirement. Moreover, the mobile phone may remain in the user’s pocket and hence does not result in divided attention.

2 Existing Work in the Area

One approach of achieving reliable results of accident identification, location, and physiological parameters monitoring is by integrating the accident identification module with the standard air bag electronic control unit (ECU). ECUs are already configured with collision detection algorithm which works with the air bag system. The air bag system is designed to release in the event of any collision. So the present work is fastened with this existing system to provide enhanced result [4]. Accident detection can be further enhanced by utilizing an acoustic pattern analysis on general traffic noise, engine noise, and on interfering elements in accident sound detection system [5]. White et al. [6] in their paper describe how smartphones, such as the iPhone and Google Android platforms, can automatically detect traffic accidents using accelerometers and acoustic data. They immediately notify a central emergency dispatch server after an accident and provide situational awareness through photographs, GPS coordinates, VOIP communication channels, and recording of accident data [6].

3 Problem Statements

Existing research and applications available on Google Play and iOS App Store have several shortcomings. Some of them are mentioned below which this paper intends to address:

Problem #1::

Existing applications (e.g., iOnRoad Augmented Driving Pro) assist in only avoiding an accident while driving. It alerts the user about situations which may be unsafe, such as imminent vehicle collision, departure from the lane and over-speeding.

Problem #2::

Most of the existing technologies and major research works are vehicle bound; that is, they work only if a person meets an accident while in that particular vehicle only.

Problem #3::

Existing technologies/applications (e.g., Drivea) extensively utilize the video camera and the display screen, thereby draining the battery.

Problem #4::

Existing applications (e.g., iOnRoad Augmented Driving Pro) are display based. The user has to keep an eye on the display screen to see the warnings and alerts. Moreover, the driver may be distracted because of this divided attention.

Problem #5::

Most existing applications (e.g., WreckWatch [6]) use only the mobile Internet connection of the phone to transmit accident information to the central server. It is therefore primarily client–server architecture. The problem with this architecture is that the phone’s Internet connection may not be switched on during the accident. In such an event, the entire objective will collapse.

This research proposes to address all the above problem areas.

4 Algorithmic Approach of the Application

Below is the flow graph, representing the flow of control, for the proposed accident detection mobile application and their respective triggers [7] (Fig. 1).

Fig. 1
figure 1

Flow of control and associated triggers for accident detection

Full size image

The steps involved in devising the algorithm for detecting a vehicular accident are as follows.

4.1 Activation

This step involves developing an algorithm to activate the application whenever the user is traveling, boards a vehicle or when he manually chooses to do so. Auto-detection can be done in one of the following ways or combination of them: first, when the phone connects to the inbuilt Bluetooth system of the vehicle; second, when the accelerometer senses continuous motion for more than a certain threshold of time; and third, manual activation using the application interface.

The activation has to be done because the application does not remain pre-activated all the time so as to consume less battery power.

4.2 Accident Detection

This step involves developing an efficient algorithm to detect an accident. The algorithm would consider a weighted average of several factors such as acoustic data, accelerometer data and measure it against a threshold. Every factor is carefully assigned certain weight depending upon how much it can be relied upon. For example, a scenario where the impact force is sufficient enough to infer a collision will still detect an accident even if the acoustic data are weak in suggesting so.

In most cases of accident scenarios, the driver and fellow passengers raise an alarm and start yelling just before an eminent collision. Brakes are applied almost immediately, and then, the actual impact takes place. These sequences of events create a pattern of acoustic data and accelerometer data which is used by the AD algorithm. Moreover, weightage is associated with each event so that a weighted average of the data can be calculated.

Experiments suggest that mobile phones often do not capture sound levels beyond certain decibels (typically 150 dB) because of clipping [6]. This means that we cannot heavily rely upon acoustic data to detect an accident. Acoustic data, therefore, should be assigned less weightage. However, this limitation can be overcame if the algorithm detects what is being said rather than the decibels it generates.

Experiments suggest that events such as dropping phone from ear height or sudden braking after reaching high speeds do not result in generating a force above 4G [8]. This observation provides us a threshold beyond which the probability of detecting an accident would increase. Thus, it is highly probable that any force exceeding 4G coupled with high-decibel impact sound exceeding 140 dB almost at the same time frame is an accident scenario.

4.3 Voice Feedback Activation

Upon detecting an accident scenario, voice feedback mechanism will automatically be activated to recognize and accept voice commands. This is also necessary to reject any false alarm which the user can explicitly reject using voice commands before information about the accident is broadcasted. The victim, if at all in a position to issue voice commands, can make use of it to accomplish simple tasks such as calling someone or choosing to broadcast the accident information. However, the victim may not be able to speak, as a result of being injured or being in shock. In such a situation, assuming that the impact is fatal, after waiting for a finite amount of time, vital information about the crash such as GPS coordinates, severity of impact will be broadcasted. The broadcasting will be done to pre-configured list of recipients, including social networks. If the user’s phone is not connected to the Internet only an SMS will be sent to the pre-configured list of recipients.

4.4 Self-adapting Algorithm

This step would involve developing an efficient way in which false alarms can be minimized. A false alarm is when the algorithm detects an accident when actually it is not. Self-learning algorithms can greatly aid to reduce false positives. This is done by analyzing if the user has rejected any instance of accident alarm issued by the algorithm. In this case, the dynamic threshold (i.e., the limit of acceleration and acoustic level beyond which an occurrence of accident is confirmed by the algorithm) is increased slightly. Self-adaptation is important because it makes the algorithm more robust, customizable, and dynamic. It means that the threshold adapts to the user’s notion of what should or should not be considered an accident worth broadcasting.

4.5 Broadcast SOS Signals and Messages

When an accident scenario is confirmed or when user manually chooses to do so, distress messages, GPS coordinates, impact severity, etc., can be broadcasted to pre-defined contacts and also on social media via an SMS or a Web link.

The Fig. 2 demonstrates the steps and components involved in devising an application for accident detection using the inputs from the sensors of a smartphone.

Fig. 2
figure 2

Steps involved in accident detection application and associated research

Full size image

5 Application Areas

Apart from the primary function of accident detection, such a mobile application can be useful in various other scenarios such as accident detection while not in a vehicle but traveling (e.g., walking, running), vehicle over-speeding or risky driving alarm, sending SOS messages (manual activation), driving assistance and navigator, women safety or distress alarm, vehicle/mobile tracking or anti-theft systems, child safety, and remote access (for surveillance and safety features).

Such an application is all the more useful because smartphones are very commonly used and are relatively low cost. Also, fixing bugs and providing functional improvements in the application is very easy because of their built-in application upgrade mechanisms, such as the Google Play store.

6 Conclusion

The paper proposes a sequence of steps and few functional specification of the mobile application for accident detection. The application is designed to run on mobile so as to be easily deployable and broadly accessible. However, a lot of work remains to be done in developing the individual modules involved in the application design. For example, auto-activation of the application itself requires a lot of careful sequence of steps and associated research. Converting the proposed accident detection methodology into code representation and porting in on a suitable operating system or mobile hardware is also a challenging assignment and area of further research.

Also, empirical observations have to be made regarding how much acceleration and decibel is produced and experienced while inside a car during different accident scenarios.