wreckwatch.dvi

Journal of Mobile Networks and Applications manuscript No.

(will be inserted by the editor)

WreckWatch: Automatic Traﬃc A ccident Detection and

Notiﬁcation with Smartphones

Jules White, Chris Thompson, Hamilton

Turner, Brian Dougherty, and Douglas C.

Schmidt

Received: date / Accepted: date

Abstract Traﬃc accidents are one of the leading causes of fatalities in the US.

An important indicator of survival rates after an accident is the time between

the acci dent a nd when emergency medical personnel are dispatched to the scene.

Eliminating the time between when an accident occurs and when ﬁr s t responders

are dispatched to the scene decr eases mortality rates by 6%. One approach to

eliminating the delay between accident occ urrence a nd ﬁrst responder dis patch

is to use in-vehicle autom atic accident detection and notiﬁcati on systems, which

sense when traﬃc accidents occur and immediately notify emergency personnel.

These in-vehicle sys tems, however, are not available in all cars and are expensive

to retroﬁt f or o lder vehicles.

This paper describes how smartphones, such as the iPhone and Google An -

droid platforms, can automatically detect traﬃc accidents using accelerom eters

and accoustic data, immediately notify a central emerg ency dispatch server after

an accident, and provide situational awareness through photographs, GPS coor-

dinates, VOIP co mmunication channels, and accident data recording. This paper

provides the following contributions to the study of detecti ng traﬃc accidents

via smar tphones: (1) we present a formal model for accident detection that com-

bines sensors and context data, (2) we show how smartp hone sensors, network

connections, and web services can be used to provide si tuational awarenss to ﬁrst

responders, and (3) we provide empirical results demonstrating the eﬃcacy o f dif-

ferent approaches employed by smartphone accident detection systems to prevent

false positives.

J. White and H. Turner

Dept. of Electrical and Computer Engineering

Virginia Tech

E-mail: {julesw,hturner0}@vt.edu

C. Thompson, B. Dougherty, and D.C. Schmidt

Dept. of Electrical Engineering and Computer Science

Vanderbilt University

E-mail: {cthompson,briand,schmidt}@dre.vanderbilt.edu

2 J. White et al.

1 Introduction

Emerging trends and challenges. Car accidents are one of the leading causes

of death [2] in the US, causing over 100 fatalities daily. In 2007 alone more than

43,1 00 deaths resulted from 10.6 million traﬃc accidents. For every 100 licensed

teenagers between the ages of 16 and 19, there will be 21 tra ﬃc accidents, making

car accidents the leading cause of death for that age group in the U.S. [25].

A number o f technological and sociological improvements have helped reduce

traﬃc fatalities during the past decade, e.g., each 1% increase in seatbelt usag e is

estima ted to save 136 lives [9]. Advanced life saving mea s ures, such as electronic

stability control, also show s igniﬁcant prom ise for reducing injuries, e.g., crash

analysis studies have shown that approximately 34% of fatal traﬃc accidents coul d

have been prevented with the use of electroni c stability control [21]. Moreover, each

minute that an injured crash vi c tim does not receive emergency medical care can

make a large diﬀerence in their survival rate, e.g., analysis shows that reducing

accident response time by one minute correlates to a six per c ent diﬀerence in the

number of lives saved [12].

An eﬀective appro ach for reducing traﬃc fatalities, therefore, is to reduce the

time between when an accident occurs and when ﬁrst responders, such as medical

personnel, are dispatched to t h e scene of the accident. Automatic collision noti ﬁ -

cation systems use sensors embedded in a car to determine when an accident has

occurred [26,7]. These systems immediately dispatch em ergency medical personnel

to serious acci dents. Eliminating the ti me b etween accident occurrence and ﬁrst

responder dispatch reduces fatalities by 6% [26].

Conventional vehicular sensor systems for accident detect ion, such as BMW’s

Automatic Crash Notiﬁcation S ystem or GM’s OnStar, notify emergency respon-

ders i mmediately by utilizing built-in cellular radios and detect car accidents with

in-vehicle sensors, such as accelerometers and airbag deployment monitors. Fig-

ure 1 shows how traditional accid ent detecti on systems operate. Sensors attached

Fig. 1: A Vehicle-based Accident Detection and No tiﬁcation System

Smartphone Traﬃc Accident Detection 3

to the vehicle use a built-in cellular radio to communicate with a m onitoring cen-

ter that is responsible for dispatching emergency responders in t h e event of an

emergency.

Unfortunately, most ca rs in the US do not have autom atic accident detection

and notiﬁcation systems. Onl y in 2007 did automa tic notiﬁcation systems become

standard options in GM vehicles and most other non-lu xury manufacturers do not

include these systems as a standard option. Based on 2007 traﬃc accident data,

autom atic traﬃc acc ident detection and notiﬁcation systems c ould have saved

2,46 0 lives ( i.e., 6% of 41,000 fatalities) had they been in universal use. A key

impediment to using these systems is that they are infeasible or prohibitively ex-

pens ive to install in existing vehicles and add to the initial cost of new vehicles.

Moreover, these systems ca n be rendered obsolete, as evidenced by GM r emoving

500, 000 subscribers from the OnS tar ser vice because they were equipped w ith ana-

log (rather tha n digital) communicatio ns systems, and were theref ore incompatible

with their newer communication infrastructure.

Solution approach ⇒ Traﬃc accident detection and notiﬁcation with

smartphones. To address the lack of accident detection and notiﬁcation systems

in many vehicles, smartphones can be used to d etect and report traﬃc accidents

when acci d ent detection and notiﬁcation systems are unavailable. Smartphones,

such as the iPho n e and Google Android, have beco me common and their usage

is rapidly increasing. In the 2nd q uarter of 2010 alone, 325.6 million smartpho nes

were so ld [27]. This larg e and growing base of smartphone users presents a sig-

niﬁcant oppor tunity to extend the reach of automatic accident reporting sy s tems.

Moreover, smart p hones are widel y used by the teenage demographi c, which is his-

torically the most accident prone driver age group. The number of teenagers using

mobil e phon es has been increasing steadily, fro m 45% of teens in 2004 to 63% in

2006 and then 71% in 2008 [20].

The low cost of smartphones compared to other traﬃc analysis and acci dent

prediction systems makes them an appealing a lternat ive to in-vehicle accident

detectio n and reporting systems [23]. Moreover, smartphones travel with their

owners, pr oviding accident detection regardless of whether or not the vehicle is

equipped with an accident detection and notiﬁcation system. Furthermore, because

each smartphone is associated with its owner, automatic notiﬁcation systems built

on smartphones can aid in the identiﬁcation of victims and deter mining what

electronic medical records to o b tain before victims a rrive at the hospital.

The a b ility to detect traﬃc accidents using smartphones has only recently

become possible because of the advances in the processing power and sensors

deployed on smartphones. For ex ample, the iPhone 4 includes a GPS system for

determining the geographic position of the phone, an accelerometer for measuring

the forces applied to the phone, two separate microphones, and a 3-axis gyroscope

for detecting phone orientatio n. Moreover, smartphones now pos ses s signiﬁcant

sensor data processing power tha t can support the real-time execution of senso r

data noise ﬁltering and analysis algorithms. For example, the HTC Nexus One

Android smart ph one has a 1Ghz processor and 512MB of RAM.

Another key smartphone attribute for accident notiﬁcation is that they pro-

vide a variety of network interfaces for relaying inform ation back to centralized

emergency response centers, such as 911 call centers. The iPhone 4 contains a cel-

lular interface for sending and receiving data over GSM networks. Wiﬁ can also be

used by the iPhone 4 to send data to a nearby wireless access point. Smartphon es

4 J. White et al.

Car

1. Accident

Detection with

Phone

Sensors

2. 3G Data

Connection

Transmits

Accident Info

3. Server

processes

accident info

and contacts

ﬁrst

responders

Fig. 2: Smartphone-Based Accident Detection System

also i n clude Bluetooth wireless interfaces that can communicate directly with the

onboard computers in many newer cars.

Smartphone-based accident detection a p plications have both advantages and

disadvantages relati ve to conventional in -vehicle accident detection syst ems, e.g.,

they are vehicle-independent, increasingly pervasive, and provide rich data for

accident analysis, including pictures and videos. Building a smartphone-based ac-

cident detection system is hard, however, because phones can be dropped (and

generate fa lse positives) and the phone is not directly connected to the vehicle.

In contrast, conventional in-vehicle accident detection systems rarely incur false

positives because they rely on sensors, such as accel erometers and airbag sensors,

that directly detect damage to the vehicle.

This paper shows how the sensors and processing capabilities of smartphones

can be used to overcome the challenges of detecting t raﬃc accidents without di rect

interaction with a vehicle’s onboard sensors. We describe an approach for using

smartphones to measure the forces experienced by a vehicle and its occupants

to provide a portable “black box” data recorder, accident detection system, and

autom atic emergency notiﬁcation mechanism. The approa ch detailed in this paper

uses the sensors on a smartphone to record the G -forces (acceleration) experienced

by the vehicle and occupant, the GPS locati on and speed of the vehicle, and

the acoustic signat ures, such as air bag deployments or impact noise, during an

accident. Figure 2 shows how sensors built into modern smartphones can detect

a major acceleration event indicative of an accident and t h en utilize the built-in

3G data connection to transmit that information to a central server to alert ﬁrst

responders. That server then processes the information and notiﬁes the a u thorities

as well as any emergency contacts.

Smartphone Traﬃc Accident Detection 5

This paper signiﬁcantly extends our prior work [8] on traﬃc accident detec-

tion and notiﬁcation using smartphones [8] in three ways. First, we present a

forma l model and algor ithm for detecting accidents using smartph ones. Second,

we describe how aco us tic data can be analyzed to lower false positives. Third, we

include the results of experiments that quantify how acoustic data can help detect

accidents and reduce false positives.

Paper organization. The remainder of this paper is orga n ized as follows: Sec-

tion 2 describes the challenges associated with using sma rtphones to detect t raﬃc

accidents; Section 3 describes techniques we developed to overcome these chal-

lenges; Section 4 em p irical ly evalua tes how to prevent fals e positives and accident

reconstruction capabilities; Section 5 compares our work on smart ph one-based ac-

cident detection systems with related work; and Section 6 presents concluding

remarks.

2 Challenges Associated w ith Automatically Detecting Car Accidents

This s ection explores the challenges a ss ociated with detect ing car accidents using

a smartphone’s sensor data. A task of critical importanc e in accident detection is

ensuring that false positives are not reported to emergency services, such as 911.

According to the US Department of Justice, 25 to 70 percent of calls to 911 i n some

areas were “phantom c alls” where the caller imm ediately hangs up [29]. California

receives approximately 6 million 911 calls from cell phones and between 1.6 and

3.6 million of these calls are phantoms [29]. Clearly, smartphone traﬃc accident

algo rithms must be careful not to increase the volume of phantom emergencies.

It is hard to strike a balance between no accident false positi ves and fully

reporting all traﬃc accidents that occur. Vehicu lar accident detection systems,

such as OnStar, have a signiﬁcant advantage since they are i ntegrated with the

vehicle and its onboard air bag depl oyment and crash sensors. Sensor data received

by these sy stems directly correlates to the forces experienced by the vehicle.

In contrast, smartp h one accident detection syst ems must indirectly predict

when an accident has occurred based on sensor inputs to the phone. Since pho nes

are mobile objects, they may experience fo rces and sounds (indicative of a traﬃc

accident) that originate from other sources, such as a user dropping the hand-

set. Accident detection algo rithms f or sm artphones must use sensor data ﬁltering

schemes tha t are resistant to noise, yet provide high enough ﬁdelity to not ﬁlter

out valid a c cidents.

2.1 Chall enge 1: Detecti ng Accident Forces Without Electronic Control Unit In-

teraction

Conventional in-vehicle accident detecti on systems rely on sensor networks through-

out th e car and direct interaction with the vehicle’s electronic control units (ECUs).

These sensors detect acceleration/deceleration, airbag deployment, and vehicular

rollover [3, 32]. Metrics f rom these sensors aid in gener ating a detailed accident

proﬁle, such as locating where the vehicle was struck, number of times it was hit,

severity of the collision, and airbag d eployment.

6 J. White et al.

Smartphone-based accident detectio n app lications must provide similar infor-

mation. Without direct access to ECUs, however, it is harder to collect informa-

tion about the vehicle. Alt hough many cars have accident/event data r ecorders

(ADRs/EDRs), it is unrealistic and undesi rable to expect dr ivers to connect their

smartphones to these ADRs/EDR s every time they get into the car. Not only would

connecting to A D Rs/-EDRs require require a standardized interface (physical and

software) to ensure compatibility, but it would require exposing a safety-criti c al

system to a variety of smartphone types and middleware platform s .

These conditions make it infeasible to verify and va lidate that each rapidly de-

veloped sm artphone version integrate properly with every ADR/-EDR. Moreover,

while many new cars have some form of ADR/EDR, any smartphone application

that req u ired interaction with an onboard computer would be useless in cars that

lacked one. What is needed, t h erefore, is to collect the same or similar information

utili z ing only the sensors present on the smartphone alone. Section ?? explains how

we address th is challenge by using the sensors in the Android platf orm to detect

accelerations/decelerations experienced by car occupants and Section 4 analyzes

device sensor data captured by smartphones and shows that low false positive

accident detection is possible.

2.2 Chall enge 2: Providing Situational Awareness and Communication with Vic-

tims to First Responders

Situational awareness involves being informed of the environment of a speciﬁc

area at an instant in time, comprehending the state of that environment, and be-

ing able to predict future outcomes in that space [11,6]. There are three levels

of situational awareness: (1) perceiving emergency indicators in the environment,

such as a driver seeing the collisi on of two vehicles in front of them, (2) compre-

hending the implications of those indicators, such as the driver realizing that they

need to slow down, and (3) possessing an abil ity to predict what will transpire

in the future, such as the driver determining that one o f the cars involved in the

accident will end up in the left lane [16].

After an accident, accident detection systems can provide critical situational

awareness to ﬁrst responders regarding the condition of the vehicle and occupants.

This da ta can then be used by ﬁrst responders to comprehend the physical state

of the passengers and possibly predict how long they can survive without medical

attention. For example, OnStar automatically places a voice call from t h e vehi-

cle to an emergency dispatch service so that ﬁrst responders can inquire about

the condition of the vehicle’s occupants, provide gu idance, and predict w hether

or not an ambulance should be dispatched. These accident detection systems can

also determine and report back to ﬁrst responders information on air bag deploy-

ment, which indicates a serious accident. Moreover, accident detection systems,

such a s OnStar, can pinpoint the GPS coordinat es of a n accident and relay this

inform ation to ﬁrst responders.

Eﬀective smartphone accident detection systems must be able to replicate the

complex s ituational awareness capabilities that are used by ﬁrs t respo n ders. They

must also provide indicators of the environment in a form that can be consumed by

ﬁrst respon ders. For example, the raw acceleration values of the phone are unlikely

to h elp ﬁrst responders und erstand what happened in an accident. Moreover, the

Smartphone Traﬃc Accident Detection 7

system must provide suﬃciently rich information to ﬁrst responders to predict the

future state of the driver and passengers, which is hard when the phone cannot

directly measure their health or the car’s condition. Sect ion 3.5 describes how we

use a combinatio n of VOIP telephony, text messaging, mapping, and bystander

reporting to provide si tuational awareness to ﬁrst resp onders.

2.3 Chall enge 3: Pr eventing False Positives

Vehicle-based accident detection sys tems monitor a network of sensors attached to

the car to determine if an accident has occurred. One key indicator of a collision

is an instance of high acceleration/ decelerati on due to a large change in velocity

of t h e vehicle over a short period of ti me. These acceleration events are hard to

atta in if a vehicle is not actively being driven since it is unlikely that an unattended

car will simply roll away from a parked location. Since smartphones are portabl e,

however, it is possible that the phone may experience accelerat ion events that were

not al s o experienced by th e user. For instance, a phon e may accidently drop from

6 feet i n th e air.

Since a smartphone-based accident detection application contacts em ergency

responders—and may dispatch police/rescue teams—it is essential to identify and

suppress false positives. Due to smartphone mobility it is hard to diﬀerentiate

programmatically between an actual car accident versus a dropped purse or a fall

on a hard surface. The inability to identify and ignore false positives accurately,

however, can render smartphone-based ac cident detection applicat ions useless by

wasting emergency responder resources on incident reports that were not real ac-

cidents. Section ?? explains how we address this challenge by using device usage

context (such as sp eed) to ﬁlter out potential false positi ves and Section 4.1 pro-

vides empirical results evaluating our ability t o suppress false positives.

3 Solution Approach

This section describes a prototype smartphone-based client/server application we

developed—called “WreckWatch”—to a dd ress the challeng es presenting in Sec-

tion 2. WreckWatch provides functionality simil ar to an accident/event data recorder

by recording the path, speed, and forces of acceleration on a vehicle leading up to

and d uring a n accid ent [5]. It can also no tify emergency responders of accidents,

aggregate images and video uploaded by bystanders at the scene of an accident,

and send prerecorded text and/or audio messages to emergenc y contacts.

3.1 The WreckWatch Client/Server Architecture

WreckWatch is separated into two main components—the WreckWatch s erver and

the WreckWatch client—shown in Figure 3. The WreckWatch client was developed

using Google Android. It acts as a mobile sensor, relays accident information to

the server via sta nd ard HTTP post operations, and provides an interface that

allows third-party observers to contribute accident report data.

8 J. White et al.

HTTP

JSON

Accident Detection

Accident Maps

Situational Awareness Data

Emergency Contact Registration

Clients

Data Aggregation

Emergency Dispatch

VOIP Communication/Provisioning

Map Updates

Situational Awareness Data Storage

Server

Fig. 3: WreckWatch Architecture Diagram

The WreckWatch Android client is written in Java based on Android 1.5 with

Google APIs. It consists of several Andr oid application Activities

for mapping,

testing, and image upload. Background services detect accidents by polling sm art-

phone system sensors, such as the GPS receiver and accelerometers. T h e po lling

rate is conﬁgurable at co mpile-time to meet user needs and to provide the appro-

priate p ower consumption characteristics. The WreckWatch c lient can gather data

from phone datab ases (such as an address book ) to designate emergency contacts.

Communication to the server from the Android client uses standard HT TP post

operati ons.

The WreckWatch server was developed using Java/MySQL with Jetty and the

Spring Framework. It provides data aggregation and a communication conduit to

emergency responders, family, and friends. It also allows clients to submit acci-

dent characteristics (such as accel eratio n, route, and speed) and presents several

interfaces, such as a Googl e Map and XML/JSON web services, for a c cess ing this

inform ation.

As accident infor mation becomes available, the WreckWatch server posts loca-

tion, route and severity information to a Google Map to aid emergency r esponders,

as well as other drivers attempt ing to navigate the roads near the accident. This

map i s avail able over HTTP through a standard web b rowser and is built with

AJAX and HTML, a s sh own in Fig u re 4. The remainder of this section presents

the formal accident detection model used by WreckWatch and its approach to re-

ducing false posit ives and then discusses features of the WreckWatch client/server

application that supports ﬁrst responder situational awareness.

Activities are basic building block components f or Android applications and can be thought

of as a “screen” or “view” that provide a single, focused thing a user can do.

Smartphone Traﬃc Accident Detection 9

Fig. 4: WreckWatch Acci dent Map

3.2 The WreckWatch Formal Accident Detection Model

A carefully crafted formal model of accident detection is important to detect traf-

ﬁc acc idents accurately. Challeng e 1 from Section 2.1 descr ibed the problems as-

sociated with detecting traﬃc accidents wit h out direct measurement of impact

data from onboard sensors. Ch allenge 2 from Section 2.3 examined th e potential

for false positives, which is a key concern with applications that automatically

dispatch police or rescue. To address both challeng es, WreckWatch uses a soft

real-time multi-sensor sampling approach, with threshold-based ﬁltering to pre-

dict when an accident occurs. The forma l accident prediction framework is based

on the following 11-tuple model of the phone state, which is used to extrapolate

the state o f the vehicle:

γ =< φ, T

, ρ, T

, β, ǫ, S

, S

, M

> (1)

where:

– S

is the span of time after an acceleration event sets a value for the va riable

φ befor e the variable is reset.

– φ is an a c celerati on variable that indicates the maximum accel eratio n experi-

enced in any direction by the phone. The ma ximum acceleration value is reset

after S

milliseconds have elapsed.

– S

is the span of time after a sound event with a sound pressure level greater

than M

dBs that the sound event variabl e, ρ, will remain set to 1.

– ρ is a binary sound event variable that indicates if a sound event greater than

dBs has occurred. The variable has value 1 if a sound event of M

dBs o r

more was experienced by the phone and 0 otherwise. From experimentation

and a l iterat u re review on air bag deployment [30], we have found t h at 140dBs

is a good value for M

10 J. White et al.

– S

is the span of time after the pho n e is no lon ger traveling at least M

mph

that t h e speed threshold variable, β, wil l remain set to 1.

– β is a speed threshold variable with value 1 if th e phone has been traveling at

greater than M

mph.

– ǫ is the distance traveled since the last time the variable β switched from value

1 to 0.

– M

is the minimum acceleration in Gs required for an acceleration event alone

to trigger accident detection.

– M

is the minimum decibels required for an acoustic event to trigger the sound

event variable.

– M

is the minimum speed in miles per hour that the device must be traveling

in order to activate the accident detection system when it is inactive.

– M

is the max distance in feet that the device is permitted t o move at a speed

lower than the speed threshold, M

, before the acci dent detection system is

deactivated.

The WreckWatch accident detection algorithm operates on the 11-tuple γ. The

accident detection function

Ev : γ → {0, 1} (2)

evaluates to 1 if an accident is detected and 0 otherwise. A n accident detection

can be triggered by one of two situations: (1) a high acceleration event and a high

decibel sound event are r ecorded while the vehicle is moving above the threshold

sp eed, M

or (2) the distance moved sin ce the last time the speed threshold M

was exceeded is less than M

feet and an acceleration and sound event occur. More

forma lly, we deﬁne these two accident det ection conditions as:

Ev(γ) =











1 if (

+ αρ ≥ M

T r

)

(β == 1) (a)

1 if (ǫ < M

)

(

+ αρ ≥ M

T r

) (b)

0 otherwise

(3)

where:

– α is a adjustab le weighting fa ctor applied to the sound event that denotes its

import ance in the accident detection model . Higher values for α al low collisi ons

at low speed or where the s afety systems sign iﬁcantly dampen the impact,

which can be detected through a combination of sound and acceleration.

– M

T r

is t he threshold for accident detection.

The ﬁrs t accident detection scenario is triggered when the smartphone is trav-

eling above a thresh old speed associated with being i ns ide a car. In this situation,

an accident is detected if the smartphone experiences a violent acceleration event,

indicating a probable collision, fo llowed by a high-decibel acoustic event, such

as air bag deployment, a horn, or an impact noise. It is also possible to detect

an accident solely from an acceleration event, without a sound event, where the

acceleration value alone is so large that it exceeds the accident detection threshold

≥ M

T r

Smartphone Traﬃc Accident Detection 11

The second scenario for accident detection oc cu rs when the smartphone is

traveling in s ide of a vehicle that stops at an intersection, traﬃc lig ht, or other

location. In this scena rio, the algorithm attempts to detect if the user has exited

the car o r is merely waiti n g for a light or traﬃc condition to change. The accident

detectio n alg orithm uses the M

distance threshold to keep the detection proc ess

active b elow the thr eshold speed. As long as the smartphone does not travel more

than M

feet from the last location the speed threshold was exceeded, the detection

algo rithm assumes that the user is still inside the car . This extra condition allows

the algorithm to detect accidents that occur when the user’s car is s truck by

another vehicle while stopped.

Car

Accelerometers

record forces

experienced in

collision

Car

Fig. 5: Device Sensors Provide Acceleration Informat ion

3.3 Using Acceleration Events to Detect Collisions

The accident detection model, γ relies on sam pling the a c celerometer to detect

colli s ions, as shown in Figure 5. Given a stream of values from the accelerometer,

denoted As, where each value As

is recorded at t ime T

, As

now

is the most

current value, and T

now

is t he curr ent in stant in time:

φ =

(

now

if As

now

≥ φ

if (T

now

− T

≤ S

)

(∀As

∈ As, As

≥ As

)

(4)

The value for φ is set to the greatest acceleration event exp erienced in any direction

over the time span S

. If the current accelerat ion value is greater than φ, then φ

is up dated to th e most recent ac celeration value.

12 J. White et al.

3.4 Using Acoustic Events to Detect Accidents

Our prio r work [8] on accident detection was based solely on acceleration. It was

thus p otentially susceptible to false positives at low sp eeds and thus required higher

settings for M

(higher values fo r M

, reduce the probability that low speed colli-

sions w ill be reported). In our accident detection model described in Sect ion 3.2,

we added acoustic data analysis to improve lower speed collision detection and

reduce the probabi lity of a false pos itive by listening for high decibel acousti c

events, such as im p act n oise, car horns, and air bag deployment. For example, air

bag deployment is accompanied by high-amplitude, short-duration n oise that can

exceed 170dB at peak a mplitude [30].

The WreckWatch formal model for accident detection uses built-in microphones

on a smartphone t o detect high-decibel acoustic events indicative of an accident.

Using a secondary sensor in conjunction with acceleration attempts to lower the

probability of false positives. As di sc us s ed in Section 4.2, clipping of the audio

above 150 decibels and other potential noises (such as shouting) make it hard to

use sound alone to detect accidents. It is possibl e that thi s limitation could be

overcome, but we chose to make acoust ic events a seconda ry ﬁlter for accident

detectio n that aids in reducing false positives.

The accident detection model γ relies on sampling the micr ophone to detect

accident noise. Given a stream of soun d event decibel values denoted Ks, where

each value Ks

is recorded at T

, Ks

now

is the most current value, and T

now

the current instant i n time:

ρ =











1 if Ks

now

≥ M

1 if ∃Ks

∈ Ks, (Ks

≥ M

)

now

− T

≤ S

)

0 otherwise

(5)

During any time spa n of S

milliseconds, if a decibel value exceeds the M

thresh-

old, then ρ is set to 1. Once ρ is set to 1, it will remain set as long as sound events

of greater th an M

decibels are experienced every S

milliseconds.

Our future work will investigate dynamically adjusing the weight, α, applied

to the sound event during accident detection. For example, if the car radio is set

to a high volume level, ρ may remain continually set to 1. In this scenario, high

decibel sound is much less indicative of an accident and thus α should be set to a

low value.

3.5 Providing Situational Awareness to First Resp onders

Chall enge 3 from Section 2.3 described the im portance of replicating the situa-

tional awareness capabilities of in-vehicle accident detection and reporting systems.

WreckWatch uses a combination of imagery, voice communicatio ns , GPS localiza-

tion, and javascript object notation (JSON) web services to relay si tuational data

to ﬁ rst respo n d ers, as described below.

Citizen scientist imagery. In an emergency, WreckWat ch allows bystanders

and uninjured victims to serve as “citizen scientists” [10] and report critical situ-

atio n al data to ﬁrst responders. In particular, it allows bystanders and uninjured

Smartphone Traﬃc Accident Detection 13

Car

Bystanders take

photos of

accident

Car

Snap!

Photos are

aggregate on server

and streamed to

ﬁrst responders

ﬁrst responder

Fig. 6: Accident Image Upload

victims t o take pictures using their smartphones and share them with ﬁrst re-

sp onders, as shown in Figure 6. Figures 7a and 7b show the client interface for

uploading pictures of victim injuries or the accident scene to the WreckWatch

server.

Emergency responders can access the uploaded images via mobile devices en

route or a standard web browser at an emergency response center. The Wreck-

Watch client provides mapping f u nc tionality throu gh Google Maps on th e device

to ensure that emergency responders can continuously receive information about

an accident to prepare them for what ever they encounter at the accident site. This

map also allows other motorists to route themselves a round an accident, thereby

reducing congesti on.

VOIP communication channels. The WreckWatch server uses digital portable

branch exchange (PBX) functionality to make/receive phone cal ls and provision

phone li nes dynamically. It can t h erefore interact with emergency responders via

traditional circuit-switched networks and create accident information hotlines in

response to serious accidents via an Asterisk-based digital PBX running Linux. The

server can also be conﬁgured with emergency contacts to notify via text and/or

audio messages in the event o f an accident. This da ta is conﬁgured at some time

prior to a collision event so the server need not interact with the cl ient to notify

family or friends.

The PBX is built on Asterisk and connects to the server through a Java API.

The Android client and web client pull information from the server and can be

conﬁgured based on user needs. Due to the loose coupling and use of open stan-

dards between clients and server, additional clients fo r other platforms (such as

other sm artphones or desktop applications) can be implemented with out the need

14 J. White et al.

(a) Bystanders Can Upload Acci-

dent Images

(b) Client Application can View or

Upload Accident Images

Fig. 7: Traﬃc Accident Ima ging

to up d ate the server. The WreckWatch server architecture also supports a hetero-

geneous group of clients, while providing a pp ropriate qualities of service to each

device.

JSON emergency web services. The WreckWatch server is a web-based s er-

vice based entirely on freely-available APIs and open-source software. It is written

in Java and built using J etty atop the Spring Framework. It utilizes a MySQL

database to store accid ent information and image meta-information. The server

communicates with the clients via a RESTful architecture over H TTP using cus-

tom XML (for the Android application) and JSON (for the web-based a p plication).

All communicatio n between the clients and the server is initiated by clients.

The server’s operations (such as accident information upload) are performed by

individual handlers that can be conﬁgured at runtime and are speciﬁed by parame-

ters in an HTTP request. This architecture enables the addition of new operat ions

and functionali ty wit h out any software modiﬁcations or the need to recompile. All

conﬁguration is handled by an XML ﬁle parsed during server startup.

Geolocation and mapping of accidents. When an a c cident occurs, the Wreck-

Watch client immediately reports certain accident charact eristics to the server, in-

cluding the GPS location o f the wreck. Each accident is geo-tagg ed on the server

with it s location and entered into a searchable dat abase of accidents. The acci-

dent locations are made available to ﬁ rst responders and other motorists t hrough

a Google Maps interface.

To further enhance ﬁrst responders’ underst anding of the conditions leading

up to the accident the route driven by the vehicle in the 30 seconds leading up to

the crash is overlayed on top of the map. This route overlay allows ﬁrst responders

to determine the direction of travel and p ossible caus e of the collision. This infor-

Smartphone Traﬃc Accident Detection 15

mation allows the system to ser ve as a ”black box” and possibly help to indicate

areas where road i mprovement is needed.

3.6 Potential Advantages of Smartphone-b ased Accident Detection Systems

Our work with smartphone-based accident detection systems in the context of

WreckWatch, we i d entiﬁed the following advantages relative to in-vehicle accident

detectio n s ystems:

1. Smartphone sensors may measure forces closer to those experienced

by victims. In the event of an accident, if the sma rtphone is in a user’s pocket, the

smartphone will experience close to the same forces and accelerations experienced

by the occupants of the vehicle. Moreover, if the smartphone remains stationary

relative to the vehicle during the collision, it is possible to use the data gathered

from the smartphone to recreate an d model the forces it experienced. In this ca s e,

the smartphone can pr ovide data much like that gathered by vehicular EC Us.

Smartphones ar e often ca rried in a pocket [17] attached to a person. In t h ese

cases, the smartphone would exp erience the same forces as vehicle occupants,

and could thus provide more information than in-vehicle systems by recording

the forces experienced by occupants rather than just the vehicle itself. When this

directionality and movement is combined with speed and location information

from the GPS receiver, it is possible to help reconstruct the accident, including

any s econdary impacts .

2. The ubiquitousness of smartphones and thei r relatively low cost may

help improve accident detection and notiﬁcation system use. Many ex isting

accident detection and traﬃc monitoring systems require an in-and-out of vehicle

infrastructure to operate eﬀectively. While some p roposed accident detection sys-

tems utilize the existing cellular network, t h ey have traditionally focused solely on

voice capabilities and have not gained wide adoption. Smartphones allow use of the

existing voice and data infr astructur e, without the need for additional in-vehcile

hardware. Due to customers and manufacturers not having to pu rchase new ha rd-

ware, it is possible that the ado ption r ate of a smartphone-based accident detection

systems would be higher than non-smartphone a lternat ives.

3. Reduced software maintenance complexity via smartphone applica-

tion upgrade mechanisms. One inherent complexity in traﬃc monitoring and

accident detection systems is the need to upgrade those systems to ﬁx bugs a nd

improve f un ctionality over time. With thousands or millions of in-vehicle accident

detectio n systems, maintenance can rapidly become a very expensive op eratio n .

An unfortunate reality is tha t freq u ently maintenance o ften becomes unduly ex-

pens ive, resulti n g in the delay of ma ny mino r improvements until there is a major

improvement that justiﬁes the cost of bringing a vehicle into a service center for an

upgrade. It may also be impossibl e to upgrade some legacy s ystems and continue

servicing them, e.g., OnStar d ropped 500,000 of their s u bs cribers due to outdated

analog hardware.

Smartphones provide an eﬀective solution for remote software maintenance

through their built-in application store upgrade mechanisms, such as the iTunes

Store. Moreover, smartphones tend to have a much hig her refresh rate than cars,

due to their lower co sts and appeal as a status symbol. This trend towards constant

16 J. White et al.

turnover of h ardware oﬀers the potential to lower the averag e age of the hardware

in use for accident detection.

4. Smartphone situational awareness systems can be augmented through

cloud-based services. While onboard sensors are excellent f or rapid accident

detectio n, they are typically limited in terms of processi n g and notiﬁcation ca-

pabilities. Since Smartphones are conn ected to a data network they can access

cloud services to elastically extend their computational and/or storage capabil-

ities. Moreover, new data an alysis services can be plugged into servers without

requiring complex upgrades of clients.

3.7 Potential Disa dvantages o f Smar tphone-based Accident Detection Sys tems

While smartphones show signiﬁcant advantages in the ﬁelds of accident det ection

and traﬃc monitoring, there potential disadvantages that motivate future research

and reﬁnement, as disc us s ed below.

Accident detection systems consume a signiﬁcant amount of battery

power. GPS receivers consume a large amou nt of power and sampling them at

the rate necessary to determ ine speed accurat ely reduces the battery life of t he

device to several hours. To overcome t his limitat ion, users can plug smartphones

into cigarett e lights in vehicles to provide t h em with power. Requiring users to

plug-in smartphones helps establish the context needed to eliminate false positives

and also mitigates the power consumption of the GPS receiver.

Low speed traﬃc may trigger deactivation of WreckWatch. If a driver is

stuck in low-speed traﬃc, their vehicle may travel beneath the M

sp eed thresh-

old for signiﬁcant periods o f time. Although WreckWatch uses the smartpho ne’s

GPS to determine device and (consequently) vehicle speed it only begins record-

ing accelerometer information and looking for potential accidents above M

sp eed

threshold. In addition to reducing battery drain, this ﬁlter helps eliminate any ac-

celeration events due to signiﬁcant accidental smartphone drops that might occur

outside a vehicle.

In high traﬃc co n gestion situations, however, ﬁltering may shut oﬀ the accident

detectio n system if the car travels more than M

feet at low speed, even though

the user is sti ll in the vehicle. Future work will explore ﬁltering approaches that

better distinguish beteween low-speed vehicle movement and walking. We intend

to u se the rythmic movement o f walking t o make this distinctio n.

Safety systems reduce impact forces. In-vehicle accelerometers are physi-

cally mounted to the chassis of the car, so their motion directly mirrors the vehicle

and will experience most forc es the vehicle experiences. Smartphones, however, are

likely to be held in a pocket or holster. Car safety systems are designed to reduce

the force on the occupants of the car during an accident a nd because of this, the

forces experienced by the phone may be signiﬁcantly less than the forces exper i-

enced by the accelerometers in the car .

These safety systems accomplish this reduction in force by increasing the time

over which the change in velocity occurs. The net change in speed is the sa me,

but the acceleration is less because it occur s over a longer period of time. Direct

measurements report much higher a c celerati ons, e.g., the peak accelerations ex-

perienced inside a football helm et dur ing play are approxima tely 29.2 G’s [24].

For low-speed accidents there is the potential that the safety systems will reduce

Smartphone Traﬃc Accident Detection 17

the acceler ation on the phone below the M

G-force threshold needed for accident

detectio n. Although low-speed crashes are less lif e-threatening, they still create a

hazard to other motor ists and sho uld be reported. In future work, we are investi-

gati n g other approaches to improve low-speed accident detection.

Destruction of the smartphone may prevent accident notiﬁcation deliv-

ery. To maximize the probability that an accident is reported, it is critical to prior-

itize data transm ission. WreckWatch uses a two-stage process to r eport accidents.

First, the initial accident report is sent to the server using a small message that

can be delivered over UDP o r HTTP. Any additio n al informa tion, such as forces

of acceleratio n during the crash, is then transmitted immediately fol lowing the

transmission of critical data. WreckWatch uses this two-stage protocol to increase

the probability that t he accident and crash diagnostic data is reported success-

fully. This two-stage protocol does not completely guarantee that a smartphone

will be abl e to transmit crash data if it is destroyed. We are actively researching

future ap proaches to improving notiﬁcation success probabilities through the use

of ru ggedized external cradles for smartphones.

Smartphone OS development companies control the software capabilities

of the sensor. For the forseeable future, a smartphone-based accident detection

system would run as an application d eployed on top of a smartphone op erating

system (OS). This approach implies that the software must operate within the

architectural limitations of the platform. One example is the lack of multi-tasking

on initial versions of the iPhone and on the new Windows Phone 7. A smartph one

user would likely not be willing to run an accident detection app lication every time

they enter their vehicle. Not only is this an issue for the initial d evelopment of such

a system, but once the system is developed major changes in t h e OS application

programming interface (API) would have t he potential to crippl e the entire system .

This p roblem a lso follows from the current tr end of rapid updates to smartphone

OS APIs, i.e., if a developed acc ident detectio n syst em was not updated with

changes in the smartphone OS API it could become obsolete rapidly.

Production quality te sting is hard. A key concern of a smartphone accident

detectio n s ystem is the need to avoid fal s e positives. When this need is combined

with the large degrees of fr eedom (e.g., speed, noise conditions, location of device,

etc.) in an accident it is hard to validate a developed smartphone based accident

detectio n system emp irically. For this work to r each product ion quality reliabili ty,

methods to test the operational eﬀectiveness of accident detection systems must

be created.

4 Empirical Results

This section describes results o f tests performed on the WreckWatch application

described in Section 3. These results empir ically evaluate WreckWatch’s ability

to prevent false positives and gather in formation to reconstruct an accident accu-

rately.

18 J. White et al.

4.1 Experiment 1: Evaluating the Possibility of False Positive Acceleration Values

As described in Section 2.3, avoidi ng false positives is a key challenge when de-

tecting car acci dents with smartp hones. Although WreckWatch only activates the

accident detection system at speed, it is still possible that a driver or passenger

could drop their smartphone whi le the vehicle is in motion. The ﬁrst experiment

was design ed to d etermine if the acceleration component of WreckWatch’s acci-

dent detection system would be triggered by the phone falling inside the vehicle

or by emergency braking that did not result in a crash.

Hypothesis ⇒. Accidental fall s or non-emergency braking would pro-

duce insuﬃcie nt accel eration to trigger accident detection. We hypothesized

that the acceleration experienced by a smartphone when dropped would be sub-

stantially less than a car accident. We believed it would be hard to produc e 4Gs

of force without dropping the phone from a substa ntial height (such as fr om a

multi-story building) or from a moving vehicle (such as a car on the highway).

We considered both situations to occur rarely enough that they did not warrant

experimentation.

Experiment setup. Since WreckWatch’s speed ﬁltering only activates the ac-

cident detection system when the phone is in mot ion, our experiments were con-

ducted inside a vehicle. To analyze the potential for false positives from accel-

eration changes, we conducted two experiments desig n ed to simulate events that

generate accelerations whose values cou ld potential ly be interpreted as car acci-

dents.

All experiments were performed on a Google ION device running the vendor

imag e of Android 1.5 on a 525 Mhz processor with 288 MB of RAM. The de-

vice was factory reset before loading WreckWatch and no additional third-party

applications were installed. WreckWatch reco rded a c celeration on three axes at

the highest pos s ible rate and wrote these values to a CSV ﬁle on the SD card in

the device. This data was then downloaded to a Windows desktop computer for

analysis in Excel.

In all g raphs, positive z-axis values indicate po sitive accelerat ion in the di-

rection from the battery cover toward the screen. Likewise, positive y-axi s values

indicate positive accelerati on in the direction from the USB connector toward the

smartphone speaker. Fina lly, positive x-axis values indicate p ositive a cc eleration

from left to right when looking at the device with the USB connector closest the

observer.

Empirical results. For the ﬁrst test, the Android device was dropped from ear

height in the driver’s seat of a car. The device bounced oﬀ the seat and wedged

between the seat and center console. Figure 8a shows the acceleration on each axis

during the collision with the ﬂoor.

Using 9.8 m/s as an approximate value for Earth’s gravity, the device experi-

enced approximately 2G’s in each direct ion with nearly 3G’s on the x-axis befo re

coming to rest. The required acceleration to trigger airbag deployment is 60G’s [13,

1]. In addition t o being ∼30 times smaller than required to deploy an airbag, this

value is well below the 4G’s used as a ﬁlter. It is therefore unlikely a smartph one

could be dropped in a manner that would exceed 4G’s. This data supports the use

of a ﬁlter (presented in Section 3.2) to prevent false positives.

A sudden stop is Another pot ential scenario that could potentially generate a

false positive. This test was performed in a vehicle by reaching a speed of approx-

Smartphone Traﬃc Accident Detection 19

(a) Acceleration During a Fall (b) Acceleration During a Sudden Stop

Fig. 8: Acceleration During Falls and Sudden Stops

imately 25 mph and enga ging in a sudden stop. The test results are approximate

as the exact speed was unknown and braking pressure was not exa ct. Figure 8b

shows the acceleration experienced o n each axis during the stop. As described in

Section 3.6 , because the smartphone remained stationary relative to the vehicle,

it experienced the same forces as the vehicle. In this instance, the acceleration

experienced by the smartphone was actually less than that experienced during the

fall.

This result is attributed to the fact that although the stop was sudden and

forceful, the car (and consequently th e smartphone) came to a rest over a period

of time that was long er th an during the drop test. In other words, the change

in velocity was greater but the actual acceleration was less becau se the change

occurred over a longer period of ti me. Based on this data, it is unlikely for the

smartphone to experience 4G’s of a cc eleration si mply due to a sudden stop.

4.2 Experiment 2: Evaluating the Possibility of Accoustic False Positives

Smartphone microphones can potentially augment the acelerom eter of the phone

to det ect collisions. Drivers and passengers, however, often inadvertently create

an array of loud noises that could potentially be interpreted by the devic e as the

sound of an airbag deploying, leading to false incident reports. We therefore needed

to determine whether benign noises associa ted with normal cell phone use coul d

be mistaken for airbag deployment.

Hypothesis ⇒ Benign nois y acitivities, such as phone drops, shouting,

laughing, loud music and driving w ith windows down would produce i ns uf-

ﬁcient noise levels to trigger accident detection. We hypothesized that none

of these noises would reach the 160dB range of an air bag deployment. If this was

the case, it would be possible to tune the accident detection model to more heavily

rely on accoustic signatures.

Experiment setup. To determine if vehicular or other so un d s unrelated to

those indicati ng a collision could trigger accident detection, we r ecorded the sound

pressure in decibels (dB) of a number of potential road sounds that could generate

20 J. White et al.

(a) Highway Noi se (b) Dropped Phone

Fig. 9: Potential Noise Levels During Highway Transportation

false positives. The decibel measurements for each sound were recorded di rectly

by the phone rather than an external measurement device to directly measure the

accoustic inputs that would be received by the accid ent detecti on algorithm. The

road noises that we analyzed incl u d ed:

1. Highway noise

2. The p hone falli ng fr om ear height in a vehicle

3. Loud laughter

4. Shouting in an argument

5. Playing the radio at full volume and

6. Playing the radio at full volume with all windows down

Empirical results. The results of the experiment are shown in Figure 9, Figure

10 and Figure 11. The baseline readings were ta ken driving a 2006 four door Honda

Accord at speeds of 55 -70 mph on an interstate highway with the radio playing at

1/3 of maximum volum e. As shown in Figure 9 the ma ximum decibel level reached

for the baseline was 81 d b.

Noise during tr ansportation can dram atically increas e, however, due to several

incidents, such as phone dr ops, laughing, shouting, playing the radio loudly, and

rolling down the windows. An eﬀective solution must ensure that the device sound

processing capabilities can diﬀerentiate between these benign activities an d the

noises associated with severe collisions, such as ai rbag deployment. Additional

experiments were executed to simulate these events.

First, we recorded the decibel level associated with dropping the device multiple

times form ear height. The results can be seen in Figure 9. Phone drops resulted

in a maximum decibel level of 103 db, co ns iderably less than the 160-180 db

generated by a n airbage deploying. We then measured the noise levels associated

with two people laughing loudly and two people having a shouting argument. As

shown in Figure 10, these activities resulted in a maxi mum noise level of 145 dBs.

Smartphone Traﬃc Accident Detection 21

(a) Shouting Argument (b) Loud Laughter

Fig. 10: Human Noise Levels During Highway Transportation

We ﬁnally measured the noise generated by playing the radio at maximum volume

and driving with all windows down. These activities also generated noise levels of

145 dB as sh own in Figure 11.

Based on these experiments, we determined that the abil ity for the device to

detect sound pressure levels greater than 145 d B is limit ed due to signal clipping.

Using sound levels alone to determine if an accident has taken place could therefore

potentially lea d to false positives as a result of norm al benign activities. We use

this result to tune our accident detection model to rely on t he accoustic signature

as a secondary indicator of acc idents and improve detection at accel eratio n values

below our accelerometer threshold. For ex ample, w hile th e device reporting a noise

level of 145 dB could be the result of a shouting match, a reading of 145 db and

a readi ng of 3.5G’s of force by the accelerometer would likely indicate that an

accident occurred.

4.3 Experiment 3: Evaluating Accident Reconstruction Capabilities

WreckWatch can potentially reconstruct an accident based solely on the data gath-

ered from the smartphone. Due to the smartphone’s presence in the vehicle during

an accident, the smar tphone will usually experience the same forces at the sa me

time as the occupants and t he vehicle itsel f. For example, ∼40% of cell phones are

carried in some form of pocket [17] , in whi ch case the device will likely experience

the same forces experienced by the person wearing the pocket.

Hypothesis ⇒ The accelerometer value would provide suﬃcient infor-

mation to reconstruct its movement during a crash. Due to the short time

period in w h ich a crash takes place, it is possible that a smartphone would have

insuﬃcient processing power and sensor sampling r ates to capture enough data

to accurately model t h e movement of the phone. We hypothesized that modern

22 J. White et al.

(a) Radio Max Volume (b) Max Volume with Windows Down

Fig. 11: Stereo Noise L evels During Highway Transportation

(a) X-Axis Acceleration (b) Y-Axis Acceleration (c) Z-Axis Acceleration

Fig. 12: Accelerati on While D ropped in a Car

smartphones have suﬃcient processing power and sens or sampli n g rates to aid in

accident reconst ruction.

Experiment setup. To demonstrate this approach, we analyzed the data from

the two experiments conducted in Section 4.1 to determine if we could reconstruct

the orientation and movement of the smartphon e.

Empirical resul ts. The graph in Figure 12a shows it is possible to determine

that the smar tphone was initially experiencing zero acceleration along the x-axis

indicating th at the x-axis was perpendicular to the ground. This orientation is

consistent with holding th e smartphone to the ear. While falling, the smartphone

tilt ed su ch the left edge of the sm artphone (relative to the screen with the scr een

facing away from the ground) was the closest edge to the sky and then ﬂip ped

agai n such t hat the left edge was clo s est to the ground. When Fig u res 12a, 12b,

and 12c are combined it is clear that the bott om of the smartphone made contact

ﬁrst, followed by the lef t edge, and ﬁnally the back of the dev ice.

Smartphone Traﬃc Accident Detection 23

(a) X-Axis Acceleration (b) Y-Axis Acceleration (c) Z-Axis Acceleration

Fig. 13: Accelerati on During a Sudden Stop

The acceleration experienced during the sudden stop was actually less than

that experienced during the fal l. Given what is known about t he event, it is there-

fore possible to identify the orientatio n of the smartphone during the event. By

examining the graphs in Figure 13 it is pos sible to deter mine that the smartphone

was resting at an angle such that the top of th e smartphone was higher than the

bottom o f the smar tphone. The decrease in acceleration along t h e z-axis is indica-

tive of t he force induced on the device by the seat as the car came to a rest. Graphs

of other sudden stop events also have a similar appeara nc e, as long as the device

remained stationary relati ve to the car .

These reconstruction capabilities can help accident investigators identify what

was experienced by the occupants of the vehicle and provide them with infor-

mation that an AD R/EDR simply cannot provide. This information can a lso be

combined with that present in the ADR/ EDR to better understand the entire ac-

cident rather than simply the forces experienced by the vehicle itself. WreckWatch

gives investigators the capability to analyze a real-world accident in a manner

simil ar to the way they would a controlled colli sion involving crash-test dummies.

Although WreckWa tch cannot provide investigators with all i mpact information

(e.g., the forces exper ienced at the ribs [15] or the pressure on the face [22]), it can

provide them with speciﬁc information about the overall force on the body and

how eﬀectively the restraints protected the passenger.

5 Related Work

This section compares WreckWatch with related work on accident and traﬃc detec-

tion systems. Our comparison with related work is organized as follows: (1) intel-

ligent transporta tion systems, (2) traﬃc monitoring with cell phones, (3) mayday

systems, and (4) traﬃc an d road monitoring monitoring sensor networks.

Intelligent transportation systems. The US Federal Communications Com-

mission (FCC) requires cell phones to provide emergency personnel with their lo-

cation. This mandate increases thei r viability as an accident-detection system by

ensuring that position data i s not limited to advanced smartphones. Vehicle local-

izati on [35] and r apid data acquisition are important to an Intelligent Transporta-

tion Sy s tem (ITS), which uti lizes sensor networks to m onitor traﬃc conditions

and make adjustments to increase safety and reduce congestion on transportation

networks [33]. These systems count cars to determine speed and congestion, as well

24 J. White et al.

as detect ice build-up and ot her hazards [19]. An ITS is not limited to highway

traﬃc mo nitoring [4]. One major advantage of WreckWatch is that it co u ld be

utili z ed as a subsystem to an ITS.

Traﬃc moni toring with cell phones. Related work ha s us ed cell ph ones to

construct a wireless mobile network for traﬃc-related applications. Traﬃc condi-

tions are often measured via loop detectors that count vehicles and determine their

sp eed. Since these loop detectors are typically embedded in the pavement there is

a high cost associated with their insta llation and maintenance [18]. Moreover, loop

detectors are often instal led in main highways, limiting available information [28].

Cell phones have been tapped as a pot ential solution to both of these issues,

because they provide a substantially larger amount of informati on, and because

cell phone tracking could be available on most roads without installing speci alized

detectio n hardware. WreckWatch is a step towards showing that cell phones are

an eﬀective medium towards a wireless sensor network focused on automob ile and

traﬃc information.

The European Nati onal Institute for Transport and Safety Research conduct ed

a study that used t h e volume of cell phones in range of a given cellular tower

to identify potential areas of congestio n or accidents [18]. This work is similar

to WreckWatch in that it utilizes the cellular radios for th e communication of

inform ation. WreckWatch is unique in that it utilizes the Android platform’s sensor

APIs to detect wrecks on a vehicle by vehicle basis, rather than using aggregate

metrics. WrechWatch’s execution directly o n t h e smartphone allows it to access

and utilize signiﬁcantly more inform ation about the device and user.

Mayday systems. Mayday systems provide voice connection to an emergency

assistance while automatically providing user location. Additional it ems tha t may-

day systems provide include remote doo r unlocking, remote engine diagnosis, theft

detectio n and tracking, automatic route guidance, travel information, and various

hands-free operations. Previous work [35] outlines the implications of location

awareness on cellular devices, and the eﬀect that this awareness would h ave on

mayday systems.

The WreckWatch system could be extended to pr ovide immediat e voice capa-

bilit ies via integrat ion with the Asterisk digita l PBX. Given WreckWatch’s current

integration with the Asterisk PBX, this extension is not technically hard to pro-

totype. Whi le remote diagnosis seems far-fetched, advances in automobile ECU

interfaces will likely make this possible in the future. With the increase in wireless

keys, remote door unlocking could be accomplished. If the phone has a wireless chip

at the correct frequency then i t can simply broadcast the door (or engine) key com-

bination. If not, add-on s martphone sensor interfaces can be built to provide such

capability. Route guidance, travel information, and hands-free operations could be

easily added to t h e WreckWatch system by utilizing various Android APIs.

Other work [34] focuses on using the cellular features of OnStar together

with accident detection functionality to investigate potential correlations between

hands-free phone calls and c ar accidents. This work analyzed the proximity of calls

to the OnStar system to an airbag deployment notiﬁcation. WreckWatch c ould be

extended to provide this information, a n d even more information by analyzing

behavior (such as texting, voice calls, Internet browsing or even gaming) prior to

an accident. Work to analyze the impact of distracti ons due to information sys-

tems (such as cell phones [ 31,14]) has relied on imprecise analysis that cou ld be

improved throug h the use of a system like WreckWatch that can not only detect

Smartphone Traﬃc Accident Detection 25

accidents, but i s also aware of potentially distracting actions, such as answering

calls or checking emails.

Traﬃc and road monitoring monitoring sensor networks. Other related

work has implemented sensor networks in constructio n zones to monitor traﬃc

ﬂow and congestion /citebathula2009 s ensor. These networks must be long-lived,

inexpensive, rapid ly deployable, and require mi n imal m aintenance. Wr eckWatch

provides all these capabiliti es at a signiﬁcantly lowered co s t to developers. More-

over, related work has not focused on the increased danger due to construction

zones occasionally introducing unfamiliar roads in an area where drivers feel fa-

miliarity and comfort. WreckWatch can include not only passi ve monitoring, but

also active alerting and notiﬁcation.

Monitoring road and t raﬃc conditions using smart ph ones has been evaluated

in past research. Prior work has focus ed on the sensing com ponent of detecting

various contextual items, such as honk detect ion and physical bump/brake/po thole

detectio n [23]. WreckWatch extends these co n cepts (e.g., adding airbag deployment

detectio n), capitalizes up on the advantag es of utilizing the underlying smartphone

cellula r infrastructure, provides automated interaction with emergency responders,

and automatically notiﬁes emergency contacts, such as family members.

6 Concluding Remarks

Reducing the time between when a n acc ident ta kes place and when it is detected

can reduce mortality rates by 6% [12]. Conventional in-vehicle accident detection

and notiﬁcation systems, such as OnStar, are eﬀective in reducin g the ti me ga p

before ﬁrst responders are sent to the scene. These systems, however, are expensive

and not available in all vehicles.

To further increase the usage of automatic accident detection and noti ﬁc a-

tion systems, smartphones can be used to indirectly detection accidents throu gh

their onboard sensors, such as accelerometers. Many challenges must be overcome,

however, particularly the potential for false positives from accidentally dropped

phones. Due to the large volume of “phantom” (accidental) calls to emergency

services, reducing the false positive rate of smartph one accident detecti on is im-

portant.

Using a combination of context data, such a s determining when a user is in-

side a vehicle, sensor data, such as accelerometer and acoustic information, and

intelligent sensor data ﬁltering, accident detection systems can be cr eated that are

resistant to false posit ives. For examp le, air bag deployment is only triggered at

over 60G’s of acceleration. As shown by experiments in Section 4, accelerations

above 4Gs are unlikely f or dropped phones.

In developing and evaluating our prototype accident detection and notiﬁcation

system, WreckWat ch, we learned the following lessons:

• Accidents exe rt extreme forces on a phone that are unlikely to occur

when dropping it. The forces experienced during a car coll ision are extreme and

highly unlikely to occur in any other event other than a high-speed collision. These

events are therefore eas ier to identify and catego rize accordingly. Moreover, by

combining the accident det ection process with contextual inf ormat ion to determine

when the user is in a vehicle, false positives are l es s likely.

26 References

• Smartphones can oﬀer novel situational awareness capabiliti es. Unin-

jured motorists and bystanders can serve as citizen scientists and provide multip le

streams of voice and imagery data from the scene of the accident. This information

can aid ﬁrst responder s in determining the s erverity of the accident, the victims in-

volved, and the urgency of medical care. Mo reover, smartphones can p rovide data

about the identify of the victims and automatically alert emergency contacts, such

as family members.

• Smartphones application stores signiﬁcantly aid in decreasing the cost

and complexity of software maintenance. The built-in application upgrade

mechanisms and communication channels on a smartphone make it possible to

push updates to thousands or milli ons o f clients and roll back if installation fails.

We have fou nd that this capability is quite helpful in mai ntaining/evolving the

software in accident detection and notiﬁcation systems.

• It may not be poss ible to detect all accidents with smartphones. Due

to the ﬁlt ers utilized to prevent false positives, it may be possi b le to experience

a low speed “f ender-b ender” witho u t the application detecting it. More work is

needed to enhance the ﬁltering mechanisms to account for these types of collisions.

In particular, WreckWatch’s ﬁltering algorithm could be enhanced to determine

whether the user is in a vehicle or not utilizing history information. For exa mple,

users often travel similar routes to work and WreckWatch could learn where stops

or reduct ions in speed are common by analysis of trends (e.g. if a person usually

travels through an area at 40mph but occasionally slows to a stop indicating a

potential traﬃc jam). Likewise, WreckWatch could use known intersections to

identify potential stops and anticipate them or download traﬃc i n formation to

predict the location of traﬃc jams resulting from long-duration redu ctions in speed.

• Acoustic data is not suﬃci ent for detecting traﬃc accidents. Our empir-

ical results show that some smartphone microphones and signal processing infras-

tructure suﬀers from signal clipping above 140dBs. This clippling makes it hard

to diﬀerentiate sounds, such as shouting, from air bag deployment. It i s possible

that this limitation can be overcome, but it will require additi onal work.

WreckWatch is an open-so u rce Android application tha t is freely available from

code.google.com/p/vtnetapps.

Acknowledgements This work was supported by a grant from the National Science Founda-

tion, RAPID:Collaborative Research:Cloud Environmental Analysis and Relief, CNS# 1047753.

References

1. National Highway Traﬃc Safety Administration. Federal Motor Vehicle Safety Standards:

Occupant Crash Protection - Supplemental Notice of Proposed Rulemaking, 1999.

2. National Hi ghway Transpor tation Safety Administration. 2007 Traﬃc Safety Annual As-

sessment - Highlights. 2008.

3. M. Alsliety. How does SDR ﬁt the telematics mo del?

4. M. AP TAYLOR. INTELLIGENT TRANSPORT SYSTEMS. Handbook of transport

systems and traﬃc control, page 461, 2001.

5. A. Askl and. Double Edged Sword That Is the Event Data Recorder, The. Temp. J. Sci.

Tech. & Envtl. L., 25:1, 2006.

6. A. Blandford and BL William Wong. Situation awareness in emergency medical dispatch.

International Journal of Human-Computer Studies, 61(4):421–452, 2004.

References 27

7. H.R. C hampion, J. Augenstein, A.J. Blatt, B. Cushing, K. Digges, J.H. Siegel, and M.C.

Flanigan. Automatic crash notiﬁcation and the U RGENCY algorithm: Its history, value,

and use. Advanced Emergency Nursing Journal, 26(2):143, 2004.

8. Chris Thompson and Jules White and Brian Dougherty and Adam Albright and Douglas

C. Schmidt. Using Smar tphones and Wireless Mobile Networks to Detect Car Accidents

and Provide Situational Awareness to Emergency Responders. In Third International

ICST Conference on MOBILe Wi reless MiddleWARE, Operating Systems, and Applica-

tions (Mobilware 2010), June 30-July 2, 2010, Chicago, IL.

9. A. Cohen and L. Einav. The eﬀects of mandatory seat belt laws on driving behavior and

traﬃc fatalities. Review of Economics and Statistics, 85(4):828–843, 2003.

10. J.P. Cohn. Citizen science: can volunteers do real research? BioScience, 58(3):192–197,

2008.

11. M.R. Endsley. Toward a theory of situation awareness in dynamic systems. Human

Factors: The Journal of the Human Factors and Ergonomics Society, 37(1):32–64, 1995.

12. W. Evanco. The Impact of Rapid Incident D etection on Freeway Accident Fatalities.

Mitretek Systems, Inc., WN96W0000071, 1996.

13. B. Fi ldes, S. Newstead, JS Barnes, and AP Morris. Airbag eﬀectiveness in real world

crashes, 2001.

14. P. Green. Crashes induced by driver information systems and what can be done to reduce

them. In SAE CONFERENCE PROCEEDINGS P, pages 27–36. SAE; 1999, 2000.

15. L. Groesch, G. Netzer, and L. Kassing. Dummy for car crash testing, October 20 1987.

US Patent 4,701,132.

16. J. Harrald and T. Jeﬀerson. Shared situational awareness in emergency management

mitigation and response. In System Sciences, 2007. HICSS 2007. 40th Annual Hawaii

International Conference on, page 23. IEEE, 2007.

17. F. Ichikawa, J. Chipchase, and R. Grignani. Where’s the phone? a study of mobile phone

lo cation in public spaces. In Proc. IEE Mobility Conference 2005. Citeseer, 2005.

18. W. D. Jones. Forecasting Traﬃc Fl ow. IEEE Spectrum, 2001.

19. A.N. Knaian. A wireless sensor network for smart roadbeds and intelligent transportation

systems. PhD thesis, Citeseer, 2000.

20. A. Lenhart. Teens and mobile phones over the past ﬁve years: Pew Internet looks back.

Pew Internet & American Life Project, 2009.

21. A. Lie, C. Tingvall, M. Kraﬀt, and A. Kullgren. The eﬀectiveness of electronic stability

control (ESC) in reducing r eal life crashes and injuries. Traﬃc Injury Prevention, 7(1):38–

43, 2006.

22. H. Mellander, S. Nilsson, C.Y. Warner, M.G. Wille, and M. Koch. Load-sensing faceform

for crash dummy instrumentation, September 8 1987. US Patent 4,691,556.

23. P. Mohan, V.N. Padmanabhan, and R . Ramjee. Nericell: Rich m onitoring of road and

traﬃc conditions using mobile smartphones. In Proceedings of the 6th ACM conference

on Embedded network sensor sy stems, pages 323–336. ACM New York, NY, USA, 2008.

24. R.S. Naunheim, J. Standeven, C. Richter, and L.M. Lewis. Comparison of impact data in

hockey, football, and soccer. The Journal of Trauma, 48(5):938, 2000.

25. W.I.S. Query. Reporting System (WISQARS). National Center for Injury Prevention and

Control, Centers for Disease Control and Prevention (producer). Available from: UR L:

www. cdc. gov/ncipc/wisqars.

26. S. Rauscher, G. Messner, P. Baur, J. Augenstein, K. Digges, E. Perdeck, G. Bahouth, and

O. Pieske. Enhanced Automatic Collision Notiﬁcation System- Improved Rescue Care

Due To Injury Prediction- First Field Experience, 2009.

27. Mikael Rickns. Idg news service. http://www.infoworld.com/d/mobilize/

android-big-winner-smartphone-sales-increase-50-percent-710, August 2010.

28. G. R ose. Mobile phones as traﬃc probes: practices, prospects and issues. Transport

Reviews, 26(3):275–291, 2006.

29. R. Sampson. Misuse and A buse of 911, 2000.

30. J.E. Saunders, W.H. Slattery III, and W.M. Luxford. Automobile airbag impulse noise:

Otologic symptoms in six patients*. Otolaryngology -Head and Neck Surgery, 118(2):228–

234, 1998.

31. P. Trbovich and J.L. Harbl uk. Cell phone communication and driver visual behavior:

The impact of cognitive distraction. In CHI’03 extended abstracts on Human factors in

computing systems, page 729. ACM, 2003.

32. M. Verma, R. Lange, and D. McGarry. A Study Of US Crash Statistics From Automated

Crash Notiﬁcation Data, 2007.

28 References

33. RJ Weiland and LB Purser. Intelligent Transportation Systems. Transportation Research,

1:40AM, 2009.

34. R.A. Young. As sociation between emb edded cellular phone calls and vehicle crashes in-

volving airbag deployment. In Proceedings of the 1st International Driving Symposium on

Human Factors in D ri ver Assessment, Training, and Vehicle Design, Aspen, CO, pages

390–400, 2001.

35. Y. Zhao. Mobile phone location determination and its impact on intelligent transportation

systems. IEEE Transactions on Intelligent Transportation Systems, 1(1):55, 2000.