ISSN 1055- 1425
April 2010
This work was performed as part of the California PATH Program of the
University of California, in cooperation with the State of California Business,
Transportation, and Housing Agency, Department of Transportation, and the
United States Department of Transportation, Federal Highway Administration.
The contents of this report reflect the views of the authors who are responsible
for the facts and the accuracy of the data presented herein. The contents do not
necessarily reflect the official views or policies of the State of California. This
report does not constitute a standard, specification, or regulation.
Final Report for Task Order 6615
CALIFORNIA PATH PROGRAM
INSTITUTE OF TRANSPORTATION STUDIES
UNIVERSITY OF CALIFORNIA, BERKELEY
Safetrip- 21: Connected Traveler
UCB- ITS- PRR- 2010- 23
California PATH Research Report
Raja Sengupta, et al.
CALIFORNIA PARTNERS FOR ADVANCED TRANSIT AND HIGHWAYS
1 of 1
SAFETRIP- 21: CONNECTED TRAVELER
Task Order 6615
FINAL REPORT
Raja Sengupta, Principal Investigator
Jim Misener, Project Manager
Katherine Ahern
Ching- Yao Chan
Somak Datta Gupta
Jerry Jariyasunant
Jing- Quan Li
Christopher Long
Eric Mai
Christian Manasseh
Christopher Nowakowski
Jessical O’Connell
Shahram Rezai
Michael Steelhorst
Liping Zhang
Wei- Bin Zhang
Kun Zhou
Xeusong Zhou
University of California, Berkeley
1357 S. 46th Street, Bldg. 190; Richmond, CA 94804- 4648
March 2010
2 of 2
3 of 3
Contents
1 Executive Summary.............................................................................................................. 13
2 Background and Introduction ............................................................................................... 14
2.1 Urgency, Payoff Potential, and Implementation ............................................................ 15
2.2 Research Objective......................................................................................................... 15
2.3 Research Plan and Deliverables ..................................................................................... 16
3 Safety System Development................................................................................................. 17
3.1 Experimental Design...................................................................................................... 17
3.1.1 Background............................................................................................................. 17
3.1.2 Premise.................................................................................................................... 17
3.1.3 Safety Applications................................................................................................. 17
3.1.4 Safety Applications Test Hypotheses ..................................................................... 19
3.1.5 Validation of Test Hypotheses................................................................................ 22
3.1.6 Data Collection and analysis................................................................................... 28
3.2 Estimation of Sample Size ............................................................................................. 33
3.2.1 Problem Description ............................................................................................... 33
3.2.2 Population Size ....................................................................................................... 33
3.2.3 Experimental Outcome Variables and Their Distribution ...................................... 34
3.2.4 Sample Size and User Base .................................................................................... 34
3.2.5 Sample Size Table .................................................................................................. 36
3.2.6 Explanation of Parameters ...................................................................................... 36
3.2.7 Technical Basis of Equations used ......................................................................... 36
3.2.8 Variation of Sample Size with respect to Different Parameters ............................. 38
3.3 System Architecture ....................................................................................................... 42
3.3.1 Networked Traveler Server..................................................................................... 43
3.3.2 Cellular Phone......................................................................................................... 44
3.4 Services .......................................................................................................................... 45
3.4.1 Routing.................................................................................................................... 45
3.4.2 Slow Traffic Ahead Alert ....................................................................................... 50
3.5 Website........................................................................................................................ .. 52
3.6 Outreach ......................................................................................................................... 54
3.7 Safety Benefit Feasibility Assessment ........................................................................... 55
3.7.1 Premise.................................................................................................................... 55
3.7.2 Applications ............................................................................................................ 55
3.7.3 Notification of Incidents and Non- recurrent Congestion Ahead ............................ 60
3.7.4 Safety Applications Test Hypotheses ..................................................................... 61
3.7.5 Validation of Test Hypotheses................................................................................ 64
3.8 Execute Safety Field Test............................................................................................... 69
3.8.1 Client Software Distribution................................................................................... 69
3.8.2 Data Collection and Release ................................................................................... 69
4 Mobile Probe- Based Traffic Monitoring and Information Provision Systems..................... 70
4 of 4
5 of 5
4.1 System Architecture ....................................................................................................... 70
4.2 Traffic Congestion Information Dissemination ............................................................. 72
4.2.1 Multi- criteria Routes in New York City ................................................................. 72
4.2.2 Park and Ride Route ( Brown) in Salt Lake City .................................................... 73
4.3 Mobile Phone- Based System Implementation ............................................................... 73
4.3.1 System Setup........................................................................................................... 73
4.4 GPS Data Mining System for Safety- related Benefit Analysis ..................................... 76
4.4.1 Introduction............................................................................................................. 76
4.4.2 Problem statement................................................................................................... 77
4.4.3 Road Network Decomposition and Grid Construction:.......................................... 78
4.4.4 Map Matching:........................................................................................................ 79
4.4.5 The Initial State....................................................................................................... 80
4.4.6 Intersections ............................................................................................................ 80
4.4.7 Cycles...................................................................................................................... 81
4.4.8 Travel Time............................................................................................................. 81
4.4.9 Cellular Phones:...................................................................................................... 82
4.4.10 Allowing for Multiple Devices:.............................................................................. 82
4.4.11 Future Work:........................................................................................................... 82
4.5 Technical Support for System Field- testing and Deployment ....................................... 83
5 Transit System Development................................................................................................ 88
5.1 Experimental Design...................................................................................................... 88
5.1.1 Background............................................................................................................. 88
5.1.2 Premise.................................................................................................................... 88
5.1.3 Transit Applications................................................................................................ 89
5.1.4 Transit Applications Test Hypotheses .................................................................... 89
5.1.5 Validation of Test Hypotheses................................................................................ 91
5.1.6 Data collection and analysis ................................................................................... 94
5.2 System Architecture ..................................................................................................... 102
5.2.1 Architecture overview........................................................................................... 102
5.2.2 System components .............................................................................................. 103
5.2.3 Transit data elements and related systems............................................................ 104
5.3 Services ........................................................................................................................ 106
5.3.1 Reliable Real- Time Transit Information Based on AVL System......................... 107
5.3.2 En route information: Waiting for Transit to Arrive ............................................ 111
5.3.3 En route: Riding Transit ....................................................................................... 112
5.3.4 Arterial Travel Time Estimation using Bus- as- probe........................................... 113
5.4 Outreach ....................................................................................................................... 117
5.5 Transit Benefit Feasibility Assessment........................................................................ 118
5.6 Execute Transit Field Test ........................................................................................... 119
5.6.1 NT Transit Test Hypothesis.................................................................................. 119
5.6.2 System Evaluation of the NT Transit System....................................................... 123
5.6.3 Field Evaluation of the Bus- as- a- probe Travel Time Estimation ......................... 132
5.6.4 Field Evaluation of the NT Transit Services ........................................................ 134
6 References:.................................................................................................................... ..... 135
7 Appendices: ........................................................................................................................ 136
6 of 6
7 of 7
Appendix- A: Candidate FOT Sites for the Safety Application .............................................. 136
Appendix- B: Candidate FOT Sites for the Transit Application ............................................. 139
Appendix- C: GPS Data Mining System for Safety- related Benefit Analysis ........................ 139
8 of 8
9 of 9
List of Figures:
Figure 3- 1: Safe- Trip 21 Safety Applications............................................................................... 18
Figure 3- 2: Hypothesized Expected Outcomes of Safe- Trip 21 Safety Applications .................. 22
Figure 3- 3: Expected User Responses and Safety Impacts of Safe- Trip 21 Safety Applications 22
Figure 3- 4: Safe- Trip 21 Safety Applications and Observable Outcome..................................... 23
Figure 3- 5: Networked Traveler System Architecture ................................................................. 43
Figure 3- 6: Cellular Phone Client Architecture............................................................................ 44
Figure 3- 7: Networked Traveler User Experience........................................................................ 45
Figure 3- 8: New York network in the routing engine .................................................................. 47
Figure 3- 9: Optimal routes based on up to seven criteria ............................................................. 48
Figure 3- 10: Slow traffic ahead alert logic ................................................................................... 51
Figure 3- 11: Image of the slow traffic ahead alert........................................................................ 52
Figure 3- 12: Account creation page of the Networked Traveler website..................................... 53
Figure 3- 13: Google Maps visualization of the alerts, with the informational popup.................. 54
Figure 3- 14: Safe- Trip 21 Safety Applications............................................................................. 55
Figure 3- 15: Area Wide Map of Potential Study Sites Locations ................................................ 57
Figure 3- 16: An Illustrative Map of Mapped Locations with Real- Time Traffic Data Feed ....... 59
Figure 3- 17: An Illustrative Map of Mapped Locations with Real- Time Traffic Data Feed ....... 60
Figure 3- 18: Hypothesized Expected Outcomes of Safe- Trip 21 Safety Applications ................ 63
Figure 3- 19: Expected User Responses and Safety Impacts of Safe- Trip 21 Safety Applications
............................................................................................................................... ...................... 63
Figure 3- 20: Safe- Trip 21 Safety Applications and Observable Outcome................................... 64
Figure 4- 1: System architecture of mobile Probe- Based Traffic Monitoring and Information
Provision Systems........................................................................................................................ 71
Figure 4- 2: Multi- criteria Routes in New York City .................................................................... 72
Figure 4- 3: Park and Ride Route ( Brown) in Salt Lake City........................................................ 73
Figure 4- 4: Link segment as a dashed line as well as the four parallel segments surrounding the
dashed line. ............................................................................................................................... ... 79
Figure 4- 5: Representation of a link segment and the grid cells it lies within. ............................ 79
Figure 4- 6: An example of the path representation. Each child points to its parent..................... 80
Figure 4- 7: Routing engine web Service performance test........................................................... 84
Figure 4- 8: Routing engine performance results, number of transitions per second.................... 85
Figure 4- 9: Routing engine performance results, responding Time ............................................. 85
Figure 4- 10: Routing engine over- load performance results, response Time............................... 86
Figure 4- 11: Map matching engine performance results, number of transitions per sec.............. 87
Figure 4- 12 Map matching engine performance results, response time ....................................... 87
Figure 5- 1: Hypothesized Expected Outcomes of Safe- Trip 21 Transit Applications ................. 91
Figure 5- 2: Sample Size Requirements for Different Population Sizes ....................................... 98
Figure 5- 3: System architecture of the DPI system .................................................................... 102
Figure 5- 4: A generalized transit ITS system architecture ......................................................... 103
Figure 5- 5: Connected Traveler Transit System Components.................................................... 104
Figure 5- 6: System Components of the transit system ............................................................... 105
Figure 5- 7: Architecture of real- time arterial performance measurement system ( APeMS)...... 106
Figure 5- 8: The NT Transit Bus / Train Routes Along US101 Corridor..................................... 107
Figure 5- 9: Scheduled Travel Time to Time- Points ( VTA Rapid 522 WB Weekday Trips)..... 109
Figure 5- 10: Scheduled Travel Time to Time- Points ( VTA Rapid 522 EB Weekday Trips) .... 110
10 of 10
11 of 11
Figure 5- 11: Scheduled Travel Time between San Jose and San Francisco .............................. 110
Figure 5- 12: Scheduled Travel Time between Consecutive Stops ............................................. 111
Figure 5- 13: En- Route – Next Transit Vehicle Information While Waiting at the Bus Stop..... 112
Figure 5- 14: En Route – My Stop Information........................................................................... 113
Figure 5- 15: Trajectories of test vehicle, BRT and local buses.................................................. 115
Figure 5- 16: Cumulative distribution function ( CDF) of cruise speeds for a BRT bus and a test
vehicle........................................................................................................................ ................ 117
Figure 5- 17: Hypothesized Expected Outcomes of Safe- Trip 21 Transit Applications ............. 120
Figure 5- 18: Cumulative distribution of the instantaneous throughput ( Bytes/ s) ...................... 125
Figure 5- 19: Hourly system service availability......................................................................... 125
Figure 5- 20: The End- to- End Latency of AVL Data.................................................................. 126
Figure 5- 21: Histogram of the End- to- End AVL Data Latency ................................................. 126
Figure 5- 22: Caltrain GPS Outage Occurrences......................................................................... 127
Figure 5- 23: Statistics of the Caltrain GPS Outage .................................................................... 128
Figure 5- 24: VTA 522 GPS Outage Occurrences ...................................................................... 129
Figure 5- 25: Statistics of the VTA 522 GPS Outage.................................................................. 129
Figure 5- 26: Caltran Schedule Deviation ................................................................................... 130
Figure 5- 27: Caltrain Arrival Time: Actual vs Predictive .......................................................... 131
Figure 5- 28: VTA 522 Schedule Deviation................................................................................ 131
Figure 5- 29: VTA 522 Arrival Time: Actual vs Predictive........................................................ 132
Figure 5- 30: Delay comparisons between all traffic and bus probes.......................................... 133
Figure 5- 31: Arterial Performance Measurements ..................................................................... 134
Figure 7- 1: Area Wide Map of Potential Study Sites Locations ................................................ 137
12 of 12
13 of 13
1 Executive Summary
The US DOT RITA Volpe Center entered into a cooperative agreement with the California
Department of Transportation ( Caltrans) to establish the inaugural SafeTrip 21 field test site in
the San Francisco Bay area [ named Connected Traveler]. Specifically, the site encompasses I-
880 from Oakland to San Jose on the east bay and from San Jose to just south of the San
Francisco International Airport, along U. S. 101 and California State Route ( SR) 82. The site
includes the SR- 84 Dumbarton Bridge toll crossing, which links I- 880 and U. S. 101.
Caltrans's partners include the Metropolitan Transportation Commission, the University of
California- Berkeley's California Partners for Advanced Transit and Highways ( PATH), the
California Center for Innovative Transportation, Nokia, Inc., NAVTEQ, Santa Clara Valley
Transportation Authority, and Nissan. The cost of the $ 12.4 million field test was funded by
private and public sector partners, including the USDOT contribution, equally. ( Public Roads,
September/ October 2008)
The Networked Traveler is part of the Connected Traveler component of the U. S. DOT
( Research and Innovative Technologies Administration, RITA) SafeTrip- 21 initiative. SafeTrip-
21 aims to expand and accelerate the U. S. DOT IntelliDrive initiative, and SafeTrip- 21 builds
upon research into the use of sophisticated information, navigation, and communications
technologies to further national transportation goals. The Connected Traveler effort contains the
several California Department of Transportation ( Caltrans)- led projects under the SafeTrip- 21.
The Networked Traveler component is one of the partner projects, and roughly described, it has
three components:
1. A technology exploration which acknowledges that a 3G wireless- and WiFi- connected
smartphone is the currently available means to connect travelers and mobility- and safety-related
information- driven and personalized information. This technology exploration was
manifested in a multi- partner, multi- application transit bus where safety, mobility, transit-and
road- systems operations transportation services was delivered. This effort was initiated
in 2008, and it culminated in a demonstration of these applications, delivered in a New York
City transit bus application. It is primarily this – the vision, creation, development and
demonstration – that this nomination is focused.
2. The 2008 planning ( and in 2009, delivery) of a field test enabling evaluation of the validity
of the hypothesis that safety can be effected by providing situational awareness over a longer
foresighted horizon, e. g., “ slow traffic ahead” via consumer- held smartphones. As a second
component of this field test is to use the same smartphone application and arterial travel data,
plus real time transit schedule information, to capture the effect and desirability of
smartphone-“ pushed” data on transit users. Both portions will occur in the San Francisco Bay
Area.
3. The 2008 planning ( and again in 2009, delivery) of a field test where parking availability
information and transit travel time for rail ( Caltrain) and bus ( SamTrans), traffic conditions,
and travel time information for freeways and major arterial highways was delivered in real-time,
to support travelers’ trip decisions and to encourage the use of alternative modes of
14 of 14
transportation. The goal is to promote efficient use of the existing transportation
infrastructure, and in turn, reduce congestion and associated vehicle emissions.
Component 1 ( SafeTrip- 21 Networked Traveler Development and Demonstration) has opened
the gates on this project for Components 2 ( Safety and Mobility Field Test and Evaluation) and 3
( Parking Information and Mode Switch Field Tests and Evaluation). More importantly, the
Networked Traveler Development and Demonstration has opened the world’s eyes on how
[ vision] x [ near term technology] x [ implementation] provides a product which in the near- to
mid- term could transform how travelers receive information and, ultimately, behave.
Indeed, the Networked Traveler project is aimed at bringing information to the traveler, and then
to the transportation system now. While it primarily addresses the need for transformational
change in safety and mobility services desired by systems operators and travelers alike, it
bootstraps off the observation that the web is here, that mobile and connected consumer
electronic devices are here, and the dire need for safety and mobility information is evident.
A major element to the work was the Networked Traveler World Congress Development and
Demonstration, given in New York City in November, 2008. To conceive and deliver the
demonstration resulted in development of three main services. “ Tell me about my trip” assists
trip planning with traffic information, transit connections, and driving choices for an eco- route
and a fastest route. “ Tell me about my route” can provide travelers with real- time road- safety
conditions, real- time traffic and parking conditions, schedule- driven transit information, real-time
GPS- based transit status, road signage. “ Watch out for me!” includes services such as the
pedestrian- to- vehicle safety alert, the vehicle- to- pedestrian safety alert, road- to- vehicle road
safety information, road hazard alerts, and work zone alerts.
Within this framework, a plethora of smartphone- delivered services were provided: Pedestrian
alerts allowed slow- moving pedestrians to signal drivers to watch out; a work zone alert signaled
phones on the demo bus to slow down for its approach to the cone area; centralized, real- time
transit information helped virtual commuters meet their trains and buses on time; and smart
parking simplified a modal switch by helping drivers find and reserve available parking in real-time.
Other items in the demo included updated travel time estimates, next- stop alerts, and a
hydrocarbon- savings calculator for transit riders and speed zone and signal priority alerts for
drivers.
The objective was to show what could happen in a Networked Traveler ethos, then put it on the
road to illustrate and punctuate the reality. Another objective is that the research team associated
with Networked Traveler was able to learn significantly and the mid- term result of bringing
selected applications into a field evaluation was brought closer to reality.
2 Background and Introduction
This research agreement addresses the field test elements of the Caltrans- US DOT cooperative
agreement for SafeTrip- 21 research award and therefore builds upon the technical foundation –
using smartphones to deliver critical safety and mobility information.
15 of 15
2.1 Urgency, Payoff Potential, and Implementation
The urgency and payoff potential are linked and therefore high: the proposed research combines
near term enabling situational awareness and transit applications from public, private and
academic stakeholders. The research holds promise to combine the resources and commitment of
the public sector, with private sector innovation, to provide multiple means to deliver safety and
mobility applications for travelers on arterials and freeways alike for system management and
traveler information, for multiple modes ( transit, as well as passenger vehicles), and for multiple
applications ( to include commercial). It does not place all resources or “ bet” on DSRC ( or
cellular or WiFi); it enables all. Importantly, it addresses safety improvement goals enabled by
‘ connectivity’ with the advent of ubiquitous wireless ‘ smartphones’ and therefore pervasive
information- rich communications.
In light of how leading high- tech companies do business today, it is clear that fast- prototyping
and an evolutionary approach are replacing central planning and long development cycles. It is
the program team’s belief that key safety goals can be readily explored and a rich dataset
provided for independent evaluation. The concept of delivering to drivers multiple safety
services via GPS- equipped cell phones carries important public benefits of utmost relevance to
Caltrans. Additionally, the concept of providing transit data for traffic, and for delivering to other
travelers, notably transit riders, connectivity information by smartphones, is also of importance
and relevance to Caltrans.
2.2 Research Objective
The primary field test component will evaluate the hypothesis, “ Smartphones can help people
drive more safely.” Thus, the primary deliverable of was a dataset enabling evaluation of the
validity of the hypothesis. The dataset will record the experience of drivers using the connected
traveler field test system. The field test system was comprised of a:
• software client downloaded by the driver onto the driver’s smartphone,
• server that will support the client with information,
• roadside sensors that will provide information to the server, and
• networking services to connect the driver’s smartphone to the server.
We expect a field test participant to provide his or her own phone and data plan in anticipation
that the system will deliver sufficiently high value. We aim to design the field test system so that
the driver perceives it to frequently deliver value. This is because, in the absence of cash
incentives, drivers who do not perceive value or who are annoyed by the client are likely to react
by turning it off or uninstalling it.
Likewise, to minimize distribution costs, we will implement a distribution strategy based on the
perceived value of the field test system and will work to acquire participants from specific
groups or associations.
16 of 16
Based on the field test hypothesis and the objective to minimize distribution costs by offering
sufficient perceived value to drivers and media, we have conceived the following service
package to provide the field test system to each participant:
• An origin- to- destination routing service. This was multi- criteria and based on that
demonstrated by us at the ITS World Congress in New York. The user was able to
customize routing based on the desire to travel with reduced emissions, reduced trip time,
or reduced variance.
• Augmentation of this service by a “ smart push” functionality able to actively monitor
conditions on the route and pro- act to offer the driver alternative routes if conditions
change significantly. Current systems require the traveler to “ pull” information, whereas
smartphones can enable the “ smart push.”
• Bundle the prime objective of the field test, the safety component, into the smart push.
This module will provide the driver with situational awareness of approaching road
hazards, such as slow traffic queues, incidents, and non- recurrent congestion. Recurrent
congestion is covered by the routing service
The three services are provided via a single software download to be executed by the
participant from the connected traveler website.
2.3 Research Plan and Deliverables
The field test was executed in two phases, resulting in the schedule and milestones in the table
below. Phase 1 ( Connected Traveler Testing) is the primary focus of this project and will directly
address the safety field test, in addition to providing the SafeTrip- 21 transit elements. Phase 2
( Exploratory Testing) focuses on the ‘ next step’ services, conducting the pedestrian safety and
eco- driving aspects of SafeTrip- 21, with smaller scale data collection. Because of the exploratory
nature of Phase 2, while the field testing are goals, the detailed definition is contingent on
success of the development and experimental installation. This is in contrast to Phase 1, which is
the primary focus and with explicit by- task deliverables.
Table 2- 1: Task Listing
Task No. Task Start Date End Date Milestone
Phase 1,
Task 1 ( 1.1)
Phase 1: Safety System
Development
January 1,
2009
March 15,
2009
Phase 1 launch
1.2 Phase 1: Outreach January 1,
2009
March 15,
2009
Phase 1 launch
1.3 Phase 1: Safety Benefit
Feasibility Assessment
January 1,
2009
November 30,
2009
1.4 Phase 1: Execute Safety Field
Test
March 15,
2009
November 30,
2009
Phase 1 dataset
1.5 Phase 1: Transit System
Development
January 1,
2009
March 15,
2009
Phase 1 launch
1.6 Phase 1: Transit Benefit January 1, November 30,
17 of 17
Feasibility Assessment 2009 2009
1.7 Phase 1: Execute Transit Field
Test
March 15,
2009
November 30,
2009
Phase 1 dataset
Phase 2 Phase 2: System Development
and Field Tests
March 15,
2009
November 30,
2009
Phase 2 launch
Task 3 Project Management and
Reporting
January 1,
2009
December 31,
2009
Reports / Final
Report
3 Safety System Development
3.1 Experimental Design
3.1.1 Background
A California PATH research team is preparing the deployment of safety applications under a
Networked Traveler project, in conjunction with the US DOT Safe Trip 21 efforts. This
document describes the premise, hypotheses, rationale, and the approach for conducting field
experiments, with the goal of assessing the validity and usability of the proposed safety
applications.
3.1.2 Premise
If drivers are better informed of the traffic conditions in their driving environment, they was
more aware and better prepared to take actions to avoid hazardous situations. Within the scope of
this study, we focus on the “ soft” safety applications that have a relatively longer time window to
provide drivers with alerts. A “ hard” safety application, by comparison, requires an immediate
action. For example, a system that warns drivers of imminent freeway front- end collisions with
another car in front will need to take effect within 1- 5 seconds. On the other hand, one example
of the “ soft” safety applications that we propose to offer is the situational awareness alert that
can be effective in a 10- 60 second time window. For example, in a situation where drivers cannot
see the slow or stopped traffic beyond a curved roadway ahead, at a distance of 1 mile or less
before the driver reaches at location, we can issue an alert to the driver especially when the
driver’s subject vehicle is traveling significantly faster than the traffic queue ahead.
3.1.3 Safety Applications
A suite of applications are being considered and to be deployed for the planned field experiments.
Most of these applications are designed for freeway driving conditions, which are the primary
test targets in this stage of the Networked Traveler project. The core list of safety applications
are given in the diagram below, and they are explained summarized as follows:
18 of 18
Figure 3- 1: Safe- Trip 21 Safety Applications
3.1.3.1 Situational Awareness of Slow Traffic Queues
The first application is a situational- awareness function that provides alerts to drivers on driving
conditions within a relatively short- latency time horizon, in the range of 10- 60 seconds. For this
application, we focus on specific highway locations where past traffic and crash patterns indicate
that a Connected- Traveler system can offer useful alerts so that drivers can take tactical actions
to avoid crashes, or in essence increase their ‘ safety alert time horizon’ to beyond the just several
seconds based on driver reaction or provided by active safety systems. In these situations, by
offering a timely “ slow or stopped traffic ahead” message the system can effectively inform
drivers of roadway hazards to reduce chances of crashes and realize safety benefits.
The research team has investigated the collision data for the last ten years and identified some
potential sites for this application. Based on the results of initial screening, a preliminary field
survey was carried out in recent weeks. A list of candidate locations, their attributes and maps
are given in Appendix A.
3.1.3.2 Curve Over- speed Alert
The second application is a curve over- speed warning, which can also be considered part of the
situational- awareness function in Application One above. For this application, we focus on
specific highway locations where users can benefit by being reminded to reduce speed as they
approach certain roadway segments. Some of these segments are off- ramps from freeways,
including a few sites identified in Appendix A. In these situations, by offering a timely “ slow
down for sharp curves ahead” message the system can effectively inform drivers of roadway
hazards to reduce chances of crashes and realize safety benefits.
3.1.3.3 Work Zone Alert
Another application is a work- zone- ahead advisory, which can be applicable in a relatively short-time
horizon such as Application One and Two above, just prior to a user reaches work zone
areas. This application can also be provided in a relatively longer time frame, for example 5- 20
minutes before the expected user route passes through ongoing work zones. In the former case,
Safe Trip 21
Networked
Traveler
Safety Tests
Slow Traffic
Queue Ahead
Curve Over-speed
Alert
Work Zone
Ahead
Notification of
Incident and
Congestion
Stop Sign Alert
19 of 19
users can benefit by being reminded to reduce speed and be cautious as they approach work
zones. In the latter case, the users can make strategic decisions to change routes to avoid passing
through a restricted or congested area. In these situations, by offering a timely “ work zone
ahead” message the system can effectively inform drivers of roadway hazards to reduce chances
of crashes and realize safety benefits.
3.1.3.4 Notification of Incidents and Non- recurrent Congestion Ahead
One other application is the notification of incidents and non- recurrent congestion on the road
ahead to the drivers based on real- time traffic data. The major premise of this application of
“ Incident and Congestion Alert” is as follows:
( 1) First of all, drivers can stay informed of roadway traffic conditions, which allow them to
make trip planning choices. The information was “ pushed” to users based on their current
positions and travel routes.
( 2) Secondly, in congested areas on highways, various hazardous scenarios may develop and
lead to increased likelihood of collisions. With the proposed application, an earlier
notification alert to the drivers, in the range of 2- 30 minutes can offer drivers
opportunities to take tactical and strategic actions, including:
- Reducing speeds with increased awareness of slow traffic ahead
- Choosing to change routes to avoid further trip delays
- Changing transportation modes by switching to transit or travel plans, with benefits of
reducing traffic demands on flow- stressed or incident- impaired roadway segments
3.1.3.5 Stop Sign Alert
Another application is a stop- sign advisory, which can be applicable for off- ramp or local street
locations, just prior to a user reaches a stop sign. This application relies on the availability of
stop sign database. In these situations, by offering a timely “ stop sign ahead” message the system
can effectively inform drivers of roadway hazards to reduce chances of crashes and realize safety
benefits.
3.1.4 Safety Applications Test Hypotheses
For each of the applications that are to be deployed for the field tests, the hypothesized outcome
and the expected user responses and the safety impacts are described and listed in Table 3- 1.
Table 3- 1: Safety Application and Test Hypotheses
Application Applicable Situations Hypothesized Outcome Expected Driver
Response and Safety
Effects
Slow Traffic Ahead • Traffic queues ahead
of curved roadway
with limited
visibility
• Collisions are
caused by vehicles
approaching too fast
toward the end of
• Collisions can be avoided if
drivers are given alerts in a time
frame that allows them to slow
down in advance
• Drivers can make cautious
approach before reaching end of
queue by receiving alerts
• Drivers benefit by an elevated
• Drivers provide
favorable assessment
of the alerts
• Drivers respond
positively and
noticeably to the alerts
• Drivers reduce speed
earlier or more
20 of 20
slow traffic queue
sense of safety and comfort
from the alerts even if the
drivers can take timely, evasive
actions without the alerts
significantly with the
alerts than without the
alerts
• Drivers make lane
change maneuvers to
other lanes to avoid
slow queue
Slow Traffic Ahead • Off- ramp queue
buildup and
spillover into
freeway
• Collisions are
caused by vehicles
approaching too fast
toward the end of
slow traffic queue
• Same as above
• Same as above
Slow Traffic Ahead • Severe traffic
weaving section
• Collisions are
caused by vehicles
sideswiping or rear-ending
other
vehicles are making
moving across lanes
in the weaving
section
• Collisions can be avoided if
drivers are given alerts in a time
frame that allows them to make
cautious approach before
reaching the weaving section
• Drivers benefit by an elevated
sense of safety and comfort
from the alerts even if the
drivers can take timely, evasive
actions without the alerts
• Same as above
Curve Over- speed
Warning
• Curved roadway
with tight turns,
including off- ramps
• Collisions are
caused by vehicles
moving too fast into
the curve
• Collisions can be avoided if
drivers are given alerts in a time
frame that allows them to make
cautious approach before
reaching the curve
• Drivers benefit by an elevated
sense of safety and comfort
from the alerts even if the
drivers can take timely, evasive
actions without the alerts
• Same as above
Work Zone Ahead • Reduced- speed
segments due to
work zone
• Road
reconfigurations due
to work zone
• Some collisions are
caused by vehicles
moving too fast into
slow traffic in work
zone
• Other collisions are
caused by changes
in traffic patterns
due to work zone
configurations
• Collisions can be avoided if
drivers are given alerts in a time
frame that allows them to make
cautious approach before
reaching work zone
• Drivers benefit by choosing
alternative routes if alerts are
given early enough for them to
exit and to avoid problematic
areas
• Drivers benefit by an elevated
sense of safety and comfort
from the alerts even if the
drivers can take timely, evasive
actions without the alerts
• Drivers provide
favorable assessment
of the alerts
• Drivers respond
positively and
noticeably to the alerts
• Drivers reduce speed
earlier or more
significantly with the
alerts than without the
alerts
• Drivers make lane
change maneuvers to
other lanes to avoid
work zone
• Drivers change routes
to avoid work zone
21 of 21
Notification of
Incident On Route
• Potential slow traffic
or congestion
induced by incidents
• Some collisions are
caused by vehicles
moving too fast into
slow traffic in
incident- induced
congested areas
• Other collisions are
caused by stressed
traffic conditions
• Other collisions are
caused by changes
in lane
configurations or
traffic patterns
• Collisions can be avoided if
drivers are given alerts in a time
frame that allows them to make
cautious approach before
incident segments
• Drivers benefit by choosing
alternative routes if alerts are
given early enough for them to
exit and to avoid problematic
areas
• Drivers benefit by an elevated
sense of safety and comfort
from the alerts even if the
drivers can take suitable actions
without the alerts
• Drivers provide
favorable assessment
of the alerts
• Drivers respond
positively and
noticeably to the alerts
• Drivers reduce speed
earlier or more
significantly with the
alerts than without the
alerts
• Drivers make lane
change maneuvers to
other lanes to avoid
incident areas
• Drivers change routes
to avoid incident areas
Notification of
Non- recurrent
( unexpected)
Congestion On
Route
• Congestion caused
by all probable
causes unexpected
by users
• Some collisions are
caused by vehicles
moving too fast into
congested areas
• Other collisions are
caused by stressed
traffic conditions
• Other collisions are
caused by changes
in lane
configurations or
traffic patterns
• Collisions can be avoided if
drivers are given alerts in a time
frame that allows them to make
cautious approach before
congested segments
• Drivers benefit by choosing
alternative routes if alerts are
given early enough for them to
exit and to avoid problematic
areas
• Drivers benefit by an elevated
sense of safety and comfort
from the alerts even if the
drivers can take suitable actions
without the alerts
• Drivers will prefer to
receive alerts about
non- recurrent
congestion only
• Recurrent congestion
if issued frequently
will appear to be
nuisance therefore
result in negative
feedback
• Drivers provide
favorable assessment
of the alerts
• Drivers respond
positively and
noticeably to the alerts
• Drivers reduce speed
earlier or more
significantly with the
alerts than without the
alerts
• Drivers make lane
change maneuvers to
other lanes to avoid
congested areas
• Drivers change routes
to avoid congested
areas
Stop Sign Alert • Stop sign at off
ramps or on local
streets
• Collisions are
caused by vehicles
moving too fast into
stop signs
• Collisions can be avoided if
drivers are given alerts in a time
frame that allows them to make
cautious approach before stop
signs
• Drivers benefit by an elevated
sense of safety and comfort
from the alerts even if the
• Drivers provide
favorable assessment
of the alerts
• Drivers respond
positively and
noticeably to the alerts
• Drivers reduce speed
earlier or more
22 of 22
drivers can take suitable actions
without the alerts
significantly with the
alerts than without the
alerts
There are a multitude of common elements given in the table above. They can be reorganized
into the charts below. The first chart is a diagram showing the suite of applications.
Figure 3- 2: Hypothesized Expected Outcomes of Safe- Trip 21 Safety Applications
Figure 3- 3: Expected User Responses and Safety Impacts of Safe- Trip 21 Safety Applications
3.1.5 Validation of Test Hypotheses
3.1.5.1 Safety Application and Expected Test Outcome
The previous section provides an overall description of the test hypotheses of the expected
outcome. In the course of the field tests, it is expected that user experience was evaluated and
Safe Trip 21
Networked Traveler
Safety Tests
Users expressed
positive experience
and provides favorable
assessment of field
tests
Users take tactical
actions, such as speed
reduction and lane
change, to mitigate the
potential hazardous
situations
Users take strategic
actions, such as route
changes, to avoid
passing through or
approaching hazardous
segment, such as work
zones or incident areas
Users are able to take
proper actions to avoid
collisions
Safe Trip 21
Networked Traveler
Safety Tests
Users benefit by having an
increased sense of awareness of
roadway hazards ahead
Users benefit by being able to
take cautious approach when
they encounter hazardous
situations
Collisions can be avoided with
users taking proper actions and
different vehicle trajectories
before reaching hazardous
locations
23 of 23
field data was collected to explore the user needs and preferences as well as design validity and
shortcomings of the safety applications. Therefore, experimental design of the field tests should
emphasize on the observations of user response, qualitatively and quantitatively, to establish the
foundation for making such assessment.
The diagram below shows the expected cause- and- effect sequence in the process of experimental
designs. The top layer is the planned safety field tests. The second layer is the applications to be
deployed. The third layer is expected user actions, if safety alerts are effective. The fourth layer
is the expected observable outcome, as a result of the safety field tests.
Figure 3- 4: Safe- Trip 21 Safety Applications and Observable Outcome
3.1.5.2 Functional Processes and Operating Constraints
Before discussing further the necessary data collection and the availability of observable data to
validate the test outcome, it is critical to point out the constraints of the data acquisition process
within the context of the planned field tests.
3.1.5.2.1 Functional Process of Safety Applications
The Networked Traveler project is based on the concept of utilizing existing technologies that
are currently available to consumers, such as GPS- enabled smart phones and personal digital
Networked Traveler
Safety Tests
Slow Traffic
Ahead
Curve Over-
Speed
Work Zone
Ahead
Incident and
Congestion
Notification
Stop Sign
Ahead
Favorable User
Experience
Tactical Actions
by Users
Strategic Actions
by Users
Positive feedback
in questionnaire
and surveys
Routing changes
or alternative
modal choices
made by users
Reduction in
collisions
Speed reduction
or lane change
maneuvers made
by users
24 of 24
appliance. The communication links may include 3G, Wi- Fi, and DSRC. The current set up
envisioned for the planned tests can be described as follows:
( 1) Users register for the service.
( 2) Users enter origin and destination for the intended trip.
( 3) Users activate services by choice and by preference.
( 4) Once activated, the user’s route and personal preference information are communicated to
the system server.
( 5) System server receives traffic speed and incident information for the whole test area ( San
Francisco Bay Area similarly covered by the 511 services).
( 6) System server offers routing suggestions to users and monitor user positions by receiving
users’ current positions periodically.
( 7) System maintains and updates traffic, incident and relevant information for the entire test bed
area and executes safety algorithms for individual users based on their current positions and
speeds.
( 8) If any condition on a user’s route warrants the issuance of safety alerts, the system server
issues and sends an alert to the users; alerts are presented to users in auditory forms while
routing information is available in both visual and auditory forms.
3.1.5.2.2 Constraints in Data Acquisitions
The following constraints in both quality and quantity of data acquisition should be noted:
( 1) System server received traffic and incident information from other sources ( Traffic. com
and SpeedInfo); therefore the update rate and the quality of traffic data are not within the
control of the application developers.
( 2) Traffic information are only available for designated segments and specific locations in the
test bed area, therefore the measurements of background traffic settings are not available
continuously in time or in space.
( 3) In this pilot test, only 13 locations are considered for “ slow queue ahead” applications.
Even though sensors was installed to capture the traffic conditions at these locations, they
can mostly provide traffic speed measurements for a specific site or a short segment for the
selected locations, and may not entirely reflect the actual representation of traffic
parameters for ideal and robust processing and execution of alert generation algorithms.
( 4) Users may or may not activate safety functions even if they volunteer and register for the
services.
( 5) Users may choose to activate selective functions of their preferences and thus only a subset
of functional results and associated data are available for individual users.
( 6) User positions are only available through the GPS coordinate on user’s devices, and
therefore the accuracy and availability of user trajectory ( speed and position) depend on the
GPS units and the settings of driving environment, which may vary significantly along
users’ routes.
( 7) There is no measurement about the movements of surrounding vehicles, which may have
impacts on the driver actions when alerts are issued. Therefore, the causal effects of driver
actions in response to alerts may not be determined.
( 8) There is only limited information about the traffic conditions at test sites. For example, in
the “ slow- queue- ahead” scenarios, only the average speed of existing traffic queue is
available to be used as a criterion in alert- generation algorithms. Therefore, insufficient
25 of 25
description of the actual traffic settings may not explain whether drivers can positively
respond to the alerts.
( 9) There are multiple variables involved in the causation of collisions, including driver
( fatigue, distraction, incorrect judgment, etc.), environment ( visibility, roadway surface
conditions, weather, etc.). A significance depth and broad spectrum of these related
parameters are not available for assessment for this pilot test. This, it should be reiterated
that this pilot test is only targeting and designing for a limited subset of situational
awareness scenarios.
( 10) The pilot test is further constrained by the fact that alerts are communicated to users
through user interface implemented within the capabilities and flexibility allowed by the
phone- based devices.
3.1.5.2.3 Measure of Effectiveness
The planned field tests of the suite of safety applications is on a limited scale, and considered a
pilot test as it is to be carried out within a limited period of performance ( for the year of 2009)
and scope. However, it is still important to establish the framework and methodology to conduct
the system assessment toward the end of the pilot test so that effectiveness and usefulness of
safety applications can be properly measured.
Having discussed the limitations of the planned tests in the previous section, it can be further
explored about the data to be collected and how they can be analyzed and investigated to assess
the effectiveness of the suggested applications. The following table illustrates how a matrix of
measure of effectiveness can be constructed.
Table 3- 2: Anticipated Test Outcomes and Measure of Effectiveness
Expected Test
Outcome and
Driver Responses
Measures of Effectiveness
( MOE)
Parameters and Variables to Assess
MOE
• Spectrum of project
partnerships
• List of partners in project
• Scope of participation by partners
• List of participating organizations
outside of project team
• Scope of community
participation
• Number of participating users
• Number of data samples collected in
field tests
• Percentage of positive feedback by
users
Public awareness of
safety campaign
• Outreach efforts • Sessions of activity reports held in
public forums and conferences
• Technical papers presented
• Reports of media events
26 of 26
• Willingness to
participate and to
maintain continual use
of applications
• Number of participating users
• Periods of active usage
• Continuity and frequency in activating
applications
• Percentage of positive feedback by
users
Favorable user
experience and
positive user
feedback
• User feedback to
surveys and
questionnaire on
- Function usefulness
- Function
acceptability
- Timeliness of alerts
- User interface
friendliness
• User answers in surveys and
questionnaires ( to be detailed and
designed later)
• Correctness and
reliability of alert
generation
• Numbers of alerts generated
• Percentage of valid alerts
• Conditions of false alerts ( time of day,
incident type, congestion status, travel
time)
• Timeliness in alert
issuance
• Total latency in alert reception time
versus design point in algorithms
• Conditions of time lags ( time of day,
incident type, congestion status, travel
time)
• User feedback in real time or in surveys
Strategic actions
( routing changes or
modal choices) by
users
• User routing changes
after alerts are issued
• User choices of modal
changes after alerts are
issued
• Route records captured before and after
alert issuance
• User inputs or responses upon reception
of alerts
• Percentage of user responses
• Percentage of confirmed and verified
user responses
- based on user real- time feedback
- based on user surveys
• Conditions of alert issuance ( time of
day, incident type, congestion status,
travel time)
• Timeliness in user
response actions
• Noticeable trajectory changes ( to be
analyzed and defined later according to
27 of 27
field GPS data resolution and fidelity)
in time versus alert issuance point
• Driver reaction time comparison to
total latency in alert generation
• Conditions of alert issuance ( time of
day, incident type, congestion status,
travel time)
• Correctness and
reliability of alert
generation
• Numbers of alerts generated
• Percentage of valid alerts
• Conditions of false alerts ( time of day,
speed differential, congestion status)
• Timeliness in alert
issuance
• Total latency in alert reception time
versus design point in algorithms
• Conditions of time lags ( time of day,
speed differential, congestion status,
incident type)
• User feedback in real time or in surveys
• User speed reduction
after alerts are issued
• Speed change maneuvers captured
before and after alert issuance, for at
least a 60- second time window before
and after
• Speed variations in time segments
within the data window
• Magnitude of speed change in various
time segments
• Percentage of speed reduction
responses
• Percentage of confirmed and verified
user responses
- based on user real- time feedback
- based on user surveys
• Conditions of alert issuance ( time of
day, congestion status, travel time,
incident type)
Tactical actions
( speed reduction
and/ or lane change
maneuvers)
• User lane change after
alerts are issued
• Lane change maneuvers captured
before and after alert issuance, for at
least a 60- second time window before
and after
• Trajectory variations in time segments
within the data window
• Percentage of lane change responses
• Percentage of confirmed and verified
28 of 28
user responses
- based on user real- time feedback
- based on user surveys
• Conditions of alert issuance ( time of
day, congestion status, travel time,
incident type)
• Timeliness in user
response actions
• Noticeable trajectory changes ( to be
analyzed and defined later according to
field GPS data resolution and fidelity)
in time versus alert issuance point
• Driver reaction time comparison to
total latency in alert generation
• Conditions of alert issuance ( time of
day, congestion status, travel time,
incident type)
Collisions avoided
and reduced
Reduction in
• Collision frequency
( per counts of
collisions) for
individual site or
collision types
• Collision rate ( per
vehicle- mile traveled)
for individual sites or
crash types
• Collision reports
• Cumulative counts of collision numbers
at specific sites and particular types
• Realistically difficult to observe in
short time spans due to data stability
and non- deterministic causal factors
3.1.6 Data Collection and analysis
3.1.6.1 Application Field Test Schedule
Table 3- 3 provides a list of milestones and targeted applications for this phase of Safe Trip 21
field deployment tests.
Table 3- 3: ST- 21 Networked Traveler Field Test Initial Milestones
Milestone Date Rollout Functionality Precipitating Events
15 March ‘ Slow traffic ahead’ from
NAVTEQ Traffic / 511
Note: Maximum leverage of
World Congress Trip
Planner ( PATH, Univ. of
Utah, NAVTEQ
components)
100s drivers recruited –
1. If expedited CHPS
approval not completed:
pilot subjects ( 100s)
2. If expedited CHPS
approval completed:
SFTMA, AAA, Stanford
Commuter Club, MTC
29 of 29
( listed in order of
probability)
15 April Add: SpeedInfo and ID’d
high concentration locations
100s drivers recruited –
1. Expedited CPHS
approval expected.
2. SpeedInfo completes
their already- committed
support.
15 June Add: Feedback and learning 100s drivers recruited –
Full- featured.
3.1.6.2 User Recruiting
We will recruit users in three phases, several hundred per phase ( early Spring, late Spring, early
Summer), by working with management from four organizations:
• SF Transportation Management Association
• Metropolitan Transportation Commission
• AAA ( Northern California Automobile Association) and
• Stanford Commuter Club ( given in order of priority in recruitment).
Each user was required to have a cell phone and an unlimited data plan. We will also recruit
drivers sign up ad hoc to our webpage and wish to download the client application. The targeted
number of users is in the range of 500- 1000 at this planning stage. However, it should be noted
that since this project offers no monetary compensation for participants, other than the incentive
of providing a potentially useful applications for interested users, the actual number of users is
difficult to predict and control.
3.1.6.3 Data Collection Period
As outlined in the application rollout schedule and milestones above, the safety applications was
made available in late spring. Corresponding to this schedule, the data collection was
implemented in several stages:
3.1.6.3.1 Quantitative Data
( 1) Collection of baseline data
After the initial installation and activation of field test functions, typical routes and user
experience was captured to establish the baseline data without the activation of safety alerts. This
step is taken to ensure the applicability of GPS data in the functional algorithms with virtual
alerts generated along the typical routes taken by each user. The baseline data was used in later
stage of data analysis to examine the probable effects of safety applications after they are
activated.
30 of 30
For users who take regular commute routes or follow consistent driving patterns, the four- week
period should provide a sample of approximate 20 data points for each user at specific sites, such
as those intended for Application “ Slow traffic ahead” or “ Curve over- speed alert”. For other
applications, such as notification of incident or congestion or work zone, the number of data
samples could be 3- 10 times greater, depending on the actual traffic conditions. Note, however,
the alerts may not be generated each time the users pass through the designated locations or
where incidents or work zones are present, therefore, the sample sizes may be reduced
substantially. For those occasions when no alerts are warranted, the driving records was kept as
the baseline data for normal driving conditions.
This period of baseline data verification is expected to continue for 4 weeks, or until a valid
sample of data points are established.
( 2) Collection of user data in response to safety applications
After the initial validation period, the data collection will continue as long as the user opts to
activate the functions in his driving routines. If a user signs up in the early stage of field test, the
data collection period can go on for 5- 6 months before the conclusion of the field tests. If the
data collection is continuous and un- interrupted, then the numbers of data samples are expected
to be 5- 6 greater than the validation period.
For users who pass through the specific sites daily, this will means an approximate sample of
100 data points for each user. For non- location specific applications, the sample size can be
several times greater. Note, however, the alerts may not be generated each time the users pass
through the designated locations or where incidents or work zones are present, therefore, the
sample sizes may be reduced substantially. For those occasions when no alerts are warranted, the
driving records was kept as the baseline data for normal driving conditions.
3.1.6.3.2 User Survey and Questionnaire
( 1) User information at registration
All users are required to register when they sign up for the application services. In this
registration process, certain questions about the users was posed. Answers to some questions are
required, and others are optional. For example, to assess the coverage of user base, the driving
distance and zip codes for origins and destinations of regular routes was useful information to
have in this registration process. The detailed form of questions was provided later.
( 2) On- Line Feedback
Users was given the option of providing anytime feedback on problems encountered in the use of
the applications as well as desired changes or suggestions on the applications that are offered.
( 3) Mid- term Survey
Three months into the initial use of the field tests, each user was required to go through a web-based
survey. This survey was an initial assessment of user experience on the safety applications.
( 4) Final Survey
One month before the project is concluded, users was asked to go through another survey. This
was another milestone to assess the user experience as well as to observe any noticeable changes
31 of 31
in user experience after exposure to the applications for an extended period. After the final
survey, unless the user opts to discontinue the service, data will continue to be collected, which
may be valuable for later evaluation of the field tests.
3.1.6.4 Types of Quantitative Data
The system server, where the monitoring of traffic conditions and alert generation algorithms are
executed, will continuously capture available data streams to facilitate later data analysis. The
types of data that can potentially be collected include the following:
• Time of alerts issued
• Traffic and incident Status that trigger the activation of alerts, such as
o Traffic speed variations in space and in time at the point of alert generation
o Incident type and severity
o Congestion status or travel time through congested segments
o Distance from user location to incident location
• Contents of alerts presented to users
• Driver response to alerts
o Real- time voice commands response to alerts
o Delayed online submission of user feedback
• Trajectory data ( GPS) of users before, during, and after alerts, from which additional data
may be derived:
o Post- alert braking or lane- changing responses
o Speed variations in space and in time before, during, and after alert reception
3.1.6.5 Types of Qualitative Data
Qualitative data to assess user subjective experience of the applications was collected through
surveys and online feedback. The types of data that can potentially be collected include the
following, but the exact form and questions of survey was developed later:
• Overall impression of applications
o Usefulness
o Timeliness
o Reliability
o Issues or problems in using applications
• Driver background information
o Age
o Gender
o Familiarity or experience with smart phones
o Driving distance daily or weekly
• Driver experience with specific applications
o Number of alerts received daily or weekly
o Perceived value of individual applications
o Specific problems encountered with individual applications
3.1.6.6 Data Analysis
The purpose of data collection and analysis is several- fold:
32 of 32
( 1) To assess the effects of intended applications on users,
( 2) To provide supporting evidence in determining the extent of success in project objectives,
and
( 3) To explore the weakness and shortcomings of implemented functions for future
improvements
3.1.6.6.1 Quantitative Data Analysis
The quantitative data captured during the field tests was grouped and categorized to allow the
determination of user responses.
The assessment should be performed for both the individual application and system as a whole.
The elements of data analysis should include:
• Number of alerts generated
• Distribution of alert generation with traffic conditions:
o Time of day
o Speed differentials
o Congested state ( estimated travel time delays)
o User speed
o Speed differential
o Distance of user location versus incident location
• Correlation of alert provision with user responses:
o User baseline or normal driving conditions
o Variations in driver trajectory
o Statistical verification of behavior changes by comparison of before and after user
experience
o Exploration of functional forms representation of selective driver responses in
terms of meaningful explanatory variables
o Determination of critical variables on driver behavioral changes
3.1.6.6.2 User Response Data
In order to verify the statistical significance of data representation, several critical data elements
must first be scrutinized.
( 1) Validity of using GPS data for monitoring user trajectory
The GPS data is phone based and not vehicle mounted, therefore the trajectory traces
expressed by the GPS unit do not fully reflect the vehicle actions. The data gathering process
is further complicated by the resolution and accuracy of GPS data. Thus, several steps can be
taken to evaluate the usage of such data:
• Preliminary laboratory and field tests can be performed to collect sample data sets for
initial evaluation
• If necessary, filtering and data processing techniques can be applied to improve the
usability of such data.
• A large sample of data sets wascome available after the first roll- out of applications. At
that stage, certain roadway segments ( tunnels or valleys) of the highway network was
33 of 33
discovered to have data issues. These data sets can be excluded from data analysis.
( 2) Use of GPS data and user actions of tactical maneuvers such as speed change and lane
change in response to alerts
Depending on the conditions of alert issuance, the users may or may not take immediately
noticeable actions. For short- time frame alerts such as slow traffic queue ahead, the user
response is unknown but expected within 60 seconds. For other applications, the time
horizon is much longer, and the Therefore, one approach for dissecting the user follow- up
actions is as follows:
• Continuously monitor the user trajectory for 60 seconds prior to the alert and right after
the alert
• Divide the observation time window into multiple time segments
• Computer the speed differential or lane- change maneuvers within each time segments
• For evaluation of all users,
o Computer the average and standard deviations of speed changes in each time
segment
o These variations are then compared to the baseline of all users
o Statistical significance tests can be performed to determine if the variations in
trajectory is meaningful at different time windows after the issuance of alerts
• For evaluation of individual users, if sufficient data samples exists,
o Computer the average and standard deviations of speed changes in each time
segment
o These variations are then compared to the baseline of individual users
o Statistical significance tests can be performed to determine if the variations in
trajectory is meaningful at different time windows after the issuance of alerts
( 3) User response evolution over time
At this planning stage, it is difficult to estimate whether sufficient data points was collected
for individual users to evaluate their progressive acceptance and thus differences in response
to the alerts. If such data become available for selective users, it was possible to examine
their response in different stages over time.
3.2 Estimation of Sample Size
3.2.1 Problem Description
Sample size, in the context of this report, refers to the number of observations that are targeted
for the evaluation of safety field experiments to be conducted for the Networked Traveler
project. For this study, we are interested in assessing the outcome of experiments measured by
the responses of users in reaction to the safety alerts. The required number of samples that allow
statistically meaningful evaluation of experimental outcome depends on a number of parameters,
including population size, confidence levels, statistical power desired, and the distribution of
outcome variables.
3.2.2 Population Size
In the intended experiments, the population size means the total number of users who are
exposed to the traffic conditions during their travel on a test site where there exists a traffic
34 of 34
situation warranted for the issuance of alerts. An exemplar calculation of the population size is
suggested as follows.
In the networked Traveler experiments, the safety alerts are applicable to a fraction of the driving
population passing through a specific test site during the daily rush hours. The capacity of a
freeway lane during the peak hours is normally between 1,500 and 2,000. Let us further assume
that only 10% of the driving public is exposed to situations that warrant the issuance of alerts.
This will amount to approximately 500 to 1,000 cases for each day or 10,000 to 20,000 per
month. Over a 9- month test period, the total population size was in the range of 100,000 to
200,000. Our intent is then to define the necessary sample size or number of observations that
was sufficient for us to assess the outcome of the safety application for this particular test site.
If the safety application is applicable to a larger fraction of the driving public, thent eh
population size was much greater. For example, for all moving traffic a few miles upstream of a
congested area or a work zone, the situation was generally applicable to traffic across multiple
lanes.
As was seen in later discussions, the sample size becomes stabilized and does not change
significantly when the population size increases to a relatively large number. For the illustration
of sample size calculation, a large number was used in this document to derive a conservative
estimation of sample size.
3.2.3 Experimental Outcome Variables and Their Distribution
The sample size calculation is a function of the types of variables and associated distribution of
these variables. For example, we was interested in whether users will respond positively to a
survey of the usefulness of an alert. The sample size needed for a dichotomous outcome ( yes or
no response) will depend on the expected distribution or ratio of positive and negative answers
and the statistical parameters that are chosen. Examples are provided in a section below.
If the experimental outcome is a continuous variable, then similarly the sample size was affected
strongly by the distributions of such variables. For example, after a safety alert is issued, we was
interested in whether the user takes actions to reduce speed within a defined time window. For
such evaluation, we was comparing the “ before” and “ after” behaviors of the users under similar
situations. The “ before” data are from the baseline data that are collected without the activation
of alerts, while the “ after” data are cases when alerts are provided to users. The change in speed
will vary by individual users as well as by the corresponding traffic conditions. If the expected
change in speed is a random sample with independent observations, then it can be assumed that a
large population of such samples will approach a normal distribution. For the examples of
sample calculation given in a section below, a set of normalized parameters, including the mean
difference between before and after and the standard deviation, are used to show how samples
sizes vary according to the chosen statistical parameters.
3.2.4 Sample Size and User Base
Multiple safety applications, including work zone, incident notification and curve over- speeding,
are planned in the field experiments. The observations or the samples for specific applications
should be categorized and separated for the purpose of evaluation as it can be expected that user
35 of 35
responses to different applications can vary. For the alert- generation scenarios that are applicable
to a wide area or a large of sites on different freeways, such as incident or work- zone
notification, it can be expected that the required sample sizes can be reasonably achieved.
Therefore, the challenge lies in the collection of sufficient observations for more restrictive, site-specific
cases that are applicable to particular traffic conditions.
The current projected number of users to be recruited for the field experiments is in the range of
several hundreds to one thousand. For most scenarios as illustrated in the section below, the user
base should meet the targets of required sample sizes. It was noted, however, that there is no
direct association of user pool size and the number of observations because the issuance of alerts
depend on the traffic conditions at the time when the users pass through the test sites. Therefore,
it remains to be seen how significantly large the number of observations can be collected for a
selective subset of the intended applications.
Expected User
Response and
Safety Effects
Assumptions Sample Size
1. Drivers
provide
favorable
assessment of
the alerts
1. Dichotomous ( Yes/ No) Outcome
2. Margin of error = 5 %
3. confidence level = 95 %
4. Population size= 200000
5. Response distribution= 50 %
385
1. Dichotomous ( Yes/ No) Outcome
2. Margin of error = 5 %
3. confidence level = 95 %
4. Population size= 200000
5. Response distribution= 50 %
2. Drivers 385
respond
positively and
noticeably to
the alerts
1. Continuous Outcome( reaction to
notice and response ( two different
outcomes))
2. α ( Type I error probability)=
0.1,0.05,0.1,0.001
3. δ( the mean difference of the pairs)= 0.5
4. Power= 0.8
5. σ ( standard deviation)= 3
alpha power
0.6 0.7 0.8 0.9
--------------------------------------------
0.1 131 171 225 310
0.05 179 224 286 381
0.01 292 349 426 540
0.001 458 529 622 759
1. Continuous Outcome
2. α ( Type I error probability)=
0.1,0.05,0.1,0.001
3. δ( the mean difference of the pairs)= 0.5
4. Power= 0.8
5. σ ( standard deviation)= 3
alpha power
0.6 0.7 0.8 0.9
--------------------------------------------
0.1 131 171 225 310
0.05 179 224 286 381
0.01 292 349 426 540
0.001 458 529 622 759
3. Drivers
reduce speed
earlier or more
significantly
with the alerts
than without
the alerts
1. Dichotomous( Yes/ No) Outcome
2. margin of error = 5 %
3. confidence level = 95 %
4. population size= 200000
5. response distribution= 50 %
385
4. Drivers
make lane
change
maneuvers to
1. Dichotomous( Yes/ No) Outcome
2. margin of error = 5 %
3. confidence level = 95 %
4. population size= 200000
385
36 of 36
3.2.5 Sample Size Table
The table above provides exemplar sample size calculations. Further explanations of parameters
are provided in sections below.
3.2.6 Explanation of Parameters
3.2.6.1 Dichotomous Outcome
a) The margin of error is the amount of error that one can tolerate. If 90% of respondents
answer yes, while 10% answer no, one may be able to tolerate a larger amount of error than if the
respondents are split 50- 50 or 45- 55.
Lower margin of error requires a larger sample size.
b) The confidence level is the amount of uncertainty you can tolerate. Suppose that we have 20
yes- no questions in a survey. With a confidence level of 95%, we would expect that for one of
the questions ( 1 in 20), the percentage of people who answer yes would be more than the margin
of error away from the true answer. The true answer is the percentage we would get if we
exhaustively interviewed everyone.
Higher confidence level requires a larger sample size.
3.2.6.2 Continuous Outcome
a) Description: Pair wise analysis is when we do two measurements on a single sample and then
compare the outcome of the two measurements. Mostly a time factor is involved, a measurement
is done, something " happens", an " intervention" for example, after which the measurement is
done again. In this case, the “ before and after alert” speed measurements are compared.
b) Distribution: In the case of speed means or averages, the speed for each individual before
alert is subtracted from the speed measurement after the alert is issued. These differences are for
all individuals added together producing a mean difference ( δ) with an associated standard
deviation ( σ). Our null hypothesis is that the average is zero; overall ( in net terms) the
respondents did not change the speed. The sample size calculated is the sample size required to
detect a postulated net change over all individuals. The expected mean difference, or net change,
for all individuals and the associated standard deviation are assumed as given in the table. A
sample size for the paired t- test is then calculated.
3.2.7 Technical Basis of Equations used
For calculating the sample size for dichotomous outcome, the following equation is used:
The sample size n and margin of error E are given by
x = Z( c/ 100)
2r( 100- r)
n = N x/(( N- 1) E
2
+ x)
E = Sqrt[( N - n) x/ n( N- 1)]
37 of 37
where N is the population size, r is the fraction of responses that we are interested in, and Z( c/ 100)
is the critical value for the confidence level c.
The assumptions made while using the above equation are:
1. The number of positive responses follows a normal distribution.
2. The above calculation assumes that you have more than about 30 samples.
3. The population size is assumed to very large.
A similar statistical example has been explained below.
Suppose that we was required to construct a 95% confidence interval for the proportion so that it
will have a 5% length of confidence interval. What sample size would be required?
A conservative estimate of the standard error of the sample proportion is . Since the
length of the confidence interval should be 5 %, the 95 % confidence form for the proportion
would take the form
Sample proportion
As the confidence interval is 95 %, the area required ( in the above diagram) .95+. 025= 0.975.
Using Normal Distribution Tables, the corresponding z- value is found as 1.96.
Let be the estimator of proportion. Then,
( - 1.96* , 1.96* ) is the 95% confidence interval. Hence it follows that,
1.96*( Estimate of Standard Error) = 0.025
Or equivalently
n= = 1537
The sample size calculation above assumes that the sample size is small relative to the
population size. If, however, we would like to incorporate a finite population correction
adjustment, then we would have to incorporate the following adjustment:
38 of 38
To determine the sample size needed for a simple random sample, obtain half the harmonic mean
of the population size and sample size calculated for a random sample with replacement.
The required sample size of 1537 can be adjusted by incorporating the population size. For a
village of 10,000 residents, we would have to obtain a sample of size:
=
For a town of 100,000 residents, the required sample size is:
=
While for a country of 70,000,000 residents, the required sample size would be:
=
This is same as that obtained for sampling with replacement. This numerical result explains why
nationwide polls typically use only 1500 to 2000 respondents. The important point to note is that
large population size has virtually no effect on the choice of the sample size.
3.2.8 Variation of Sample Size with respect to Different Parameters
3.2.8.1 Dichotomous Outcome
Figure 3- 5: Sample Size versus Margin of Error
39 of 39
This graph shows that sample size is more sensitive to the margin of error when the margin of
error is in the range of 0- 5 %. It also indicates that choosing margin of error greater than 10 %
does not give a conservative sample size. In order to have a conservative and large sample size,
the margin of error should be in the range of 0- 5 %.
Figure 3- 6: Sample Size versus Confidence Level
The graph above indicates that 90- 100% confidence interval yields a conservative sample size
range.
Figure 3- 7: Sample Size versus Response Distribution
40 of 40
The graph above shows response distribution of 50% yields the most conservative sample size.
Therefore, a response distribution of 50% is assumed when actual response distribution is
unknown.
Figure 3- 8: Sample Size versus Population Size
The graph above illustrates a fact that by increasing the population size greater than 10000 does
not produce significant change in the sample size. Therefore, it is reasonable to assume a large
population size when the actual population size is unknown.
In the present case, population size means the total number of drivers who are exposed to the
same traffic conditions during their travel on a specific site where there exists a traffic situation
calling for alerts. So, the population size is a fraction of AADT on a specific site.
3.2.8.2 Continuous Outcome
41 of 41
Figure 3- 9: Sample Size versus α ( Type I Error Probability)
The graph above explains that the sample size decreases as α increases. α indicates the
probability of rejecting a null hypothesis when it is actually true. Plainly speaking, it occurs
when we are observing a difference when in truth there is none. Therefore, it is obvious we
require large sample size to observe a small α.
Figure 3- 10: Sample Size versus Power ( 1- β)
The power of a statistical test is the probability that the test will reject a false null hypothesis
( that it will not make a Type II error). As power increases, the chances of a Type II error
decrease. The probability of a Type II error is referred to as the false negative rate ( β). Therefore
power is equal to 1 − β.
Therefore, higher power requires larger sample size. This is evident from the graph above.
Figure 3- 11: Sample Size versus δ ( Mean Difference of the Pairs)
42 of 42
The graph above indicates that in order to observe a small mean difference between the pairs, we
require a large sample size.
Figure 3- 12: Sample Size versus σ ( Standard Deviation)
Standard deviation is a simple measure of the variability or dispersion of a data set. A large
standard deviation indicates that the data points are far from the mean and a small standard
deviation indicates that they are clustered closely around the mean.
The graph above explains that a smaller sample size is required in order to maintain a smaller
standard deviation.
3.3 System Architecture
Multiple information systems was integrated with middleware software providing standardized
interfaces that was able to deliver information through a variety of mobile devices ( see Figure
3- 13).
43 of 43
Figure 3- 13: Networked Traveler System Architecture
The system architecture is formed of the client, residing on the cellular phone, the Networked
Traveler server, hosting several services to enable the required functionality listed above, and 3rd
party services that provide the real- time or semi- real- time data that is needed for the functionality.
Data exchange between these components is achieved through several mechanisms. At the lower
level the 3rd party components interact with the Networked Traveler Server through a backhaul
internet connection having the 3rd party servers as one end node on the Internet and the
Networked Traveler as the other node on the Internet. Communication between the Networked
Traveler Server and the Cellular Phone is achieved also over Internet communication protocols
enabled by a cellular data plan provided by any of the Cellular Network companies. At a higher
level of abstraction, data between the 3rd party servers and the Network Traveler Server is
exchanged either through XML, JSON or some proprietary protocol developed by the 3rd party.
Data exchange between the Networked Traveler Server and the Cellular Phone always occurs
through the JSON standard communication over HTTP.
3.3.1 Networked Traveler Server
The Networked Traveler Server serves two main functions: it fuses together the data that comes
from 3rd parties to host for the cellular applications, and it hosts the Networked Traveler website
which serves as the first entry point to the user’s experience of Networked Traveler and as a user
profile management center later on during the field test.
44 of 44
3.3.2 Cellular Phone
The cellular phone is the interface that provides the Networked Traveler services to the user and
collects user feedback.
On the client, two main functions exist ( See Figure 3- 14): Routing and Safety. The Routing
function solicits information from the user regarding their desired destination and route
preference. The Saftey function provides safety messages ( in- line with the functionalities
described above) related to the route defined by the routing function.
The Routing function converses with the Routing Service on the Networked Traveler Server to
obtain the route from the current location of the cell phone to the desired destination. The
Routing function also updates its route every set interval related to how the cell phone moves.
This ensures that the client application is constantly aware of where the user is headed.
Figure 3- 14: Cellular Phone Client Architecture
The Safety function runs two main processes. The first process communicates with the
Networked Traveler Server to obtain the most recent safety information regarding the route the
user is on. This information is cached on the client and refreshed every 30 sec. This mechanism
ensures that any communication timeouts along the way would not result in system crashes. The
second process runs every 2 sec and checks the current location of the client by requesting the
GPS coordinates from the cellular device and comparing that with the safety information
retrieved by the first process. In case of proximity of any of the safety information, and alert is
displayed and voiced to the user.
The proximity to safety information is different for each safety service. For the case of Slow
Traffic Ahead, the current cell phone location is compared to a “ trigger point” location on its
route. The “ trigger point” is a point defined 60 sec upstream the slowed traffic location ( as
retrieved from SpeedInfo sensors). If the client is within 1000 feet of the trigger location and
approaching at a speed 15 mph above the speed reported at the SpeedInfo location and alert is
issued.
45 of 45
Figure 3- 15 shows the full Networked Traveler user experience starting from registering on the
Networked Traveler website, downloading the client application to their cellular phone and using
the application while driving.
Figure 3- 15: Networked Traveler User Experience
3.4 Services
3.4.1 Routing
3.4.1.1 Background
With significant failure rates, existing in- pavement and road- side traffic sensors are typically
located on a small subset of freeway links, and accurate travel time and traffic flow information
on ramps and arterial corridors are critically needed but very costly to collect. In past several
years, in- car navigation and cell phone systems using the Global Positioning System ( GPS)
technology have matured into a rapidly growing industry and its penetration rate in the U. S. is
expected to exceed 9% in 2008. Recently, a new generation of commercial navigation system has
been successfully developed to provide two- way connectivity through a built- in Wi- Fi or cellular
connection, which allows a network of equipped drivers to anonymously share their speeds and
locations, obtain up- to- date traffic flow information, and more importantly make smart route
decisions.
The new generation of automobile navigation devices presents a data rich environment for
regional traveler information systems to accurately measure route- based travel times and
network- wide traffic flow distribution and evolution. It also offers an effective mechanism for
traffic management centers ( TMCs) to balance traffic on freeway and arterial corridors by
46 of 46
delivering precise en- route diversion guidance. On the other hand, utilizing mobile traffic probe
data, especially in their early deployment stage, could be constrained by low market penetration
rates, leading to small data samples in statistical inference and thus high variances in travel time
and network flow estimates. On the other hand, without fully integrating traffic management
strategies from TMCs, independent real- time drivers acting non- cooperatively might also affect
and even worsen the traffic conditions. By designing and implementing a mobile probe- based
traffic monitoring and information provision prototype system, this research aims to ( 1) provide
a web- based traffic visualization interface to end users ( i. e. transportation planners and travelers)
and ( 2) demonstrate potential benefits in increasing arterial street traffic observability and
eventually improving system- wide traffic conditions.
The objective of this task is to provide a prototype web- based traffic information provision
system to California PATH so as to receive input and feedback from the related users ( travelers
and transportation planners) regarding its interface and architecture. This task consists of two
subtasks.
3.4.1.2 Setup Web Browser
Web Browser
Please use Firefox 2 as your web browser.
Firefox 2 can be downloaded from HTTP:// www. mozilla. com/ en- US/ firefox/ all- older. html
HTTP Address
HTTP:// 128.32.129.90/ map/ mapverajax1.8. html
3.4.1.3 Network Data Coverage
The New York network in the routing engine currently covers Brooklyn, Queens, Manhattan, Bronx and
Staten Island ( as highlighted in Figure 3- 16). Paths cannot be found for origins and destinations outside
of this area.
Total mileage of road covered: 3,388 miles, 33,518 nodes, 55,123 links
The web- based Map 24 Interface is provided by NAVTEQ.
47 of 47
Figure 3- 16: New York network in the routing engine
48 of 48
Find Routes: Define Origin and Destination: To find routes, first left- click the mouse on the map to
define an origin point, and then left- click to define a destination point. The optimal routes for up to seven
criteria was shown on the map, as shown in Figure 3- 17.
Figure 3- 17: Optimal routes based on up to seven criteria
For each path, the corresponding travel time and travel distance are shown on the right.
3.4.1.4 Understand Different Criteria Used in Route Finding
Fastest path ( Yellow): the smallest travel time
Shortest path ( Blue): the shortest travel distance
Eco path ( Green): the average speed is close to eco- driving speed ( 50- 60 mph)
Avoid toll path ( Orange): no toll along the route or the lowest tolling fee
Safety path ( Red): the smallest probability of seeing/ being involved in a traffic incident
during the whole trip
Detour ( Black): highest travel time reliability
Park & Ride path ( Brown): use park & ride intermodal option
Remarks:
1) Different optimization criteria could lead to the same path.
2) Historical and live traffic data come from Traffic. com ( NAVTEQ)
3) Transit and tolling data come from MTA.
3.4.1.5 Check Dynamic Traffic along the Route ( through Check Boxes)
There are two check boxes associated with each path.
Click the left check box to highlight the selected path on the map,
Click on the right check box to show the time- dependent travel time profile and speed contour along
the selected path.
49 of 49
Travel Time Profile: The time- dependent travel time profile shows the travel time at different
departure times of day.
Traffic conditions along the route: The speed contour shows the traffic speed data collected from
road sensors along the selected path.
The X axis represents time of day.
The Y axis represents space along the path from A to B.
Color legend:
• Red: highly congested.
• Yellow: relatively congested.
• Green: free- flow.
• Blank/ White: no sensor data.
50 of 50
3.4.2 Slow Traffic Ahead Alert
3.4.2.1 Introduction
The primary safety- related service of the safety application is Slow Traffic Ahead Alert for
drivers. Networked Traveler’s client application runs on the phone and executes the following
major tasks:
• Reads GPS information ( position, speed, heading angle, etc) of the phone.
• Uploads the GPS samples to Networked Traveler’s server every few seconds ( 22 sec, in
the current version) via cellular data communications network.
• Server searches around location of the vehicle and if found relevant sends back to the
Client, a set of data related to slow traffic ahead alerts.
• Client uses the server data and if conditions satisfied, issues a slow traffic ahead alert to
the driver. The alert is both audio and visual and can be also delivered through Bluetooth.
3.4.2.2 Alert Logic
The alert logic is described below and also illustrated in Figure 3- 18.
Here are some definitions related to the alert logic:
• Subject vehicle: Vehicle that its driver is going to receive slow traffic ahead alert
• Alert location: Location ahead of the subject vehicle where traffic is slow
• Trigger location: Represented by GPS lat, long, and heading; about one mile ( 60
seconds of free flow speed) before the alert location. Alert is issued at or within 500 ft of
the trigger location.
Suppose:
• Vs = Speed of the subject vehicle
• Vf = Speed of the vehicles at the alert location
Alert is issued if all conditions below are satisfied:
1) Vf ≤ 50 mph
2) Vs – Vf ≥ 15 mph
3) Distance between trigger location and subject vehicle location ≤ 500 ft and
4) Difference between trigger location’s heading and vehicle’s heading ≤ 50 deg
51 of 51
Figure 3- 18: Slow traffic ahead alert logic
3.4.2.3 Coverage Area
We use two sources of traffic data: Navteq Traffic. com and SpeedInfo. In total, we have more
than 2000 trigger points in Bay Area, which they cover all major freeways.
3.4.2.4 Alert image
Figure 3- 19 shows the alert. The images take over entire screen of the phone. User may tap
anywhere on the screen to provide real- time feedback for the alert. As text below the slow traffic
ahead sign mentions, tapping the screen means user has found the alert to be not useful or
irrelevant.
52 of 52
Figure 3- 19: Image of the slow traffic ahead alert
3.5 Website
From mid- February to July 2009, NT- Safety developed the following web application to support
Phase I of the Networked Traveler - Safety launch. The basic functionality of the website was to
allow users to create a web- based user account which would:
1) Facilitate software download to the mobile phone,
2) Ensure users accept the Networked Traveler terms and conditions,
3) Visually identify specific alerts given to specific users, to enable qualitative feedback on
the alerts.
Figure 3- 20 shows screen shot of the account creation page. The first challenge was to provide
users a way to download the application to his or her mobile phone. We created a simple form
for users to fill out, including a unique username and password. Once a user had provided us
with his or her username, password, mobile phone number and carrier, we sent a text message to
the phone with a download link.
53 of 53
Figure 3- 20: Account creation page of the Networked Traveler website
Visual design was taken and adapted from the GEMS efforts demonstrated at ITS World
Congress in November 2008. The basic account creation was written in HTML and PHP, with a
MySQL database capturing the basic user data. The database was also adapted from tables
created in support of the GEMS web services efforts.
The user table was expanded after July, but most of the fields are as follows:
Field Type
uid int( 11)
login varchar( 20)
password varchar( 32)
appCategories varchar( 600)
terms varchar( 12)
gender varchar( 3)
age varchar( 10)
54 of 54
Though only a preliminary survey was written and deployed by July, it provided the
technological framework to collect the qualitative feedback of users. This supports the following
evaluation objectives set out in the SafeTrip- 21 California Connected Traveler Evaluation Plan:
1) Analyze the perceived timeliness, accuracy, and usefulness of safety alerts.
2) Explore the user- perceived benefits of the safety alerts.
The preliminary survey was an adaptation of questions posed in the experimental design
document dated Feb 8, 2009. The innovation was using Google Maps to visually identify the
alerts, and then tying alert- specific identifying data ( time, date, and user i. d.) to survey responses.
Figure 3- 21 shows an example of it. This enables a finer- grained and richer collection of data
than surveys which are not associated with particular events, though this method presents unique
challenges, too. The survey content was modified after July.
Figure 3- 21: Google Maps visualization of the alerts, with the informational popup
Although Google Analytics was added after July to collect usage statistics, page views,
completed downloads, etc., the basic site for which to collect these statistics was built in the time
period we’re discussing. The demographic survey to collect basic user demographic information
immediately after account creation was also implemented after July.
3.6 Outreach
Currently, the research team of the Networked Traveler Project is in active discussions with the
Metropolitan Transportation Commission ( MTC) and several associations of drivers ( e. g., CSAA
and the Transportation Management Association of San Francisco) within the San Francisco Bay
55 of 55
Area Region. Ideally, the field tests of this second service were conducted through full
integration of the traffic advisory incident data available from MTC’s 511 system. In any event,
as an important task initiated at the outset of this project and conducted in parallel to Task 1, we
aim to find up to 1000 drivers already owning appropriate GPS- equipped smartphones and
unlimited data plans.
3.7 Safety Benefit Feasibility Assessment
This section provides a description of the premise, hypotheses, rationale, and the approach for
conducting safety field tests, with the goal of assessing the validity and usability of the proposed
safety applications.
3.7.1 Premise
If drivers are better informed of the traffic conditions in their driving environment, they was
more aware and better prepared to take actions to avoid hazardous situations. Within the scope of
this study, we focus on the “ soft” safety applications that have a relatively longer time window to
provide drivers with alerts. A “ hard” safety application, by comparison, requires an immediate
action. For example, a system that warns drivers of imminent freeway front- end collisions with
another car in front will need to take effect within 1- 5 seconds. On the other hand, one example
of the “ soft” safety applications that we propose to offer is the situational awareness alert that
can be effective in a 10- 60 second time window. For example, in a situation where drivers cannot
see the slow or stopped traffic beyond a curved roadway ahead, at a distance of 1 mile or so
before the driver reaches at location, we can issue an alert to the driver especially when the
driver’s subject vehicle is traveling significantly faster than the traffic queue ahead.
3.7.2 Applications
A suite of applications are being considered and to be tested for the planned field experiments.
Most of these applications are designed for freeway driving conditions, which are the primary
test targets in this stage of the Networked Traveler project. The core list of safety applications
are given in Figure 3- 22, and they are explained and summarized as follows:
Figure 3- 22: Safe- Trip 21 Safety Applications
Safe Trip 21
Networked Traveler
Safety Field Tests
Slow Traffic Queue
Ahead
Notification of Incident Notification of Non-recurrent
Congestion
56 of 56
3.7.2.1 Situational Awareness of Slow Traffic Queues
The first application is a situational- awareness function that provides alerts to drivers on driving
conditions within a relatively short- latency time horizon, in the range of 10- 60 seconds. For this
application, we focus on specific highway locations where past traffic and crash patterns indicate
that a Networked Traveler system can offer useful alerts so that drivers can take tactical actions
to avoid crashes, or in essence increase their ‘ safety alert time horizon’ to beyond the just several
seconds based on driver reaction or provided by active safety systems. In these situations, by
offering a timely “ slow or stopped traffic ahead” message the system can effectively inform
drivers of roadway hazards to reduce chances of crashes and realize safety benefits.
To seek the test sites that may offer the most significant benefits for crash reduction, the research
team investigated the collision data for the last ten years for the greater San Francisco Bay Area
and identified sites where specific crash patterns might warrant the deployment of such
applications. A list of candidate locations, their attributes and maps are given in the following
sub- section.
Subsequently, it is reasoned that the “ slow traffic ahead” application can be extended to a much
broader network of highway spots where traffic speed can be detected. If the application user’s
vehicle speed is significantly higher than the speed of traffic stream ahead, then an alert may be
warranted. Therefore, through the collaboration with Metropolitan Traffic Commission ( MTC)
and two companies that provide real- time traffic information, SpeedInfo and Traffic. com, a
network with more than 2,000 nodes of traffic speed information is incorporated into a greater
area test bed to be included in the field tests of safety applications. Exemplar illustrations in a
sub- section below illustrate the distribution of these nodes in the Bay Area highway network.
3.7.2.1.1 Study Sites with specific patterns of crash concentration that warrant situational
awareness alerts
This section contains the list ( Table 3- 4) and maps of candidate sites currently being considered
for Safety Application # 1.
Note: Nomenclature in the tables below:
• B: Northbound; SB: Southbound; EB: Eastbound; WB: Westbound
• PM: Post Mile as defined in California Highway Database on a certain route within a
county
57 of 57
Figure 3- 23: Area Wide Map of Potential Study Sites Locations
Table 3- 4: Candidate Sites for Field Tests of Safety Application “ Slow Traffic Ahead”
Site
No.
Site Location Site Characteristics Type of Situation
Awareness
1 Alameda County
SR- 13, NB
PM 9.5
 Limited line of site to
sections ahead of curve
 Slow queue ahead due to
off- ramp backup into
mainline
 Slow traffic ahead on
right lane due to
bottleneck
 Slow traffic after curve
2 Alameda County
SR- 13, SB
PM 9.25
Broadway Terrace
Off- Ramp
 Severe fish- hoop off- ramp
 Combined with a stop and
traffic light at end of ramp
 Curve over- speed
 Queue at off- ramp
3 Alameda County
I- 880, SB
PM 27.5
 Combined vertical and
horizontal curves
 A merge of high- street
entry ramp and mainline
prior to curve
 Congestion in rush hours
 Slow traffic after curve
4 Alameda County
I- 880, NB
 Off- tramp bottleneck with
backup into right lane of
 Slow traffic ahead on
right lane due to
58 of 58
PM 19.4
Connector to SR- 238
mainline traffic bottleneck
5 San Francisco County
I- 280, NB
PM 1.5
Geneva Off- Ramp
 Off- tramp bottleneck with
backup into right lane of
mainline traffic
 Slow traffic ahead on
right lane due to
bottleneck
6 SR101 NB,
PM 4.2,
Mission & Dubose
off Ramp
 Traffic backing up in the
off ramp.
 Congestion
 Traffic Weaving
 Slow traffic due to
congestion
7 San Francisco County
US- 101, SB and NB
PM 4- 6
( Hospital Curve)
 Combined vertical and
horizontal curves
 Congestion bottleneck
 Traffic Weaving with on-and
off- ramp traffic
 Slow queue ahead
 Traffic Weaving
8 Santa Clara County
I- 880, NB
PM 4.2
Connector to US- 101
NB
 Frequent collisions with
K- rail barrier on left side
 Off- ramp curve
9 Santa Clara County
US- 101, SB
PM 32.9
Segment between
Tully Road and Story
Road
 Considerable traffic
weaving between two
exits in congestion periods
 Traffic Weaving
10 Santa Clara County
US- 101, NB
PM 18.0
Near Cochrane
Interchange
 Near 60% of collisions on
left lane
 Near Transition of 3- Lane
into 4- lane segment with
HOV lane on left
 On- ramp and off- ramp
nearby
 Lane Transition Traffic
Weaving
11 Santa Clara County
US- 101, SB
Tully Road EB Exit
 Speeding a major factor
( more than 75%)
 Rear- end Collision
dominate ( near 90%)
 More than 85% ramp
collisions at ramp exit and
cross street
 Slow queue ahead
 Ramp over- speeding
12 Santa Clara County
I- 280, NB
Wolfe Road Exit
 Limited line of sight to
ramp queue from mainline
 Signal controlled cross
street at ramp exit
 More than 90% ramp
 Slow queue ahead
 Ramp over- speeding
59 of 59
collisions at ramp exit and
cross street
13 Contra Costa County
I- 80, EB
PM 3.4
Segment between San
Pablo Ave and
Solano Ave Exits
 Combined vertical and
horizontal curves
 Congestion bottleneck
 Slow traffic ahead due
to bottleneck
 Traffic Weaving
3.7.2.1.2 Network of Traffic Speed Measurements Nodes Included for Safety Alert
Generation
The current version of Networked Traveler utilizes an area- wide real- time traffic data map that
includes more than 2,000 locations in the San Francisco Bay Area. Data feed comes from
SpeedInfo and Traffic. com and processed into a Networked Traveler server and is used to update
all calculations. Figure 3- 24 and Figure 3- 25 show exemplar displays of locations where traffic
data are available on freeways near San Francisco.
Figure 3- 24: An Illustrative Map of Mapped Locations with Real- Time Traffic Data Feed
60 of 60
Figure 3- 25: An Illustrative Map of Mapped Locations with Real- Time Traffic Data Feed
3.7.3 Notification of Incidents and Non- recurrent Congestion Ahead
One other application is the notification of incidents and non- recurrent congestion on the road
ahead to the drivers based on real- time traffic data. The major premise of this application of
“ Incident and Congestion Alert” is as follows:
( 1) First of all, drivers can stay informed of roadway traffic conditions, which allow them to
make trip planning choices. The information was “ pushed” to users based on their current
positions and travel routes.
( 2) Secondly, in congested areas on highways, various hazardous scenarios may develop and
lead to increased likelihood of collisions. With the proposed application, an earlier notification
alert to the drivers, in the range of 2- 30 minutes can offer drivers opportunities to take tactical
and strategic actions, including
• reducing speeds with increased awareness of slow traffic ahead
• choosing to change routes to avoid further trip delays
• changing transportation modes by switching to transit or travel plans, with benefits of
reducing traffic demands on flow- stressed or incident- impaired roadway segments can
effectively inform drivers of roadway hazards to reduce chances of crashes and realize safety
benefits.
61 of 61
3.7.4 Safety Applications Test Hypotheses
For each of the applications that are to be deployed for the field tests, the hypothesized outcome
and the expected user responses and the safety impacts are described and listed in Table 3- 5.
Table 3- 5: Safety Application and Test Hypotheses
Application Applicable Situations Hypothesized Outcome Expected Driver
Response and Safety
Effects
Slow Traffic Ahead • Traffic queues ahead
of curved roadway
with limited
visibility
• Collisions are
caused by vehicles
approaching too fast
toward the end of
slow traffic queue
• Collisions can be avoided if
drivers are given alerts in a time
frame that allows them to slow
down in advance
• Drivers can make cautious
approach before reaching end of
queue by receiving alerts
• Drivers benefit by an elevated
sense of safety and comfort
from the alerts even if the
drivers can take timely, evasive
actions without the alerts
• Drivers provide
favorable assessment
of the alerts
• Drivers respond
positively and
noticeably to the alerts
• Drivers reduce speed
earlier or more
significantly with the
alerts than without the
alerts
• Drivers make lane
change maneuvers to
other lanes to avoid
slow queue
Slow Traffic Ahead • Off- ramp queue
buildup and
spillover into
freeway
• Collisions are
caused by vehicles
approaching too fast
toward the end of
slow traffic queue
• Same as above
• Same as above
Slow Traffic Ahead • Severe traffic
weaving section
• Collisions are
caused by vehicles
sideswiping or rear-ending
other
vehicles are making
moving across lanes
in the weaving
section
• Collisions can be avoided if
drivers are given alerts in a time
frame that allows them to make
cautious approach before
reaching the weaving section
• Drivers benefit by an elevated
sense of safety and comfort
from the alerts even if the
drivers can take timely, evasive
actions without the alerts
• Same as above
Notification of
Incident On Route
• Potential slow traffic
or congestion
induced by incidents
• Some collisions are
caused by vehicles
moving too fast into
slow traffic in
incident- induced
• Collisions can be avoided if
drivers are given alerts in a time
frame that allows them to make
cautious approach before
incident segments
• Drivers benefit by choosing
alternative routes if alerts are
given early enough for them to
• Drivers provide
favorable assessment
of the alerts
• Drivers respond
positively and
noticeably to the alerts
• Drivers reduce speed
earlier or more
62 of 62
congested areas
• Other collisions are
caused by stressed
traffic conditions
• Other collisions are
caused by changes
in lane
configurations or
traffic patterns
exit and to avoid problematic
areas
• Drivers benefit by an elevated
sense of safety and comfort
from the alerts even if the
drivers can take suitable actions
without the alerts
significantly with the
alerts than without the
alerts
• Drivers make lane
change maneuvers to
other lanes to avoid
incident areas
• Drivers change routes
to avoid incident areas
Notification of
Non- recurrent
( unexpected)
Congestion On
Route
• Congestion caused
by all probable
causes unexpected
by users
• Some collisions are
caused by vehicles
moving too fast into
congested areas
• Other collisions are
caused by stressed
traffic conditions
• Other collisions are
caused by changes
in lane
configurations or
traffic patterns
• Collisions can be avoided if
drivers are given alerts in a time
frame that allows them to make
cautious approach before
congested segments
• Drivers benefit by choosing
alternative routes if alerts are
given early enough for them to
exit and to avoid problematic
areas
• Drivers benefit by an elevated
sense of safety and comfort
from the alerts even if the
drivers can take suitable actions
without the alerts
• Drivers will prefer to
receive alerts about
non- recurrent
congestion only
• Recurrent congestion
if issued frequently
will appear to be
nuisance therefore
result in negative
feedback
• Drivers provide
favorable assessment
of the alerts
• Drivers respond
positively and
noticeably to the alerts
• Drivers reduce speed
earlier or more
significantly with the
alerts than without the
alerts
• Drivers make lane
change maneuvers to
other lanes to avoid
congested areas
• Drivers change routes
to avoid congested
areas
There are a multitude of common elements given in the table above. They can be reorganized into the charts
below.
Figure 3- 26 is a diagram showing the safety applications may provide benefits in several
manners:
• Users benefit by having an increased sense of awareness of roadway hazards ahead
• Users benefit by being able to take cautious approach when hazardous situations are
encountered
• Collisions can be avoided with users taking proper actions and alter trajectories before
reaching hazardous situations
63 of 63
Figure 3- 26: Hypothesized Expected Outcomes of Safe- Trip 21 Safety Applications
In order to assess the benefits that are received by users, the hypotheses need to be verified
through the actions or responses from the users, including:
• Users express positive experience and provide favorable feedback of field tests
• Users take tactical actions, such as speed reduction or lane change, to mitigate the
potential hazardous situations
• Users take strategic actions, such as route changes, to avoid passing through or
approaching hazardous locations, such as incident areas.
• Users are able to take timely actions to avoid crashes
Figure 3- 27: Expected User Responses and Safety Impacts of Safe- Trip 21 Safety Applications
Safe Trip 21
Networked Traveler
Safety Tests
Users express positive
experience and provide
favorable assessment
of field tests
Users take tactical
actions, such as speed
reduction and lane
change, to mitigate the
potential hazardous
situations
Users take strategic
actions, such as route
changes, to avoid
passing through or
approaching hazardous
segment, such as work
zones or incident areas
Users are able to take
timely actions to avoid
collisions
Safe Trip 21
Networked Traveler
Safety Tests
Users benefit by having an
increased sense of awareness of
roadway hazards ahead
Users benefit by being able to
take cautious approach when
they encounter hazardous
situations
Collisions can be avoided with
users taking proper actions and
different vehicle trajectories
before reaching hazardous
locations
64 of 64
3.7.5 Validation of Test Hypotheses
3.7.5.1 Safety Application and Expected Test Outcome
The previous section provides an overall description of the test hypotheses of the expected
outcome. In the course of the field tests, it is expected that user experience was evaluated and
field data was collected to explore the user needs and preferences as well as design validity and
shortcomings of the safety applications. Therefore, experimental design of the field tests should
emphasize on the observations of user response, qualitatively and quantitatively, to establish the
foundation for making such assessment.
The diagram below, Figure 3- 28, shows the expected cause- and- effect sequence in the process of
experimental designs. The top layer is the planned safety field tests. The second layer is the
applications to be deployed. The third layer is expected user actions, if safety alerts are effective.
The fourth layer is the expected observable outcome, as a result of the safety field tests.
Figure 3- 28: Safe- Trip 21 Safety Applications and Observable Outcome
Networked Traveler
Safety Tests
Slow Traffic
Ahead
Incident
Notification
Congestion
Notification
Favorable User
Experience
Tactical Actions
by Users
Strategic Actions
by Users
Positive feedback
in questionnaire
and surveys
Routing changes
or alternative
modal choices
made by users
Reduction in
collisions
Speed reduction
or lane change
maneuvers made
by users
65 of 65
3.7.5.2 Data Collection Constraints
While the availability of observable data to validate the test outcome is essential for benefit
assessment, it is critical to point out the constraints of the data acquisition process within the
context of the planned field tests.
The following constraints in both quality and quantify of data acquisition should be noted:
( 11) System server received traffic and incident information from other sources ( Traffic. com
and SpeedInfo); therefore the update rate and the quality of traffic data are not within the
control of the application developers.
( 12) Traffic information are only available for specific locations in the test bed area, therefore
the measurements of overall corridor traffic settings are not available continuously in time
or in space.
( 13) Even though sensors were installed to capture the traffic conditions at these locations, they
can mostly provide traffic speed measurements for a specific site or a short segment for the
selected locations. It does not provide the information about the ending locations of traffic
queues and may not entirely reflect the actual representation of traffic parameters for ideal
and robust processing and execution of alert generation algorithms.
( 14) Users may or may not activate safety functions even if they volunteer and register for the
services.
( 15) Users may choose to activate selective functions of their preferences and thus only a subset
of functional results and associated data are available for individual users.
( 16) User positions are only available through the GPS coordinate on user’s devices, and
therefore the accuracy and availability of user trajectory ( speed and position) depend on the
GPS units and the settings of driving environment, which may vary significantly along
users’ routes.
( 17) There is no measured information about the movements of surrounding vehicles, which
may have impacts on the driver actions when alerts are issued. Therefore, the causal effects
of driver actions in response to alerts may not be determined.
( 18) There is only limited information about the traffic conditions at test sites. For example, in
the “ slow- queue- ahead” scenarios, only the average speed of existing traffic queue is
available to be used as a criterion in alert- generation algorithms. Therefore, insufficient
description of the actual traffic settings may not explain whether drivers can positively
respond to the alerts.
( 19) There are multiple variables involved in the causation of collisions, including driver
( fatigue, distraction, incorrect judgment, etc.), environment ( visibility, roadway surface
conditions, weather, etc.). A significance depth and broad spectrum of these related
parameters are not available for assessment for this pilot test. This, it should be reiterated
that this pilot test is only targeting and designing for a limited subset of situational
awareness scenarios.
( 20) The pilot test is further constrained by the fact that alerts are communicated to users
through user interface implemented within the capabilities and flexibility allowed by the
phone- based devices.
66 of 66
3.7.5.3 Measure of Effectiveness
Having discussed the limitations of the planned tests in the previous section, it can be further
explored about the data to be collected and how they can be analyzed and investigated to assess
the effectiveness of the suggested applications. The following table illustrates how a matrix of
measure of effectiveness can be constructed.
Table 3- 6: Anticipated Test Outcomes and Measure of Effectiveness
Expected Test
Outcome and
Driver Responses
Measures of Effectiveness
( MOE)
Parameters and Variables to Assess
MOE
• Spectrum of project
partnerships
• List of partners in project
• Scope of participation by partners
• List of participating organizations
outside of project team
• Scope of community
participation
• Number of participating users
• Number of data samples collected in
field tests
• Percentage of positive feedback by
users
Public awareness of
safety campaign
• Outreach efforts • Sessions of activity reports held in
public forums and conferences
• Technical papers presented
• Reports of media events
• Willingness to
participate and to
maintain continual use
of applications
• Number of participating users
• Periods of active usage
• Continuity and frequency in activating
applications
• Percentage of positive feedback by
users
Favorable user
experience and
positive user
feedback
• User feedback to
surveys and
questionnaire on
- Function usefulness
- Function
acceptability
- Timeliness of alerts
- User interface
friendliness
• User answers in surveys and
questionnaires ( to be detailed and
designed later)
67 of 67
• Correctness and
reliability of alert
generation
• Numbers of alerts generated
• Percentage