ISSN 1055- 1425
May 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 6217
CALIFORNIA PATH PROGRAM
INSTITUTE OF TRANSPORTATION STUDIES
UNIVERSITY OF CALIFORNIA, BERKELEY
VII California: Development and
Deployment Proof of Concept and Group-
Enabled Mobility and Safety ( GEMS)
UCB- ITS- PRR- 2010- 26
California PATH Research Report
Jim Misener, et al.
CALIFORNIA PARTNERS FOR ADVANCED TRANSIT AND HIGHWAYS
1 of 133
VII California: Development and Deployment Proof of Concept and Group-
Enabled Mobility and Safety ( GEMS)
Task Order 6217
FINAL REPORT
Jim Misener, Project Manager
Raja Sengupta, Principal Investigator
Katherine Ahern
Somak Datta Gupta
Susan Dickey
Tom Kuhn
Thang Lian
Christian Manasseh
David Nelson
Shahram Rezai
Ashkan Sharafsaleh
Steven Shladover
Joel VanderWerf
University of California, Berkeley
1357 S. 46 th Street, Bldg. 190; Richmond, CA 94804- 4648
March 2010
2 of 133
Contents
Part I: Development and Deployment: Proof of
Concept
1 Conduct ― Innovative Mobility Showcases‖ Demo at the World Congress in 2005 ............. 19
2 Develop Architecture ............................................................................................................ 19
3 Develop Applications............................................................................................................ 20
3.1 Curve Overspeed Warning System ( COWS) ................................................................. 20
3.1.1 Introduction ............................................................................................................. 21
3.1.2 Digital Map as a Virtual Sensor for Advanced Driver Assistance System ............. 23
3.1.2.1 Overview of Digital Map and ADAS .............................................................. 23
3.1.2.2 Architecture and Advantages of the ADAS and COWS Enhanced by VII ..... 24
3.1.3 Dynamic Road/ Lane Curve Reconstruction Using Digital Map Data .................... 25
3.1.4 Conventional Approach ─ Spline ........................................................................... 26
3.1.5 New Approach ─ Data Pre- filtering and Parametric Curve Fitting ........................ 26
3.1.6 Data Pre- Filtering by Circle Center Search ( CCS) and Circle Selection ( CS)
Algorithms ............................................................................................................................ 28
3.1.7 Parametric Curve- Fitting ........................................................................................ 30
3.1.8 Curve Overspeed Warning Experiment .................................................................. 32
3.1.9 Conclusion and Future Work .................................................................................. 33
4 Transition VII California Proof of Concept Testbed to US DOT Development Test
Environment ............................................................................................................................... .. 34
4.1 Build and Expand Testbed ............................................................................................. 34
4.2 Examine Suitability of HA- NDGPS .............................................................................. 35
4.2.1 GPS ......................................................................................................................... 37
4.2.2 Differential GPS and Carrier- Phase GPS ............................................................... 38
4.2.3 Real- Time Differential Corrections ........................................................................ 39
4.2.4 Wide Area Augmentation System ( WAAS) ........................................................... 40
4.2.5 Real Time Kinematic ( RTK) and CORS ................................................................ 41
4.2.6 United States Coast Guard National Differential GPS System .............................. 42
4.2.7 DSRC Background.................................................................................................. 45
4.2.8 NTRIP Broadcasting Methods ................................................................................ 46
4.2.9 Integration of DSRC and NTRIP ............................................................................ 47
4.2.9.1 Hardware Architecture of DSRC/ NTRIP Broadcasts ..................................... 47
4.2.9.2 Software Integration of DSRC/ NTRIP Broadcasts ......................................... 49
4.2.9.3 Architecture Implementation for VII ............................................................... 51
4.2.10 Performance Testing and Evaluation ...................................................................... 54
4.2.10.1 DSRC Performance Testing ............................................................................ 54
4.2.11 NTRIP Broadcast Evaluation of Positional Accuracy ............................................ 55
4.2.11.1 Experimental Coordinate Systems................................................................... 57
4.2.12 Evaluation of VII- Compatible DSRC/ NTRIP Architecture ................................... 57
3 of 133
4.2.13 Recommendations, Conclusions, and Future Work ................................................ 59
4.2.13.1 Summary .......................................................................................................... 59
4.2.14 Next Steps ............................................................................................................... 61
4.2.15 Conclusions ............................................................................................................. 61
5 Conduct Testbed Operations ................................................................................................. 62
5.1 Support VII California Operation and Maintenance ...................................................... 62
5.1.1 Provide Physical Support ........................................................................................ 62
5.1.2 Perform Automatic RSU Monitoring ...................................................................... 62
5.2 Support User Experiments and Demonstrations ............................................................ 62
6 Conduct Testbed Applications Research .............................................................................. 63
6.1 Examine Probe Messaging ............................................................................................. 63
6.1.1 Background ............................................................................................................. 64
6.1.2 Technical Approach ................................................................................................ 65
6.1.2.1 Effects Of Changes On Probe Data ................................................................. 66
6.1.3 Privacy- Protection Strategies .................................................................................. 68
6.1.4 Distortions To Speed Estimates At Signalized Intersections .................................. 70
6.1.5 Alternative Strategies for Consideration ................................................................. 75
6.1.6 Additional Probe Data Research Needed ................................................................ 77
6.2 Develop VII- enabled Curve Speed Warning ................................................................. 78
6.2.1 Introduction ............................................................................................................. 78
6.2.2 Data Transmission and On- board Computation: .................................................... 79
6.2.3 Decision Making: .................................................................................................... 79
6.2.4 Warning Generation: ............................................................................................... 80
7 Management .......................................................................................................................... 80
7.1 Outreach ......................................................................................................................... 80
7.2 Testbed Coordination ..................................................................................................... 80
7.3 Reporting ........................................................................................................................ 81
Part II: Group- Enabled Mobility and Safety ( GEMS)
1 Introduction ........................................................................................................................... 82
2 Outreach of GEMS users ...................................................................................................... 83
2.1 Define GEMS Applications ........................................................................................... 83
2.2 Find Application Users ................................................................................................... 84
2.3 Find Application Developers ......................................................................................... 84
2.4 Conduct Evaluation ( Business Case / Effectiveness) ..................................................... 84
3 Development of RSE and OBE components ........................................................................ 85
3.1 Develop Mobile WiFi/ DSRC Gateway .......................................................................... 85
3.2 Develop Multi- Device/ Multi- Spectrum Web Services .................................................. 89
3.3 Implement Application Components ............................................................................. 91
3.3.1 Mobility Applications ............................................................................................. 91
3.3.1.1 Introduction ..................................................................................................... 91
3.3.1.2 System Architecture ........................................................................................ 93
3.3.1.3 Routing Server ................................................................................................. 94
3.3.2 Safety Applications ............................................................................................... 101
3.3.2.1 Ped Alert: ....................................................................................................... 101
4 of 133
3.3.2.2 Car2Car Application: ..................................................................................... 107
3.3.3 Situational Awareness Applications for Drivers: ................................................. 107
3.3.3.1 Introduction ................................................................................................... 107
3.3.3.2 Integration of applications and scheduling of display resource usage .......... 108
3.3.3.3 Application logic ........................................................................................... 108
3.3.3.4 Database Development .................................................................................. 110
3.3.3.5 System Architecture ...................................................................................... 111
3.3.3.6 Data Provisioning .......................................................................................... 112
3.3.3.7 Simulation Testing ......................................................................................... 112
3.3.3.8 On- the- road testing ........................................................................................ 114
3.3.4 Transit Applications .............................................................................................. 114
3.3.4.1 Premises ......................................................................................................... 114
3.3.4.2 The transit applications— En route transit information ................................. 115
3.3.4.3 The transit applications— Improving the transit operations .......................... 116
3.3.5 Shuttle traffic probes: ............................................................................................ 117
3.3.5.1 Marguerite Shuttle system ............................................................................. 118
3.3.5.2 VII California Testbed ................................................................................... 118
3.3.5.3 System architecture – Hardware .................................................................... 119
3.3.5.4 System architecture – Software ..................................................................... 119
3.3.5.5 Map interface ................................................................................................. 120
3.3.5.6 Web service interface .................................................................................... 120
4 Integrate Applications with User Devices .......................................................................... 121
4.1 WiFi Device Integration ............................................................................................... 121
4.2 Cell Phone Integration .................................................................................................. 122
4.3 Personal Navigation Device ( PND) Integration ........................................................... 122
4.4 Provide Roadside GEMS Elements .............................................................................. 122
4.4.1 Develop Multiband RSE Components .................................................................. 122
4.4.2 Install Multiband RSE........................................................................................... 122
5 Provide Data Integration and Display Elements ................................................................. 122
5.1 Develop Generic Display Format and Data ................................................................. 122
5.2 Provide MTC 511 Interface .......................................................................................... 123
5.2.1 Provide PEMS Interface ....................................................................................... 123
5.2.2 Develop VII California Internet Server ................................................................ 123
6 Make GEMS Testbed Operational ...................................................................................... 123
6.1 Internal demonstration of GEMS proof- of- concept ..................................................... 124
6.2 GEMS demonstration with partners to SSOM in mid- August 2008. ........................... 124
6.3 Install, Shakedown and Test ......................................................................................... 124
6.4 Scale to GEMS Trial .................................................................................................... 124
6.5 Conduct GEMS Testbed Trials .................................................................................... 124
6.6 Management and Reporting ......................................................................................... 124
7 Schedule, Milestones, and Deliverables ............................................................................. 125
8 References: .......................................................................................................................... 126
9 Appendices:.................................................................................................................... .... 128
9.1 Appendix: VII DSRC/ NTRIP DGPS Setup Manual .................................................... 128
5 of 133
9.1.1 To set up unit and begin logging data: .................................................................. 129
9.1.2 In order to make sure that GPS is receiving NTRIP corrections .......................... 133
Table of Figures
Part I:
Figure 1- 1: A Map of the VII California Network ( November, 2007) ......................................... 17
Figure 2- 1: Integrated Multi- Criteria Routing Engine .................................................................. 20
Figure 3- 1: Functional Components of a COWS system .............................................................. 22
Figure 3- 2: Concept of ADAS Enhanced by VII .......................................................................... 24
Figure 3- 3: ( a) Road curve fitted by splines ( b) Radius of curvature derived from splines ......... 26
Figure 3- 4: Concept of Circle Center Search algorithm ............................................................... 28
Figure 3- 5: Proposed road curve reconstruction method .............................................................. 28
Figure 3- 6: Exit ramp from northbound I- 580 to Bayview Ave. ( Google Map) .......................... 29
Figure 3- 7: ( a) Preliminary Curvature Estimates by CCS Algorithm ( b) Preliminary Estimates of
Curvature Radii by CCS Algorithm .............................................................................................. 30
Figure 3- 8: ( a) Optimized estimates of road curvatures through parametric curve- fitting ( b)
Optimized estimates of curvature radii ......................................................................................... 30
Figure 3- 9: On ramp from Marsh Rd. to southbound US 101 ( Google map) ............................... 31
Figure 3- 10: ( a) Preliminary curvature estimates by CCS algorithm ( b) Preliminary estimates of
curvature radii by CCS algorithm ................................................................................................. 31
Figure 3- 11: ( a) Optimized road curvature estimates through curve- fitting ( b) Optimized
curvature radius estimates ............................................................................................................. 32
Figure 3- 12: Example of COWS Field Test at the RFS Test Track ............................................. 33
Figure 3- 13: Vehicle speed and GPS condition when approaching the curve ( when the GPS is in
outage, the resultant HDOP is set to zero by the GPS receiver) ................................................... 33
Figure 4- 1: NDGPS coverage in 2009 [ USCG NAVCEN, 2009]. ............................................... 44
Figure 4- 2: Ntrip architecture [ GNSS Data Center, 2009]. .......................................................... 47
Figure 4- 3: Ntrip/ DSRC hardware architecture ............................................................................ 48
Figure 4- 4: DSRC architecture [ IEEE 1609.3- 2007] .................................................................... 50
Figure 4- 5: WAVE/ DSRC architecture [ IEEE 1609.3- 2007] ....................................................... 50
Figure 4- 6: Configuration screens for the Ntrip Server and Ntrip Client programs. .................... 51
Figure 4- 7: California VII testbed deployment [ www. californiavii. org] ..................................... 52
Figure 4- 8: DSRC communication installation for VII testbed [ www. vii. path. berkeley. edu] ..... 54
Figure 4- 9: UC Riverside DGPS arterial test site ......................................................................... 54
Figure 4- 10: Vehicle with mounted vision system for positional accuracy determination. ......... 56
Figure 4- 11: Image capture of lane marking for positional accuracy determination .................... 57
Figure 4- 12: Camera frame of reference ....................................................................................... 57
Figure 6- 1: Cumulative Distribution of Snapshot Latency from Original TCA ( Lower Curve) and
Updated TCA ( Upper Curve) ........................................................................................................ 67
Figure 6- 2: Histograms of Speed Samples from Ground Truth Simulation and Probe Snapshots
Sampled According to SAE J2735, for Complete Corridor ......................................................... 68
Figure 6- 3: Simulated Probe Snapshots at El Camino Real and Showers Drive, Showing Blind
Spots Where Temporary ID Numbers are Changed ..................................................................... 69
6 of 133
Figure 6- 4: Probability Density of Ground Truth and Probe Snapshot Speeds at a Minor
Signalized Intersection ................................................................................................................. 70
Figure 6- 5: Cumulative Distribution of Ground Truth and Probe Snapshot Speeds at a Minor
Signalized Intersection ................................................................................................................. 71
Figure 6- 6: Probability Density of Ground Truth and Probe Snapshot Speeds at a Major
Signalized Intersection ................................................................................................................. 72
Figure 6- 7: Cumulative Distribution of Ground Truth and Probe Snapshot Speeds at a Major
Signalized Intersection ................................................................................................................. 72
Figure 6- 8: Cumulative Distribution of Number of Snapshots per Segment ................................ 73
Figure 6- 9: Cumulative Distribution of Snapshot Segment Duration ( seconds) .......................... 74
Figure 6- 10: Cumulative Distribution of Snapshot Segment Length ( meters) ............................. 74
Figure 6- 11: Concept of operation for the ramp example of CSW ............................................... 79
Part II:
Figure 1- 1: GEMS application on a mobile phone ....................................................................... 83
Figure 3- 1: Software architecture of SOBU ................................................................................. 89
Figure 3- 2: Front page of the Networked Traveler website .......................................................... 90
Figure 3- 3: Traffic Information Provision System Architecture with Multi- criteria Routing ...... 94
Figure 3- 4: A demonstration of PedAlert application in 2008 ITS World Congress ................. 101
Figure 3- 5: Relative distance between GPS position measurements .......................................... 102
Figure 3- 6: iPhone accelerometer measurements along an axis perpendicular to Earth gravity
direction ............................................................................................................................... ...... 103
Figure 3- 7: Meade street outside RFS. ....................................................................................... 104
Figure 3- 8: Results of some field experiments in order to determine beginning of crossing time
............................................................................................................................... ..................... 105
Figure 3- 9: Dynamic Personalized Passenger Information System ............................................ 115
Figure 3- 10: Time to Transfer point update ................................................................................ 115
Figure 3- 11: Your stop next alert ................................................................................................ 116
Figure 3- 12: Carbon emissions saving of a transit trip ............................................................... 116
Figure 3- 13: GEMS transit apps for transit operations ............................................................... 117
7 of 133
Executive Summary
This PATH Research Report covers the ( Vehicle- Infrastructure Integration) VII California
Development and Deployment ( Task Order 6217) efforts beginning in 2008 and concluding June
30, 2009. This is a successor to the report for TO 5217 and reports the applications- oriented
research subsequent to that work.
The report is organized by a synopsis of the background and reasons for the VII California
project, then it summarizes some of the antecedent ( TO 5217) work: the ― Innovative Mobility
Showcase‖ ( 2005), which established the architecture and, importantly the applications ( curve
overspeed warning, probe messaging)) and the underlying testbed and enablers ( High Accuracy
National Differential GPS).
Let us begin with the question, ― Why VII California was implemented?‖ It is important to begin
with an understanding of a significant impetus: the national VII ― movement‖. The VII system in
the United States would be enabled by roadside wireless hotspots generated by Dedicated Short
Range Communication ( DSRC) transceivers operating within 75 MHz of free, FCC- licensed
bandwidth near 5.9 GHz. These transceivers are incorporated in Roadside Equipment ( RSE),
which are connected by edge backhaul communications into a network architecture that
addresses security, privacy and other design considerations ( FHWA, 2005). Applications,
standards and architecture are under active development. The goal of these efforts is a roadside-based
network delivering low- latency, highly reliable data communications to support safety and
mobility services to users. The coverage would be extensive: the proposed VII system has the
potential to cover all urban roads within 2- minute travel times, 70% of all signalized
intersections in 454 urban areas and up to 15 new million vehicles per year would be DSRC- and
therefore VII- equipped ( Cops, 2006).
The VII initiative is intended to lead to nationwide deployment of cooperating vehicle and
infrastructure devices, producing an integrated transportation data network of unprecedented
scope and complexity. The fully deployed system would include onboard equipment ( OBE)
installed on new vehicle manufactured after a specified date and roadside equipment ( RSE)
installed at all signalized intersections in major urban areas, at primary intersections in other
areas, at all highway interchanges and along major intercity and many rural highways
( representing about 240,000 RSE locations nationwide). This network would make it possible to
collect transportation operations data of great breadth and depth, to implement sophisticated
traffic safety systems, and to manage traffic flows with previously unthinkable precision.
To assess the feasibility and desirability of VII, many technical, economic and institutional
questions need to be answered. Considering the magnitude of the commitments that was needed
by a wide range of public and private sector organizations in order for VII to be deployed, these
questions must be answered very convincingly before deployment can proceed. The process of
developing the answers is just beginning, and is likely to require considerable time and effort.
Lessons for deployment might be learned from regional efforts, notably in Florida, Michigan and
California ( Florida DOT, 2004, Michigan DOT, 2007, Misener and Shladover, 2006) and most
8 of 133
certainly in the forthcoming US DOT VII Proof of Concept experiments ( Henry, 2007).
Certainly, California is at the nexus of VII need and innovation. The same reasons to create a
national VII program are acutely recognized in California: an obligation to better manage the
safety and productivity of our highway system, and the understanding that a fusion of public,
automotive and other private sector innovations can make this a reality.
However, California and regional stakeholders have specific transportation infrastructure,
operating policies and needs than what may be universally addressed with a national VII
program. These needs have led to a partnership between Caltrans and the San Francisco Bay
Area Metropolitan Transportation Commission. Caltrans and MTC are addressing these needs
with a multiyear effort to develop, demonstrate and deploy VII in a key corridor in Northern
California. This corridor is comprised of roughly ten- mile segments of two routes North of Palo
Alto and South of the San Francisco Airport. It encompasses two highways: State Route 82 and
US 101. We note that this selection addresses both a high- volume freeway ( US 101) and a major
arterial complete with signalized intersections ( SR 82), shown below:
9 of 133
A Map of the VII California Network ( November, 2007)
Overall, Caltrans and MTC aimed to:
Evaluate exemplar public use cases from which we can generalize VII feasibility;
10 of 133
Evaluate institutional, policy and public benefit issues;
Explore wireless communication deployment issues and options;
Resolve key technical issues involving implementation and operation;
Assess implementations of the VII infrastructure, architecture and operations; and
Support private sector evaluation interests.
In support of VII California, PATH has conducted this project, VII California Development and
Demonstration Deployment ( VIIC D 3 or simply D 3 ) where the testbed was built and operated and
where deployment and applications issues are investigated. Why? Because some of the technical
questions can be addressed through analysis and simulation studies, while others need field
testing under realistic conditions. Some of the most challenging questions, which will require
the largest investments of time and effort, involve the scalability of system performance in
advancing from small numbers of OBEs and RSEs to large numbers of OBEs for each RSE and
then to large numbers of RSEs as well. Other questions involve the practical aspects of
implementing RSEs in the real world of roadway operations, which can only be answered by
starting to install and operate those RSEs and learning about the physical and institutional
constraints, the failure modes and the maintenance needs that are encountered there. These have
important ramifications for the design of the VII technology and for the long- term costs of
deploying, operating and maintaining it in the field.
The Curve Overspeed Warning System ( COWS) is one of the two cooperative active safety
applications of VII California. ( The other such time- critical safety of life applications that
requires low latency, highly reliable and available vehicle- to- infrastructure and infrastructure- to-vehicle
communication is Cooperative Intersection Collision Avoidance Systems ( CICAS), not
covered in this report.) The COWS system is aimed to integrate on- board sensors, digital map,
GPS and the broadcasted information from the RSE to predict safety speed and provide speed
advisory or warning messages to the driver.
To gain general applicability on production vehicles, the current system design adopted in this
project utilizes a minimum set of common mobile sensors to achieve the required COWS
functionalities. The prototype components include wheel speed sensors, yaw rate sensor, GPS
with/ without differential correction and a digital map. These four items would be coupled with a
processor, communication devices, and a human- machine interface. The current research in VII
California follows five main objectives:
1. Improve the integration of a digital map, GPS and mobile sensors for the COWS
application
2. Conduct map- based road modeling for real- time road geometry estimation and prediction
3. Conduct dynamic lane- level vehicle positioning and detection with digital map and GPS
or DGPS
4. Enhance map update by vehicle- infrastructure ( V- I) communication
5. Enhance cooperative safety with V- I communication by estimating road surface condition
and providing dynamic information to RSE
The California PATH program and Caltrans have a number of research applications that can
benefit from a high- accuracy vehicle positioning implementation. The U. S. Department of
11 of 133
Transportation and U. S. Coast Guard in conjunction with the Interagency GPS Executive Board
are currently developing a High Accuracy- Nationwide Differential Global Positioning System
( HA- NDGPS), targeted at a variety of transportation- related applications. The HA- NDGPS
program provides the capability to broadcast corrections to the Global Positioning System ( GPS)
over long ranges to achieve accuracy better than 10 centimeters ( 95 percent of the time)
throughout the coverage area. HA- NDGPS is currently undergoing a research and development
phase with a future implementation pending U. S. congressional budget approvals. Application of
this technology will provide advanced safety features for transportation, including applications
such as lane departure warning, intersection collision warnings, and railroad track defect alerts.
The VII California Program has established a testbed in the San Francisco Bay area that is being
utilized for a variety of experiments. With the integration of vehicle and roadside
communications ( DSRC), the determination of vehicle location has become a critical component
for several VII applications. One of the key objectives of this study is to demonstrate that the
existing VII communication infrastructure ( i. e., Dedicated Short Range Communications
( DSRC), roadside equipment) can be utilized where possible for broadcasting corrections to the
vehicles‘ GPS receivers. This eliminates the need to depend on other communication methods to
receive correction signals, resulting in greater control and lower costs. This architecture
compliments the potential use of existing DGPS broadcast networks such as the California
statewide CORS, NDGPS, and/ or NGS.
The architecture of the local base station integrated with the VII communications infrastructure
provides both a low- cost lane- level positioning solution with the potential to upgrade to
centimeter- level accuracy using carrier phase receivers that could be installed in a subset of
vehicles. The pseudorange and carrier phase corrections could both be broadcast over the RSE
DSRC transceivers or through an alternative wireless network. While this integrated approach
has not been developed commercially, the methodology and experimentation ( described in this
report) has shown to be viable through similar university research programs. Initial integration
may consist of only code corrections while future implementations could add carrier phase
corrections with only software changes to be made in the base station and RSE hardware.
This study has implemented the DGPS/ DSRC architecture and demonstrated the feasibility of
broadcasting the DGPS code corrections over the DSRC network. Initial performance
evaluations were completed to demonstrate the potential performance of the architecture. While
initial performance has demonstrated the architecture to be successful for lane- level positioning
applications requiring differential corrections, additional enhancements would be required for
deploying the architecture beyond specific testbeds, pilots, and demonstrations. These
enhancements would allow for a more commercially viable solution to improving GPS positional
accuracies. Several research goals were achieved with this evaluation:
Comparison of positioning performance using NDGPS corrections transmitted via beacon
and via Internet – correction quality and positional accuracy has been demonstrated to be
dependent on prompt acquisition of a DGPS correction message. The DGPS signal
transmission via internet has been evaluated for TCP/ IP transmission with a DSRC link
to the rover vehicle. Rapid and effective acquisition of a DSRC link is critical for
receiving DGPS corrections within a single cell DSRC coverage area;
12 of 133
Potential of transferring HA- NDGPS corrections to standard formats – this study has
reviewed and evaluated the protocols, formatting, and transmission of high accuracy
signals. The HA- NDGPS protocol performs a message compression/ decompression
sequence which does not degrade the quality of the original RTCM correction message.
Integration potential of alternative correction signals ( RTK, WAAS, CORS etc.) – tests
scenarios completed within this study have demonstrated that the DSRC/ Ntrip
architecture is compatible with any RTCM correction messages. Receivers capable of
processing multiple sources of corrections can utilize alternate corrections in addition to
corrections received via DSRC/ Ntrip.
Integration of HA- NDGPS receivers within CA VII vehicles/ applications – the
HANDGPS protocols have been found to provide a RTCM compatible correction which
is suitable for any L1/ L2 receiver accepting RTCM carrier phase corrections. Specifically
configured receivers are not necessary if broadcasts are transmitted via TCP/ IP protocols
( DSRC/ Ntrip).
Geographical distribution accuracy requirements of corrections signals ( regional,
intersection- only, highway- only etc) – the range and performance of a single DSRC
transmission site was evaluated. Performance was found to be greatly dependent upon the
rate of acquiring a DSRC communication link;
Frequency requirements of correction signals – the frequency of transmitting a correction
signal was maximized for performance within the scope of this study. Decreasing the
frequency would be possible for regions of continuous or semi- continuous DSRC
coverage; and,
Compatibility of RSE/ DSRC system design with correction signal size, frequency,
format, and vehicle densities – the current study results did not find limitations due to
DSRC communication bandwidth. DSRC communication and position quality was
limited primarily by DSRC coverage area.
The next step towards a final integration would be to create compatible software that would
determine availability of suitable regional corrections and autonomously initiate transfer. The
current architecture requires a manual selection of DGPS base stations. This future development
would focus on these following components:
A review and collaboration with entities maintaining DGPS broadcast networks to
establish agreements for automated downloads;
Create software that evaluates current location and searches for spatial- appropriate and
available correction messages;
create software that automatically adjusts configuration settings of DGPS Ntrip
communications; and
13 of 133
Implement and test the automated architecture in specific VII applications.
Successful implementation of this automated DGPS acquisition architecture would greatly
simplify the methodology of acquiring DGPS corrections and provide improved positioning
performance of future ITS implementations.
The current phase of research on VII probe data processing has produced ( and is
producing) the following results:
• Implementation of the Noblis Trajectory Conversion Algorithm ( TCA) program
to process simulation outputs from the PATH ( PTTL) VISSIM simulation of El
Camino Real, following the J2735 probe sampling protocols
• Analysis of TCA outputs to identify substantial latency in probe snapshot uploads
under default conditions
• Examination of changes to probe message management protocol to significantly
reduce latency to support the most time- critical probe data applications
• Exploration of effects of market penetration on aggregated probe data granularity
( in both time and space)
• Evaluation of effects of local aggregation ( at RSE) on backhaul data rate and RSE
computational burden for some representative types of probe data ( weather status,
dropped load, traffic speed).
This work is still scratching the surface of a substantial topic, with the potential to influence the
developing SAE J2735 standard and expectations for future use of VII probe data. We have been
in close contact with Noblis, who are studying the probe data processing issues for the national
VII program, with substantially larger resources at their disposal, to ensure that our work remains
complementary to theirs rather than duplicative. They have been focusing on detailed evaluation
of the SAE J2735 protocols and sensitivity studies to evaluate the suitability of the key features
of SAE J2735, with a strong emphasis on the Day One VII applications and relatively low
market penetrations. We have been considering the needs of some of the longer term VII
applications and market penetrations up to 100% in order to ensure that the VII probe approach
is scalable to a fully mature VII system. We plan continuing consultations with the Noblis staff
to maintain the complementarity of our efforts.
During the coming year, we are planning to address the following important VII probe
vehicle data sampling issues:
• Testing performance in a new urban network currently being studied by Noblis ( the Van
Ness corridor in San Francisco), which appears to have some advantages over our current
El Camino network;
Developing improved algorithms for estimating network speed from probe samples, since
simple averaging introduces significant biases;
Developing and evaluating semantic approaches for reducing the backhaul burden
associated with probe data, complementary to the aggregation approach currently being
evaluated;
14 of 133
Evaluating the effect of adjusting the in- vehicle snapshot buffer size and buffer
management rules based on considerations of market penetration and density of RSE
installations;
Seeking another network model that can be used for freeway probe studies, and including
urban fringe areas where RSEs was sparse or non- existent;
Investigating strategies for maximizing the effectiveness of probe data sampling at the
boundaries of regions that are equipped with RSEs, so that the snapshots collected in
unequipped regions are not lost unnecessarily. Other issues that could potentially overlap
with Noblis‘ work was considered, but only explored if we can determine that Noblis is
not addressing them:
Evaluating snapshot management alternatives to make most efficient use of the available
buffer;
Increasing the snapshot buffer size, particularly under low market penetration conditions;
Evaluating the effect of changes in the snapshot management rules on the load imposed
on the DSRC wireless channel;
Evaluating suitability of the default snapshot sampling rules under a range of traffic
conditions, including heavy congestion.
15 of 133
Background and Introduction
______________________________________________________________________________
This PATH Research Report is organized to impart the very specific and generally very
pragmatic implementation details first, beginning with an introduction, description of VII
hardware, general network and installation, then progressing to a more detailed description of
the network and operating software and finally to applications in development and prospective
applications. Because it is not yet a final report but rather a ‘ research in progress’ report, it
does not comprehensively address every task in the VII California family of task orders;
specifically, several of the applications described in Section 4 are represented as works in
progress ( as they are at this writing), and the on- ramp metering study is not yet reported. Again,
the purpose, of this report is to provide the reader with an understanding of how VII California
was implemented.
______________________________________________________________________________
Let us begin with the question, ― Why VII California was implemented?‖ It is important to begin
with an understanding of a significant impetus: the national VII ― movement‖. The VII system in
the United States would be enabled by roadside wireless hotspots generated by Dedicated Short
Range Communication ( DSRC) transceivers operating within 75 MHz of free, FCC- licensed
bandwidth near 5.9 GHz. These transceivers are incorporated in Roadside Equipment ( RSE),
which are connected by edge backhaul communications into a network architecture that
addresses security, privacy and other design considerations ( FHWA, 2005). Applications,
standards and architecture are under active development. The goal of these efforts is a roadside-based
network delivering low- latency, highly reliable data communications to support safety and
mobility services to users. The coverage would be extensive: the proposed VII system has the
potential to cover all urban roads within 2- minute travel times, 70% of all signalized
intersections in 454 urban areas and up to 15 new million vehicles per year would be DSRC- and
therefore VII- equipped ( Cops, 2006).
The VII initiative is intended to lead to nationwide deployment of cooperating vehicle and
infrastructure devices, producing an integrated transportation data network of unprecedented
scope and complexity. The fully deployed system would include onboard equipment ( OBE)
installed on new vehicle manufactured after a specified date and roadside equipment ( RSE)
installed at all signalized intersections in major urban areas, at primary intersections in other
areas, at all highway interchanges and along major intercity and many rural highways
( representing about 240,000 RSE locations nationwide). This network would make it possible to
collect transportation operations data of great breadth and depth, to implement sophisticated
traffic safety systems, and to manage traffic flows with previously unthinkable precision.
To assess the feasibility and desirability of VII, many technical, economic and institutional
questions need to be answered. Considering the magnitude of the commitments that was needed
by a wide range of public and private sector organizations in order for VII to be deployed, these
questions must be answered very convincingly before deployment can proceed. The process of
developing the answers is just beginning, and is likely to require considerable time and effort.
16 of 133
Lessons for deployment might be learned from regional efforts, notably in Florida, Michigan and
California ( Florida DOT, 2004, Michigan DOT, 2007, Misener and Shladover, 2006) and most
certainly in the forthcoming US DOT VII Proof of Concept experiments ( Henry, 2007).
Certainly, California is at the nexus of VII need and innovation. The same reasons to create a
national VII program are acutely recognized in California: an obligation to better manage the
safety and productivity of our highway system, and the understanding that a fusion of public,
automotive and other private sector innovations can make this a reality.
However, California and regional stakeholders have specific transportation infrastructure,
operating policies and needs than what may be universally addressed with a national VII
program. These needs have led to a partnership between Caltrans and the San Francisco Bay
Area Metropolitan Transportation Commission. Caltrans and MTC are addressing these needs
with a multiyear effort to develop, demonstrate and deploy VII in a key corridor in Northern
California. This corridor is comprised of roughly ten- mile segments of two routes North of Palo
Alto and South of the San Francisco Airport. It encompasses two highways: State Route 82 and
US 101. We note that this selection addresses both a high- volume freeway ( US 101) and a major
arterial complete with signalized intersections ( SR 82), shown in Figure 1- 1:
17 of 133
Figure 1- 1: A Map of the VII California Network ( November, 2007)
Overall, Caltrans and MTC aim to:
Evaluate exemplar public use cases from which we can generalize VII feasibility;
18 of 133
Evaluate institutional, policy and public benefit issues;
Explore wireless communication deployment issues and options;
Resolve key technical issues involving implementation and operation;
Assess implementations of the VII infrastructure, architecture and operations; and
Support private sector evaluation interests.
In support of VII California, PATH has conducted this project, VII California Development and
Demonstration Deployment ( VIIC D 3 or simply D 3 ) where the testbed was built and operated and
where deployment and applications issues are investigated. Why? Because some of the technical
questions can be addressed through analysis and simulation studies, while others need field
testing under realistic conditions. Some of the most challenging questions, which will require
the largest investments of time and effort, involve the scalability of system performance in
advancing from small numbers of OBEs and RSEs to large numbers of OBEs for each RSE and
then to large numbers of RSEs as well. Other questions involve the practical aspects of
implementing RSEs in the real world of roadway operations, which can only be answered by
starting to install and operate those RSEs and learning about the physical and institutional
constraints, the failure modes and the maintenance needs that are encountered there. These have
important ramifications for the design of the VII technology and for the long- term costs of
deploying, operating and maintaining it in the field.
This report describes the lessons learned in the all phases of the PATH effort.
19 of 133
Development and Deployment: Proof of Concept
1 Conduct “ Innovative Mobility Showcases” Demo at
the World Congress in 2005
The World Congress ― Innovative Mobility Showcase ( ISM)‖ will include a VII California
demonstration of three vehicle original equipment manufacturer ( OEM)- developed applications:
1) Vehicles as Traffic Probes:
Data from vehicles is sent to the central processing center and used to calculate travel
times along specified link, routes, or paths.
2) Travel Time Data to Vehicles:
The central processing center sends accurate and up- to- date link travel times to the RSU
and then the vehicle for use in real- time dynamic routing. The travel times was generated
by the 511/ TravInfo ™ system.
3) In- Vehicle Signage:
Integration of roadside signage information into in- vehicle navigation system, e. g, speed
limit, next exit information. Lays migration path to work zone warning.
In addition, there may be OEM applications which they choose to show to their corporate
leaders: Encrypted message set specific to Original Equipment Manufacturer ( OEM)
requirements, passed between vehicle, RSU and OEM center.
This Task 1 provides resources for PATH to participate in the VII California IMS demonstration,
to troubleshoot computer software or RSE hardware components in order to keep the
aforementioned applications running, and to staff the VII California World Congress booth.
2 Develop Architecture
This task requires the TEAM to seamlessly integrate various data collection, processing
components and routing features and construct traffic routing and information provision services,
as illustrated in Figure 2- 1. Specifically, the TEAM will work with the PATH team to provide
three types of web services:
Pre- trip and real- time routing,
Traffic congestion along the route,
Slow traffic ahead alert.
20 of 133
Traffic
Information
Services:
1. Routing
2. Congestion
along the route
3. Slow traffic
ahead
Traffic Data Fusion and
Prediction Engine
Dynamic Multi- criteria
Routing Engine
High resolution
link- node map
Live Freeway
Traffic Data
GPS-equipped
mobile
phone
Traffic Alert
Service
( PATH)
Figure 2- 1: Integrated Multi- Criteria Routing Engine
3 Develop Applications
This chapter will discuss several applications that are currently being developed in association
with the VII California effort. In addition, each application discussed will provide the current
progress and a promising future outlook. The first section will discuss in details the Curve
Overspeed Warning System ( COWS), and then will proceed to discuss in details of additional
applications organized in different sections including Traffic Probe Data Processing, Real- Time
Arterial Performance Data, Intersection Safety, and lastly, High- Accuracy Nationwide
Differential Global Positioning System ( HAND- GPS).
3.1 Curve Overspeed Warning System ( COWS)
The Curve Overspeed Warning System ( COWS) is one of the two cooperative active safety
applications of VII California. ( The other such time- critical safety of life applications that
requires low latency, highly reliable and available vehicle- to- infrastructure and infrastructure- to-vehicle
communication is Cooperative Intersection Collision Avoidance Systems ( CICAS), not
covered in this report.) The COWS system is aimed to integrate on- board sensors, digital map,
GPS and the broadcasted information from the RSE to predict safety speed and provide speed
advisory or warning messages to the driver.
To gain general applicability on production vehicles, the current system design adopted in this
project utilizes a minimum set of common mobile sensors to achieve the required COWS
21 of 133
functionalities. The prototype components include wheel speed sensors, yaw rate sensor, GPS
with/ without differential correction and a digital map. These four items would be coupled with a
processor, communication devices, and a human- machine interface. The current research in VII
California follows five main objectives:
6. Improve the integration of a digital map, GPS and mobile sensors for the COWS
application
7. Conduct map- based road modeling for real- time road geometry estimation and prediction
8. Conduct dynamic lane- level vehicle positioning and detection with digital map and GPS
or DGPS
9. Enhance map update by vehicle- infrastructure ( V- I) communication
10. Enhance cooperative safety with V- I communication by estimating road surface condition
and providing dynamic information to RSE
This section describes the preliminary results with respect to Objectives 1 and 2 above. It details
the development procedure of a new method for dynamic reconstructing of road curvatures using
digital map as well as demonstrating its effective in a prototype COWS system implemented in a
PATH vehicle. While digital map has been applied to many Advanced Driver Assistance System
( ADAS) applications, one critical attribute – road/ lane curvature is not available in the existing
digital maps. Curvature derivation using Splines is a well- known method in the computer
graphics modeling community; however it was also found that the direct application of the
Spline method is often not appropriate for real- time safety applications due to the resultant
discontinuities in the curvature estimates and the lack of robustness against map data errors.
This report presents a method to reconstruct road curvature attributes in real- time using existing
digital map data based on the proposed Circle Center Search ( CCS) and Circle Selection ( CS)
algorithms. Simulation and experimental results on a prototype system demonstrated that the
proposed method can deliver curvature estimates that meet the desired accuracy for a typical
Curve Over- Speed Warning system.
3.1.1 Introduction
In- vehicle navigation and telematics systems which utilize GPS, digital map databases and
wireless communication to receive external information, are becoming popular in recent years.
The increased use of the in- vehicle navigation systems has also motivated the exploration of
extracting road information from the digital map databases for other in- vehicle applications. In
particular, many safety- related systems are candidates benefiting from the use of digital map
information. While ADAS are becoming more and more popular today, map data and positioning
information of navigation systems are being developed to improve driver assistance functions,
which facilitates the development of Predictive Information and Assistance functions. It is
believed that there is a significant potential for the use of a digital map and the vehicle‘ s position
to predict the road geometry and to track related attributes ahead of the vehicle. Moreover,
ADAS- Applications can benefit from this potential, and new functionality may likely be enabled.
A curve warning system, an embodiment of this concept, based on a navigation system and
enhanced by VII is one of such application example.
22 of 133
Nowadays many driver safety assistance and stability control systems, such as Lane Departure
Warning System ( LDWS), Adaptive Cruise Control ( ACC), Electric Stability Program ( ESP),
and Active Rollover Prevention ( ARP), are often equipped on modern vehicles. These systems
typically react to an event that has already occurred. The idea of dynamically extracting
incoming road attributes from a digital map database and treating the map as a virtual sensor, and
integrating such a sensor into the vehicle positioning system in order to improve the ability of
predicting an impending safety event becomes very appealing. Efforts have been made to realize
this concept in the ITS industry such as in the US EDMap project and in the European IN- ARTE,
NextMAP, ActMAP, and PReVENT projects.
The concept of ― using the digital map as a virtual sensor‖ has been studied in some of the
aforementioned projects in the sense of a ― horizon- predictive sensor‖ to provide hot spot
warnings to a driver; it has also been applied to enhance the GPS/ INS- based positioning system
for lane- identification purpose in this research project. This report presents a Curve Overspeed
Warning System, which was developed under this concept. Figure 3- 1 shows the block diagram
of this COWS, which exploits digital map data in the following functional units: Map- Matching,
Attribute Provider, Position Enhancement, and Safety Application modules.
Figure 3- 1: Functional Components of a COWS system
This report focuses on several prerequisites of the COWS: reconstructing dynamic road curve
using digital map for Curve Speed Assistant 1 ( CSA) system as well as assessing its applicability
in COWS. Road or lane curvature, an important parameter for computing safe speed on a curve,
is typically not available as an attribute in the existing digital maps. This attribute can be either
dynamically estimated in real- time or extracted from a set of pre- processed data saved in the
database. However, practical considerations, such as data storage limitation, map update
frequency, accommodation of complex or dynamic road attributes ( e. g. super- elevation, friction,
1 Curve Speed Assistant includes Warning and Control functions ( CSA- W and CSA- C). VII-based
COWS is endeavored to be an enhanced CSA- W.
23 of 133
and road grade) motivate the researchers to seek out methods that provide reliable road/ lane
curvature estimates based on the existing digital map data. Curvature derived from splines was
used in EDMap project, however, it was concluded that ― systematic problems‖ exist that prevent
the curve warning application from directly using curvature derived from the splines,‖ and ― more
work must be done to improve the methods used for representing curvature to enable the curve
warning functionality.‖ To provide more accurate real- time curvature estimates, a new approach
based on locating the centers of curve sections, a Circle Center Search ( CCS) algorithm, was
developed and validated through simulations and experiments. The resultant curvature estimate
errors, varying from 5% to 10% depending on the map data accuracy, meets curvature accuracy
requirements ( 10% for CSA- W and 5% for CSA- C) suggested by CAMP.
The outlines of this report are as follows. Section 3.1.2 describes typical map- based ADAS
systems, in particular the COWS, as well as the framework of an enhanced ADAS system using
vehicle infrastructure integration. Section 3.1.5 proposes a new method for curvature estimation
based on the existing digital map and addresses the related design issues. Comparisons between
the conventional spline approach and the proposed method are also provided. Section 3.1.8
shows the preliminary experimental results conducted at the Richmond Field Station for a
prototype Curve Overspeed Warning System using a PATH vehicle. Conclusions are made in
Section 3.1.9.
3.1.2 Digital Map as a Virtual Sensor for Advanced Driver Assistance System
3.1.2.1 Overview of Digital Map and ADAS
Over the years, the specifications of a digital map have gradually evolved to fulfill the
requirements of various emerging in- vehicle applications, such as GPS- based navigations and
ADAS applications. A typical digital map is a geographical database containing road geometrical
and attributive data. Based on a specific road network model, the geometric relationship and road
features can be described based on certain rules. Geographic Data File ( GDF) map is currently an
international ISO standard for navigation maps. It is both a data model and an exchange format
for digital maps that can accommodate different map contents and data formats defined by
individual map makers. Hence, different navigation systems can interpret all digital maps
following this standard.
A modern navigation system typically has two main components: a map database and a GPS-based
positioning unit that can be integrated with ― dead reckoning‖ sensors such as gyroscope
and odometer. The calculated vehicle position can be ― projected‖ to the most likely point on the
map and be associated with a road segment. Through this ― map- matching‖ technique, the
relevant road attributes and information can be extracted from the database. Given the
destination provided by the driver and the continuously updated actual positions, the navigation
system guides a driver to his destination through the best route.
In contrast to the relatively simple structure of a navigation system, ADAS applications often
require two additional subsystems, ADAS Horizon Provider ( AHP) and ADAS Horizon
Reconstructor ( AHR), to extract and process data for the ADAS computation. The processed
ADAS specific map data ( in both of geometrical and attributive contents) is called the ADAS
24 of 133
horizon ( AH), which is the extracted map data around the current position as well as in the
― look- forward‖ direction. The ― low- level‖ data extraction and aggregation into AH ( 2D) is
executed by AHP based on the map- matched position received from the positioning unit. AHR
receives AH ( 2D) from AHP and transmits only the incremental updates of AH ( 1D) to the
ADAS application, i. e. AHR functions as a ― filter‖ to accommodate bandwidth constraints in the
application side. This interface between AHR and the application is referred to as the ― high- level
interface‖ since it can be developed as an internal API of an application.
Note that the correctness of the AHP and AHR functions hinges on accurate map- matched
positions, especially for the high- accuracy ADAS applications such as Lane Following Assistant,
Forward Collision Warning, and Curve Speed Warning or Control. Both the vehicle positioning
system and the digital map may need to be enhanced for such ADAS applications. In addition to
accuracy, the map database needs to be updated frequently to guarantee reliable up- to- date road
information. As a consequence, an easily accessible and cost- effective map updating method
needs to be provided for maintaining such map- based ADAS applications. VII is one such
application candidate and its concept of operation is described below.
3.1.2.2 Architecture and Advantages of the ADAS and COWS Enhanced by VII
Figure 3- 2 shows the main components of this new ADAS system enhanced by the vehicle and
infrastructure integration in this report. This system integrates ( D) GPS, vehicular sensors,
wireless communication ( e. g. Dedicated Short Range Communication: DSRC), and digital
application map to perform safety- related applications such as curve overspeed warning, stop
sign warning and junction/ intersection speed warning. The application map is developed based
on the commercial GDF map provided by NAVTEQ. Since most current digital maps are ― road-level‖
maps, detailed road/ lane attributes, such as number of lane, lane width, and stop sign
location, are not available but are required for many safety applications. Therefore, this
application map was generated by extracting relevant road geometrical and attributive
information from the existing GDF map and adding the aforementioned detailed attributes to the
new database.
Figure 3- 2: Concept of ADAS Enhanced by VII
25 of 133
The on- board system platform consists of the following functional modules: EKF- based
GPS/ INS positioning unit, Map- Matching processor, Attribute Provider, Position Enhancement
unit, Safety Application module, and the Wireless Communication unit. The advantages of this
system design are described as follows.
The system can not only operate in a stand- alone fashion using on- board sensors and digital map,
but it can also operate in a cooperative enhancement manner through VII. When there are RSE)
nearby, the equipped vehicle can exchange data with RSE via V- I wireless communication, e. g.
DSRC. Detailed or dynamic road attributes such as super- elevation, grade, friction, traffic signal
at ramp end ( metering) etc., as well as event- based messages such as traffic accident, lane
closures, detour, or construction zone, can be transmitted from the RSE to the vehicle. In
addition, it is possible to provide GPS correction signal and map update service to the on- board
system through VII. On the other hand, the equipped vehicle can transmit detected or computed
data such as speed advisory, air bag activation and ABS activation, to the RSE, so that RSE can
inform other nearby drivers of an incident ahead.
The system also employs a positioning enhancement unit to improve the map- matched position
for lane identification using a ― road- level‖ positioning unit. As opposed to the ― lane- level‖
vehicle- map positioning system, which relies on measurements from the lane- level positioning
unit, the proposed system has advantages in terms of robustness and cost- effectiveness.
The current and future road/ lane curvature can be estimated in real- time based on the road
― node‖ positions, and lane attributes, i. e. lane width and number of lane. The details was
described in the next section.
3.1.3 Dynamic Road/ Lane Curve Reconstruction Using Digital Map Data
This section focuses on one technical issue regarding road/ lane curvature estimation using map
data in certain specific ADAS applications such as Curve Over- Speed Warning: estimating in
real time the radius of curvature, curvature direction, and the position of the curvature center.
More complex road attributes such as super- elevation, grade and side friction, are expected to be
taken into account for further curvature refinement 2 .
Since the road or lane curvature is not an available attribute in the existing commercial digital
map, this important attribute should either be estimated in real- time, or be created off- line and
saved in advance before operation. However, if a reliable method utilizing the existing map data
can be developed to estimate the road/ lane curvature in real- time, significant data storage space
can be saved.
The following sub- sections first explain the feasibility of the curvature derivation based on
splines, a well- known mathematical tool in the computer graphics modeling community. Then a
nonlinear filtering approach using CCS and CS algorithms was proposed and compared with the
splines approach.
2 In this report, those complex road attributes are not taken into consideration for curvature
estimation.
26 of 133
3.1.4 Conventional Approach ─ Spline
Spline is a common tool for road geometry representation. A spline typically refers to a wide
range of functions defined piecewise by polynomials that are used in applications requiring data
interpolation and/ or smoothing. Using the spline format, it is possible to interpolate road position
coordinates at any point along the spline based on the discrete map positions called nodes. Road
attributes, such as headings, tangents, and curvatures can also be derived using the resulting
splines. It is therefore possible to deliver the road geometry information to the ADAS
applications in the spline format. However, curvatures derived from splines may not be directly
used by the ADAS applications as found in CAMP.
As shown in Figure 3- 3, the curve represents the road center line of an exit ramp from
northbound highway I- 580 to Bayview Avenue. It is constructed by the cubic b- spline based on
the ― node‖ positions. This curve seems to be well- described by the spline function, y = f( x). One
can derive the road curvature by the following formula using this spline function:
2
2
3/ 2
2
1
( )
( ) 1 ( )
d y
dx
dy
dx
K x
R x
where K( x) and R( x) are the resulting curvature and radius, respectively.
Figure 3- 3( b) shows the estimates of the curvature radius by this approach.
( a) ( b)
Figure 3- 3: ( a) Road curve fitted by splines ( b) Radius of curvature derived from splines
Two main problems can be observed from this example. First, errors of the curvature estimates at
the curve ends are large, which is due to the insufficient positional constraints. This type of
errors would appear frequently especially when such data are delivered by the ― incremental‖ AH.
Second, the variance of curvature estimates is also large, and it can be detrimental to the
performance of CSA as it may cause large undulation in the resultant safety speeds.
In addition, curve- fitting by splines cannot guarantee ― robustness‖ against the positioning
inaccuracy because of its intrinsic property. Unfortunately, the map data has relatively high
positional inaccuracy due to the sensor noise and the accumulated errors in the repositioning
process. Road information derived from splines may be mathematically correct but not
necessarily physically justified.
3.1.5 New Approach ─ Data Pre- filtering and Parametric Curve Fitting
The new approach presented in this report includes two parts: data pre- filtering and parametric
curve fitting. As discussed in the last section, curvature derivation from splines, a non- parametric
cure- fitting approach, may not be able to be directly used by the ADAS applications. The main
27 of 133
difficulty lies in the discontinuity and high variance in the curvature estimates. Although a
possible remedy to the variance problem is adding some sort of filtering to the estimates from
splines, the discontinuity in the curvature estimates would be more difficult to resolve in that the
discontinuity could be a real road feature or it could be a result of positional inaccuracy. While
an arbitrary filtering process may lead to missed detection of a curve, an un- filtered discontinuity
due to ― noise‖ could also cause false detection.
The above two problems raise some fundamental questions: ― Is a non- parametric curve- fitting
method effective for curvature derivation?‖ And ― Is it possible that the shape of a road can be
modeled in such a way that the resultant road curvature can be correctly estimated in a piece- by-piece
fashion using this specific model assumption?‖ In addition, for time- critical applications,
computation efficiency is another important issue. Considering all the above factors, a parametric
curve- fitting approach that captures the ― dynamics‖ of road curvature as well as rejects the
― noise‖ from the road data is explored.
Figure 3- 4 depicts the concept of this new approach. As shown in this figure, a vehicle is
traversing a curve with speed V ( at C. G.). This curve consists of several nodes, N1, N2 and N3,
recorded in the digital map. For simplicity, the steady state curvature is of our interests, i. e.
R1= R2= R3, C is the center of curvature, and Rv represents the turning radius of the vehicle.
Assuming further that this vehicle is in quasi steady state, namely, the magnitude of V is constant
and the center of turning radius ideally matches the center of road curvature C. Therefore, one
can easily computed the radius of road curvature and curvature center based on the node
positions N1, N2 and N3 regardless of positional inaccuracy. The safety speed can then be
predicted based on the estimated curvature and the desired lateral acceleration before entering
this curve.
As a matter of fact, drivers normally approximate the road curvature ahead based on the visible
lane stripes and regulate the vehicle trajectory accordingly. The main idea of this new approach
is to model the road shape from a driver‘ s perspective. Since a vehicle at a fixed steering angle
and constant speed follows a constant arc, a road curve can then be consisted of one or several
arcs, and each arc ( a portion of the circumference of a circle) has a constant curvature. For a
straight road, the arc has an infinity radius of curvature. If the curvature of each arc can be
identified, for example, by fitting the circle function as in Equation ( 1), to the node positions of
arc, the road curvatures can then be obtained piece by piece. Hence, the road curvature
estimation is rendered to be a ― circle search‖ problem, which is realized by the Circle Center
Search algorithm presented below in Figure 3- 4.
However, position inaccuracy may still impede the direct use of the curvature estimates by the
CCS algorithm. Therefore, the CCS algorithm is used together with the Circle Selection
algorithm for data pre- filtering, i. e. curve- detection and curve- point selection. Based on the
preliminary curvature estimates including curvature centers and radii of curvatures, a parametric
curve fitting is employed to optimize the curvature estimates using a circle function. Figure 3- 5
shows the overall processes of the proposed curve reconstruction method.
28 of 133
Figure 3- 4: Concept of Circle Center Search algorithm
Figure 3- 5: Proposed road curve reconstruction method
3.1.6 Data Pre- Filtering by Circle Center Search ( CCS) and Circle Selection
( CS) Algorithms
Figure 3- 6 shows the satellite picture ( from Google map) of the ramp. This curve can be roughly
divided into two arcs with different radii of curvatures. The radius of initial portion is around 63
meters, and the curvature radii of the latter portion are greater than 90 meters. Figure 3- 7( a)
shows the preliminary curvature estimates by CCS algorithm. Blue stars are the so- called ― node‖
data in a commercial digital map, and they are located on the road center line. The first node at
entrance is circled in read. Red stars are the preliminary curvature center estimates, and each one
29 of 133
is computed based on three consecutive nodes. The resultant estimates of curvature radii are
shown in Figure 3- 7( b).
Several interesting phenomena can be observed from Figure 3- 7( a) and Figure 3- 7( b): ( 1) the
first six curvature center estimates are distributed in a relatively small region, i. e. they appear to
converge to the true curvature center, ( 2) the last six curvature center estimates appear to diverge
from the average position of the first six ones, ( 3) the first six curvature radius estimates vary
around the average value of 65 meters within the 10 meter bound, ( 4) the seventh to ninth radius
estimates appear to have a different average value of 95 meters, and ( 5) the radius estimates
jump from 96 meters to 136 meters in the last portion. ( Note that the last three radii are identical
due to using the same three nodes in CCS computation. If the nodes of the straight road in
connection with the curve end are used, the curvature radius estimates will diverge.)
In this example, the whole ramp can be divided into two parts. The first curve consists of the first
to the sixth nodes, and the second curve is between the sixth and the last nodes. Since the ramp
end is connected to a straight road, curvature of the second curve is not stationary. However, the
errors appear to be within an acceptable range for application use after further process by
parametric curve fitting discussed below.
Figure 3- 6: Exit ramp from northbound I- 580 to Bayview Ave. ( Google Map)
( a) ( b)
30 of 133
Figure 3- 7: ( a) Preliminary Curvature Estimates by CCS Algorithm ( b) Preliminary Estimates of Curvature
Radii by CCS Algorithm
The main idea of Circle Selection algorithm is to group proper nodes based on the preliminary
curvature radius estimates by CCS algorithm. By detecting relative large difference between two
consecutive radius estimates, a discontinuity of road curvature and the connection node between
two curves can be identified. The thresholds for detecting curvature discontinuity can be defined
in terms of absolute radius difference or relative radius difference depending on ( 1) the desired
sensitivity determined by the application need and ( 2) the map quality in terms of ― relative
accuracy‖ as well as the number of nodes on a curve. In general, thresholds defined in terms of
― relative difference‖ can better fit high sensitivity demanding application using high quality map.
In summary, the CCS and CS algorithms function as a nonlinear filter, which can be used to
detect a road curve and distinguish road curvature differences. However, for more accurate
curvature estimates, further parametric curve- fitting is required as described below.
3.1.7 Parametric Curve- Fitting
Based on the previous data pre- filtering results, the selected node positions ( xi, yi), i = 1~ n, of
each portion of curve are used in the curve- fitting. The objective function J for the curve- fitting
is defined in Equation ( 1):
2 2 2
J ( x x0) ( y y0 ) R ( 1)
By minimizing this objective function using ( xi, yi), the position of curvature center ( x0, y0) and
radius of curvature R can be estimated.
Figure 3- 8( a) shows the optimized curvature estimates for the ramp. It shows clearly that this
ramp can be divided into two curves as suggested earlier in Figure 3- 8. Although the last node,
which is a connection point with a straight road, is taken for the second curve- fitting, it does not
noticeably affect the fitting result. The enhanced curve radius estimates are quite accurate as
shown in Figure 3- 8( b).
( a) ( b)
Figure 3- 8: ( a) Optimized estimates of road curvatures through parametric curve- fitting ( b) Optimized
estimates of curvature radii
31 of 133
Another example is carried out for an on- ramp from Marsh Road to southbound US 101 as
shown in Figure 3- 9. This example shows a more complete ramp that can be divided into three
parts. The first and the last portions are straight roads, and the intermediate part is one curve with
radius of curvature of about 37~ 38 meters. Figure 3- 10( a) and Figure 3- 10( b) show the
preliminary curvature estimates by CCS algorithm using the map data from the existing
commercial digital map. The curvature center estimates of the intermediate portion are
distributed within the ramp except two nodes due to the undulation of the curve shape. The result
also reflects that the map quality is an important factor for the threshold design of the CS
algorithm. Figure 3- 10( b) shows that the curvature radius estimates appear to converge in the
direction from ramp entrance to the intermediate portion and diverge in the direction toward the
ramp end. The optimized curvature estimates are shown in Figure 3- 11( a) and Figure 3- 11( b).
Figure 3- 9: On ramp from Marsh Rd. to southbound US 101 ( Google map)
( a) ( b)
Figure 3- 10: ( a) Preliminary curvature estimates by CCS algorithm ( b) Preliminary estimates of curvature
radii by CCS algorithm
32 of 133
( a) ( b)
Figure 3- 11: ( a) Optimized road curvature estimates through curve- fitting ( b) Optimized curvature radius
estimates
3.1.8 Curve Overspeed Warning Experiment
This section presents a preliminary result of a prototype curve overspeed warning application
using an experimental ADAS system at the California PATH Program. Currently, the on- board
experimental system integrates GPS measurements, available vehicular sensors ( e. g., odometer,
gyroscope, and accelerometer), and digital map for safety applications in an autonomous mode.
Incorporating the vehicle- infrastructure communication into this system platform for further
performance enhancement is one of the on- going tasks in the project and left for future
discussion.
The proposed dynamic curvature estimation algorithm was implemented in the experimental
system and tested in real- time at the Richmond Field Station test tracks. Figure 3- 12 shows one
test result on a curve in one of the test track where GPS satellites are not available due to the
surrounding tall trees. The safe speed for negotiating this curve is 9.3 m/ s as computed by the
COWS algorithm in real- time. The experiment showed that the COWS system did provide
appropriate warnings when it detected the vehicle speed was unsafe for an upcoming curve based
on both the positioning system and the map information. Figure 3- 13 shows the corresponding
vehicle speeds, number of satellites used in position computation, and the HDOP of GPS. When
approaching this curve, GPS speed was constant due to satellite signal outage. The wheel speed
was higher than the safety speed between 163~ 165.3 seconds, and the speed warning was
activated. After the vehicle was slowed down, the warning was automatically turned off by the
system.
One can also see that the satellite signal outages did adversely affect the EKF- based GPS/ INS
position accuracy. A position enhancement method through sensor fusion of digital map was
developed to address this issue; however the development is not yet finished and therefore was
left for the future report. Figure 3- 12 does show that the enhanced EKF- based positions have the
potential to achieve the desired ― lane- level‖ positioning requirement.
33 of 133
Figure 3- 12: Example of COWS Field Test at the RFS Test Track
Figure 3- 13: Vehicle speed and GPS condition when approaching the curve ( when the GPS is in outage, the
resultant HDOP is set to zero by the GPS receiver)
3.1.9 Conclusion and Future Work
34 of 133
This report describes the general framework of a Curve Overspeed Warning System and presents
a dynamic road curve reconstruction method using the existing map database information for this
specific application. The curve attributes computed by this approach appear to be better than
those from the conventional spline approach.
This new approach following a typical stochastic estimation approach by combining a data pre-filtering
and parametric curve- fitting function under the assumption that the characteristics of
road curve can be modeled in terms of various connecting ― circles.‖. Under this assumption, any
given road curve consists of a number of connecting arcs where each arc corresponds to a
specific circle. If each of these circles can be identified, the correct curvatures along this curve
can therefore be derived. In order to deal with the positioning inaccuracy in the map data, the
parametric curve fitting is conducted based on this circle model. Data pre- filtering ( that detects
curvature changes as well) selects specific ― nodes‖ of each identified circle, which is conducted
by the proposed Circle Center Search and Circle Selection algorithms, while curve- fitting is
utilized to remove the variance in the curvature estimates.
Preliminary experimental results demonstrated that this prototype COWS achieved the basic
performance requirements for a purely map- based COWS without involving vehicle-infrastructure
communication. To achieve the optimal system performance, the enhanced map
data and dynamic road information was incorporated into the COWS computation through VII.
The future work to accomplish the VII COWS is summarized below.
1. Develop a robust position enhancement module based on current scheme, so that the
GPS- based positioning unit can still achieve ― lane- identification‖ accuracy as GPS
differential correction is not available.
2. Develop the on- board wireless communication module.
3. Develop the DSRC map information message format.
4. Incorporate the enhanced map data and dynamic road information transmitted from the
RSE into the COWS algorithms.
5. Develop the required software and hardware for vehicle- infrastructure communication.
6. Develop the vehicle- to- infrastructure information feedback mechanism for event, hazard
or accident detection.
4 Transition VII California Proof of Concept Testbed
to US DOT Development Test Environment
4.1 Build and Expand Testbed
An expanded VII California testbed was designed to accommodate emerging US DOT
POC and DTE requirements. Elements of the design will include determination of the adequacy
of the RSE locations and site characteristics determined to date. The likely scenario was to fulfill
the Roadside Equipment ( RSE) network already determined under prior effort. Also investigated
under this task was transition of RSE components to DTE requirements, with most of the focus
35 of 133
replacement of the Denso WRM for candidate sites into POC DSRC transceivers. As part of this
task, an experimental RSE, complete with intersection state capabilities was installed at the
PATH Richmond Field Station ( RFS) ― intelligent intersection‖ for use in testing and
demonstration.
4.2 Examine Suitability of HA- NDGPS
The California PATH program and Caltrans have a number of research applications that can
benefit from a high- accuracy vehicle positioning implementation. The U. S. Department of
Transportation and U. S. Coast Guard in conjunction with the Interagency GPS Executive Board
are currently developing a High Accuracy- Nationwide Differential Global Positioning System
( HA- NDGPS), targeted at a variety of transportation- related applications. The HA- NDGPS
program provides the capability to broadcast corrections to the Global Positioning System ( GPS)
over long ranges to achieve accuracy better than 10 centimeters ( 95 percent of the time)
throughout the coverage area. HA- NDGPS is currently undergoing a research and development
phase with a future implementation pending U. S. congressional budget approvals. Application of
this technology will provide advanced safety features for transportation, including applications
such as lane departure warning, intersection collision warnings, and railroad track defect alerts.
The California VII Program has established a testbed in the San Francisco Bay area that is being
utilized for a variety of experiments. With the integration of vehicle and roadside
communications ( DSRC), the determination of vehicle location has become a critical component
for several VII applications. One of the key objectives of this study is to demonstrate that the
existing VII communication infrastructure ( i. e., Dedicated Short Range Communications
( DSRC), roadside equipment) can be utilized where possible for broadcasting corrections to the
vehicles‘ GPS receivers. This eliminates the need to depend on other communication methods to
receive correction signals, resulting in greater control and lower costs. This architecture
compliments the potential use of existing DGPS broadcast networks such as the California
statewide CORS, NDGPS, and/ or NGS.
The architecture of the local base station integrated with the VII communications infrastructure
provides both a low- cost lane- level positioning solution with the potential to upgrade to
centimeter- level accuracy using carrier phase receivers that could be installed in a subset of
vehicles. The pseudorange and carrier phase corrections could both be broadcast over the RSE
DSRC transceivers or through an alternative wireless network. While this integrated approach
has not been developed commercially, the methodology and experimentation ( described in this
report) has shown to be viable through similar university research programs. Initial integration
may consist of only code corrections while future implementations could add carrier phase
corrections with only software changes to be made in the base station and RSE hardware.
This study has implemented the DGPS/ DSRC architecture and demonstrated the feasibility of
broadcasting the DGPS code corrections over the DSRC network. Initial performance
evaluations were completed to demonstrate the potential performance of the architecture. While
initial performance has demonstrated the architecture to be successful for lane- level positioning
applications requiring differential corrections, additional enhancements would be required for
deploying the architecture beyond specific testbeds, pilots, and demonstrations. These
enhancements would allow for a more commercially viable solution to improving GPS positional
accuracies. Several research goals were achieved with this evaluation:
36 of 133
Comparison of positioning performance using NDGPS corrections transmitted via beacon
and via Internet – correction quality and positional accuracy has been demonstrated to be
dependent on prompt acquisition of a DGPS correction message. The DGPS signal
transmission via internet has been evaluated for TCP/ IP transmission with a DSRC link
to the rover vehicle. Rapid and effective acquisition of a DSRC link is critical for
receiving DGPS corrections within a single cell DSRC coverage area;
Potential of transferring HA- NDGPS corrections to standard formats – this study has
reviewed and evaluated the protocols, formatting, and transmission of high accuracy
signals. The HA- NDGPS protocol performs a message compression/ decompression
sequence which does not degrade the quality of the original RTCM correction message.
Integration potential of alternative correction signals ( RTK, WAAS, CORS etc.) – tests
scenarios completed within this study have demonstrated that the DSRC/ Ntrip
architecture is compatible with any RTCM correction messages. Receivers capable of
processing multiple sources of corrections can utilize alternate corrections in addition to
corrections received via DSRC/ Ntrip.
Integration of HA- NDGPS receivers within CA VII vehicles/ applications – the
HANDGPS protocols have been found to provide a RTCM compatible correction which
is suitable for any L1/ L2 receiver accepting RTCM carrier phase corrections. Specifically
configured receivers are not necessary if broadcasts are transmitted via TCP/ IP protocols
( DSRC/ Ntrip).
Geographical distribution accuracy requirements of corrections signals ( regional,
intersection- only, highway- only etc) – the range and performance of a single DSRC
transmission site was evaluated. Performance was found to be greatly dependent upon the
rate of acquiring a DSRC communication link;
Frequency requirements of correction signals – the frequency of transmitting a correction
signal was maximized for performance within the scope of this study. Decreasing the
frequency would be possible for regions of continuous or semi- continuous DSRC
coverage; and,
Compatibility of RSE/ DSRC system design with correction signal size, frequency,
format, and vehicle densities – the current study results did not find limitations due to
DSRC communication bandwidth. DSRC communication and position quality was
limited primarily by DSRC coverage area.
The next step towards a final integration would be to create compatible software that would
determine availability of suitable regional corrections and autonomously initiate transfer. The
current architecture requires a manual selection of DGPS base stations. This future development
would focus on these following components:
37 of 133
A review and collaboration with entities maintaining DGPS broadcast networks to
establish agreements for automated downloads;
Create software that evaluates current location and searches for spatial- appropriate and
available correction messages;
create software that automatically adjusts configuration settings of DGPS Ntrip
communications; and
Implement and test the automated architecture in specific VII applications.
Successful implementation of this automated DGPS acquisition architecture would greatly
simplify the methodology of acquiring DGPS corrections and provide improved positioning
performance of future ITS implementations.
4.2.1 GPS
The Global Positioning System ( GPS) is one of the most convenient and accurate methods for
determining a vehicle‘ s position within a global coordinate system [ Farrell & Barth, 1999;
Farrell & Givargis, 2000]. Utilization of a GPS receiver has become the most prominent method
of determining the physical location of a vehicle. A detailed and concise description of GPS is
provided in [ Farrell & Barth, 1999]. The system is built around a set of 24 satellites ( with
additional, spares, replacements, upgrades) that orbit the Earth. The orbits are designed in a
manner that allows the signals from at least four satellites to be received simultaneously at any
point on the surface of the Earth ( neglecting obstacles such as tunnels, urban canyons, dense
forest etc.). A GPS receiver on the surface of the Earth utilizes the signals from at least four
satellites to determine its own antenna position ( x, y, z) according to various measurements of
the pseudoranges between the satellites and the receiver antenna. The receiver measurements
include various code- based pseudoranges and potentially carrier phase information. The standard
deviation of uncorrected GPS position estimates is on the order of 10- 20 meters. Increased
accuracy better than 3 meters can be achieved through the use of code- range based differential
GPS ( DGPS) techniques, such as those described in [ Navstar, 1991; Kee, 1994; Blomenhofer,
1994; and Farrell & Barth, 1999].
Satellite transmission of orbital position ( ephemeris), timing, and satellite status data to GPS
receivers is known as ‗ code,‘ and measurements of the distance between the satellite and the
receiver using this ‗ code‘ information are called code- based measurements. The GPS receivers
utilize the ephemeris data to calculate the positions of each satellite. With the position of a
satellite known, the distance between the receiver and the satellite ( called the pseudorange) can
be determined using the propagation delay of the signal. When the distance between a receiver
and at least four distinct satellites is known, a position lock can be obtained [ Bajikar et al.,
1997].
Most low- cost GPS receivers are single frequency L1 ( 1575.42 MHz) C/ A code sensors, which
measure the distances between a receiver and satellites and estimate the receiver‘ s antenna
position based on these pseudorange measurements. Given the range standard deviation of
common- mode noise on the order of 10 – 20 meters [ Farrell & Barth, 1999] and non- common
mode noise at order of 0.1 to 4.0 meters [ Farrell & Barth, 1999; Farrell & Givargis, 2000], a
standalone GPS receiver has a horizontal standard deviation of position error around 20 meters.
38 of 133
This accuracy is sufficient for the road- network- level navigation of route finding/ planning and
guidance, which usually positions the vehicle at street level with the assistance of map matching
algorithms. Most of the current existing vehicle navigation systems utilize the GPS receivers that
are in this category.
In terms of vehicle spatial positioning, a standard GPS receiver with the accuracy of 20 meters
coupled with map matching has performed well over years in the route guiding navigation
systems. More accurate vehicle navigation, such as differentiating the vehicle‘ s lane, requires
higher accuracy positioning capability. Positioning systems of centimeter- level accuracy for
vehicle operational control, e. g., GPS coupled with Inertial Navigation Systems ( INS), have been
tested over years and demonstrated sufficient performance in the control applications. However,
they are currently too expensive for general navigation or lane- level VII applications. Improved
accuracy can be obtained by using differential GPS techniques to remove the common- mode
error from the measurements, making the standard deviation of the error small enough to satisfy
the lane- level accuracy requirements. Increasing accuracy beyond the lane level requires
additional corrections such as carrier phase corrections and/ or dual channel corrections.
It is apparent that a low- cost positioning system capable of discriminating between lanes is
needed for lane- based VII applications, requiring approximately 1 to 2 meter level accuracy. A
DGPS system that uses carrier- phase based range observations can provide accuracy up to 1- 3
centimeters, however these receivers require dual frequency reception and additional algorithms
to solve integer ambiguity issues, resulting in significantly higher cost ( see, e. g., [ Navstar, 1991;
Blomenhofer, 1994; Farrell & Givargis, 2000]). Vehicle applications requiring lane- level
accuracy ( 2 meters) can potentially utilize a low- cost GPS receiver coupled with other on- board
electronics and firmware to increase the accuracy. These lower cost configurations require the
use of differential corrections originating from a base station in relatively close proximity.
4.2.2 Differential GPS and Carrier- Phase GPS
Several sources of error contribute to calculation inaccuracies of the pseudoranges, including
satellite clock bias, atmospheric delay, ephemeris prediction data, and receiver tracking error
noise [ Bajikar et al., 1997]. These errors are frequently referred to as the ‗ common mode errors‘
because they are common to all receivers in a local (< 50 km) area. Because these errors are
common to all receivers in a local area, they can be eliminated through differential GPS ( DGPS).
Utilizing a stationary base station receiver whose position has been accurately surveyed,
common mode errors can be determined for the local area surrounding the base station. The
methodology of transmitting these local errors to nearby mobile receivers ( rovers) forms the
basis of a differential GPS architecture. A breakdown of GPS and DGPS errors are provided in
Table 4- 1.
There are three primary types of DGPS position corrections that can be provided by the base
station: code ( or range- space), carrier- phase, and Doppler corrections. Within the context of this
study, code and carrier- phase corrections are described. Carrier- phase corrections, which
typically produce centimeter level accuracy, are traditionally achieved with post processing
algorithms while code- based DGPS corrections are frequently utilized for real- time applications,
resulting in 2- 3 meter accuracy. However, it is possible to also transmit carrier- phase correction
in real time, resulting in what is called Real Time Kinematic ( RTK) positioning.
For code- based DGPS, the base station receives the satellite signals and calculates the common
mode errors from each satellite, using the known accurate position of the base station. Once the
common mode errors for a given time instant are known, they can be transmitted to all receivers
39 of 133
within a local area. The rover receivers subtract these transmitted common mode errors for the
satellites in its view to calculate its position, resulting in a typical accuracy of 2- 3 meters. The
accuracy is also influenced by the age of the correction, which is the time between the base
station‘ s calculation of the errors and the receiver‘ s calculation of its position. To maintain the
accuracy integrity, correction updates are typically needed at least every 10- 15 seconds [ FHWA,
2005; Barth et al., 2005].
Table 4- 1: Summary of GPS Error Sources. [ Trimble, 2006].
The carrier frequency is used for transmitting the code- based signal from the satellite to the
receiver. Carrier- phase DGPS functions through phase measurements of the carrier signal,
detecting the change in the number of carrier cycles between the receiver and a given satellite.
The total number of carrier cycles between the receiver and a given satellite multiplied by the
carrier wavelength can provide a more accurate measurement of the range. An ‗ integer phase
ambiguity‘ arises when the total number of carrier cycles is not known; only the change in this
total number of cycles can be directly observed. If the code measurement can be made accurate
to within a few meters, then there is only a few wavelengths of the carrier signal to consider to
determine which cycle really marks the edge of the carrier frequency timing pulse. Resolving
this carrier phase ambiguity for just a few cycles is a much more solvable problem and with
increasing processing power and functionality, it‘ s possible to make this kind of measurement in
real time. In this method, the common mode errors are identical to the common mode errors
encountered in the code- based measurements, but the non- common mode errors are
approximately 100 times smaller than their corresponding errors in the code- based
measurements. Eliminating the common mode errors with code and phase corrections, it is then
possible to achieve centimeter- level accuracy using carrier- phase DGPS.
The process of transmitting carrier- phase corrections in real time from a localized based station
to a rover receiver capable of processing carrier- phase corrections is commonly referred to as
Real Time Kinematics ( RTK). The RTK methodology is commonly utilized by the survey
industry to achieve accurate geographic positions within a localized area. While the traditional
survey techniques have typically required the rover receiver to be stationary for several minutes
to achieve centimeter level accuracy, improved methods are allowing for real time, second-bysecond,
carrier- phase corrections. Table 4- 2 summarizes the correction techniques and their
accuracies.
4.2.3 Real- Time Differential Corrections
Several industry standard DGPS correction signals have been implemented for various
differential services, including RTK. Differential correction formats were created for marine,
aviation, navigation, and proprietary systems. The most frequently utilized correction streams
that are non- proprietary are termed:
40 of 133
a) RTCM- 104, and
b) RTCA- 159 ( WAAS)
Table 4- 2: Summary of GPS signal correction methods. [ Magellan, 2006].
Many GPS receivers are ― RTCM- capable‖ meaning they accept DGPS correction messages
through a real- time data communication link ( e. g., VHF or UHF radio, cellular telephone, FM
radio sub- carrier, or satellite com link). The Radio Technical Commission for Maritime Services
Special Committee 104 recommended standards for DGPS correction messages, which have
become termed RTCM- 104. Several versions exist which include the recent addition of message
types 18/ 19/ 20/ 21 for carrier phase solutions such as RTK. For RTK applications, RTCM
version 2.1 provides Type 18 ( carrier phase raw data) or Type 20 ( carrier phase corrections).
Radio Technology Committee for Aviation Special Committee 159 developed minimum
standards that define the basis for FAA approval of equipment using GPS for aircraft navigation
in the United States. The RTCA DO- 229 document entitled ― Minimum Operational Performance
Standards for Global Positioning System/ Wide Area Augmentation System Airborne
Equipment‖ was prepared by Special Committee 159 in 1996. It contains the standards for
airborne navigation equipment using GPS augmented by a Wide Area Augmentation System
( WAAS).
As described previously, several proprietary differential data streams exist including systems
such as Starfire, and Omnistar. While these systems may be adaptable for VII applications, it is
presumed that an open architecture method is preferred for achieving the accuracy requirements
desired. Similarly, numerous proprietary survey grade (< 5cm) DGPS systems exist which could
be modified to meet VII requirements, but have also received limited focus due to proprietary
correction signals that would become an issue for VII implementation. While the GPS industry
has integrated WAAS and RTCM ( RTK capability) corrections into many receivers, there is a
third DGPS correction architecture evaluated in this study, referred to the National Differential
GPS ( NDGPS) architecture. Greater detail is provided on WAAS, RTK, and NDGPS correction
methodologies below.
4.2.4 Wide Area Augmentation System ( WAAS)
The Federal Aviation Administration ( FAA) developed a Wide Area Augmentation System to
transmit satellite based DGPS correction signals for civil aviation. WAAS utilizes a network of
41 of 133
precisely- located ground reference stations that monitor GPS satellite signals. These wide- area
reference stations ( WRS) are located throughout the continental United States, Hawaii, Canada,
Mexico and Alaska. These stations collect and process GPS information and send this
information to WAAS Ground Uplink Stations ( GUS). The WAAS ground uplink stations
develop a WAAS correction message that is sent to user receivers on the L1 transmission signal
via geostationary satellites. Using WAAS, GPS signal accuracy is improved from 20 meters to
approximately 3 meters in both the horizontal and vertical dimensions.
WAAS reached initial operational capability for aviation use on July 10, 2003 as the first of
several Space- Based Augmentation Systems ( SBAS) being developed throughout the world and
is compatible with all other international satellite- based augmentation systems. Although the
WAAS was designed for aviation users, it supports a wide variety of non- aviation uses including
agriculture, surveying, recreation, and surface transportation. The WAAS signal has been
available for non safety- of- life applications since August 24, 2000, and numerous manufacturers
have developed WAAS- enabled GPS receivers for the consumer and OEM market.
The next phase of WAAS is referred to as the Global Navigation Satellite System Landing
System ( GLS) segment. The GLS phase of WAAS is scheduled to coincide with the operational
capability of GPS modernization and is scheduled to be completed in 2013. GLS will utilize, and
depend upon, improvements that the Department of Defense ( DoD) will make as part of its GPS
modernization program. GPS modernization will improve WAAS performance during periods of
severe solar storm activity and provide additional security against interference to the GPS.
4.2.5 Real Time Kinematic ( RTK) and CORS
RTK is a process where carrier- phase GPS signal corrections are transmitted in real time from a
reference receiver at a known location to one or more remote rover receivers. The use of an RTK
capable GPS system can compensate for atmospheric delay, orbital errors and other variables in
GPS geometry, increasing positioning accuracy up to and sometimes within a centimeter. Used
by engineers, topographers, surveyors and other professionals, RTK is a technique employed in
applications where high precision is necessary. RTK is used, not only as a precision positioning
instrument, but also as a core for navigation systems or automatic machine guidance, in
applications such as agriculture, civil engineering, and dredging. It provides advantages over
other traditional positioning and tracking methods, increasing productivity and accuracy. Using
the code and carrier phase of the GPS signals, RTK provides differential corrections to produce
the most precise GPS positioning.
The RTK process begins with a preliminary integer ambiguity resolution. This is a crucial aspect
of any kinematic system, particularly in real- time where the velocity of a rover receiver should
not degrade either the achievable performance or the system¡ ¦ s overall reliability. The base
station is responsible for assembling the base station carrier phase correction message, which
aids the receiver in solving the integer ambiguity. With integer ambiguity solved, the receiver is
capable of centimeter level accuracy at frequencies of 1 Hz.
With increased prevalence of centimeter level applications, RTK correction messages are being
integrated within a network of reference stations. The National Geodetic Survey ( NGS), an
office of the National Oceanic and Atmospheric Administration¡ ¦ s ( NOAA) National Ocean
Service, coordinates two networks of Continuously Operating Reference Stations ( CORS):
- the National CORS network; and,
- the Cooperative CORS network.
42 of 133
The national CORS network is operated, managed, and maintained through NGS agreements
with site data available through NGS; while the Cooperative CORS is a network of independent
equipment operators each responsible for their own data collection, storage, and
transmission. Each CORS site provides GPS carrier phase and code range measurements in
support of 3- dimensional positioning activities throughout the United States. Currently, only a
small portion of the sites provides real time ( 1 Hz) correction data capable of supporting RTK
applications.
The CORS system benefits from a multi- purpose cooperative structure involving many
government, academic, commercial and private organizations. New sites are evaluated for
inclusion according to established specifications and criteria. Cooperative CORS data are
available from the participating organization that operates the respective site. Specific to
California, an additional collaborative effort has evolved to operate and maintain reference
stations with real time correction capability.
The California Spatial Reference Center ( CSRC) is operated through the Cecil H. and Ida M.
Green Institute of Geophysics and Planetary Physics at UCSD‘ s Scripps Institution of
Oceanography. In partnership with surveyors, engineers, GIS professionals, the National
Geodetic Survey, the California Department of Transportation, and the geophysics community,
CSRC has developed a plan to establish and maintain a network of GPS control stations
necessary to meet the demands of government and private businesses for a reliable spatial
reference system in California.
CSRC has had significant influence on the implementation, development, and operation of
reference stations in and around Southern California. The implementation of these sites has
predominantly been associated with geophysics ( earth crust movements) and municipal survey
requirements. The real time data requirements for these applications are compatible with RTK
data requirements.
4.2.6 United States Coast Guard National Differential GPS System
Another system for providing differential corrections is the U. S. Coast Guard‘ s Nation- wide
Differential Global Positioning System ( NDGPS). This service is a land- based differential
correction system that receives and processes signals from orbiting GPS satellites, calculates
corrections from known positions, and broadcasts these corrections via a Medium Frequency
( 307 kHz) beacon transmitter to DGPS users in the broadcast site‘ s coverage area [ Wolfe et al.,
2000].
As the DGPS concept was being developed in the late 1980‘ s, a variety of alternate methods to
enhance the accuracy and integrity of GPS through differential correction were considered. The
motivation that guided development of the USCG NDGPS service were redeployment of
decommissioned radio beacon sites distributed throughout the United States, availability of
radio beacon frequencies ( 285- 325kHz), and the need for harbor navigational aides [ USDOT,
2001]. NDGPS sites were engineered to broadcast applicable pseudorange corrections at 200 bits
per second or less up to a range of 450 km. At the time, the selective availability ( S/ A) dithering
error was the greatest error to correct, dwarfing other errors such as atmospheric, multipath,
algorithmic, and noise errors. Correcting for pseudorange errors allowed DGPS receivers to meet
the 10 meter accuracy requirement for positioning aids to navigation and for the 8- 20 meter
accuracy requirement for harbor and harbor approach ( H/ HA) [ USDOT, 2001].
Selective Availability was eliminated for GPS broadcasts on May 2, 2000, in accordance with a
43 of 133
Presidential Decision [ USPDD, 1999]. With GPS unencumbered by S/ A, GPS receiver accuracy
achieved dramatic improvements. DGPS receivers also benefited by the removal of S/ A by using
algorithms to correct remaining GPS errors, achieving accuracies of 1- 3 meters [ USDOT, 2001].
Atmospheric errors from the effects of the ionosphere, as well as the wet and dry portions of the
troposphere, are now the largest contributor of error to the GPS signal. While DGPS
pseudorange corrections effectively minimize these errors at the DGPS reference location, spatial
decorrelation degrades these corrections as the distance between the receiver and
reference station increases. Modeling techniques using real time monitoring show significant
potential to achieve sub- meter accuracies by supplementing the pseudorange corrections with
improved atmospheric models [ Gutman et al., 1999].
The NDGPS system is in the process of finalizing a nationwide network of DGPS broadcast sites
to provide dual terrestrial coverage in the continental U. S. Spatial decorrelation effects are
minimized by the utilization of these multiple reference stations. New generation DGPS
receivers take advantage of this dense network to compare the signals of multiple broadcast sites
to enhance positional accuracy. Data from multiple locations can be transferred to other locations
to rebroadcast or be combined at a central location and then rebroadcasted [ Last et al., 2002].
When the required coverage is met, DGPS users in the U. S. will possess signal availability of
better than the required 99.9% ( availability represents the percentage of time the DGPS signal is
usable). The NDGPS system provides users with broadcast messages as defined by the Radio
Technical Commission for Maritime Services ( RTCM) and utilizes Reference Station Integrity
Monitor ( RSIM) messages for intra- system communication [ RTCM, 2001a; RTCM, 2001b].
Figure 4- 1 shows the estimated coverage area for installed NDGPS sites as of 2009. Single
coverage regions ( gray areas) and regions where more than one signal is available ( yellow areas)
were identified using Millington‘ s method for determining ground wave signal strength [ USCG
NAVCEN, 2009]. Table 4- 3 gives the current status of California‘ s NDGPS broadcast stations.
Table 4- 3: Status of California NDGPS broadcast stations [ USCG NAVCEN, 2009].
44 of 133
Figure 4- 1: NDGPS coverage in 2009 [ USCG NAVCEN, 2009].
The U. S. Coast Guard developed the original NDGPS network. The U. S. Army Corps of
Engineers ( USACOE) needed similar capability along inland waterways and, with the help of the
USCG, established similar broadcast stations. USACOE later adopted the NDGPS concept and
developed additional stations. The US Department of Transportation ( USDOT) continues to
install NDGPS stations at retired Air Force Ground Wave Emergency Network ( GWEN) sites.
When all proposed installations are complete, there was approximately 137 similar stations
broadcasting Course/ Acquisition ( C/ A) code correctors to users. This will enable meter- level
positioning with an associated level of integrity, according to the Federal Highway
Administration [ FHWA, 2005].
These beacons today broadcast single- frequency GPS code range correctors enabling few- meter
level positioning and navigation along the U. S. coasts and inland waterways. An expected
pseudorange value is computed for each GPS satellite in view at the NDGPS sites. These
computed values are compared with the actual pseudorange measurements made at the sites; the
difference is known as a pseudorange corrector. The assumption is that the errors are common to
both the reference site and any user site. These correctors are placed in a formal bit stream with
message header, message type, and with parity considerations and broadcast to users as a Type 9
RTCM message. This message is one of many broadcast as part of the RTCM- 104 protocol
developed by the Radio Technical Committee for Maritime Services ( RTCM) [ FHWA, 2005].
Based upon the RTCM- 104 message, users are able to perform meter- level positioning in static
or moving applications. This message requires approximately 660 bits to send C/ A code
pseudorange correctors for 12 satellites. It should be noted that correctors are sent because
correctors are expected to require fewer bits than observations. Real Time Kinematic ( RTK)
45 of 133
techniques applied to this 200 baud system may not provide the accuracies of a traditional RTK
application, but may show merit in achieving decimeter level accuracies at a limited range from
the DGPS broadcast location.
The USCG and others are currently enhancing the NDGPS system, providing for higher
accuracy in the sub- meter range. This effort is referred to as the High Accuracy NDGPS
( HANDGPS)
system, which is described in greater detail in the following chapter.
The U. S. Department of Transportation approved a decision to continue the inland component of
the Nationwide Differential Global Positioning System ( NDGPS) on April 18, 2008. The
decision was based on the results of the NDGPS user assessment conducted by the Research and
Innovative Technology Administration ( RITA). RITA assessed the existing user needs and
systems requirements for the inland component of NDGPS. Information was gathered through
public response ( including responses from state and local governments, the private sector, and
the non- profit sector), and through quantification of the mission requirements of other federal
agencies using inland NDGPS.
To date, the US Coast Guard monitors and controls 38 operational NDGPS sites that belong to
the DOT. The Coast Guard is a key member of the seven- agency partnership for the Department
of Transportation‘ s NDGPS expansion initiative. The Coast Guard brings its expertise in
building, operating and maintaining DGPS sites to the partnership. The other members of the
NDGPS expansion initiative are the U. S. Air Force, the U. S. Army Corps of Engineers, the
Federal Highway Administration, the National Oceanic and Atmospheric Administration, the
Office of the Secretary of the Department of Transportation, and most recently appointed
sponsor for the project is the Research and Innovative Technology Administration ( RITA).
[ USCG NAVCEN, 2009]
The continued evaluation and expansion of the high accuracy ( HA) NDGPS concept has been
planned for 2008 and 2009. Currently, Hawk Run, PA; Hagerstown, MD; and the Topeka, KS
NDGPS sites are equipped to broadcast code and carrier phase observables under a test scenario.
Testing is expected to continue to support ongoing system development. Pueblo, CO is expected
to become the next HANDGPS broadcast site in FY 09. [ USCG NAVCEN, 2009]
4.2.7 DSRC Background
Dedicated Short Range Communications ( DSRC) is a general purpose RF communications link
between the vehicle and the roadside ( V2R), or between two vehicles ( V2V). The technology
draws upon the increasingly popular IEEE 802.11 Wi- Fi standard. Within the IEEE 802 context,
Wireless Access in Vehicular Environments ( WAVE) utilizes the DSRC technology for V2V
communication and V2R communications. The 802.11 efforts in WAVE applications are being
developed into the 802.11p standard. Equivalent efforts are occurring with the IEEE 1609
working group and standard for Dedicated Short Range Communications. The 802.11p and 1609
standards are for data- only systems and operate on radio frequencies in the 5,725 MHz to 5,875
MHz Industrial, Scientific and Medical ( ISM) band. The set of standards developed to support
this interface provide a short to medium range communications service for a variety of
applications, including public safety ( obstacle detection, collision warnings and avoidance,
intersection safety), commercial vehicle applications ( weigh- in- motion/ inspection clearances,
border crossing), electronic toll collection, parking lot payment, in- vehicle signing, and many
others.
46 of 133
DSRC technology provides secure, reliable communication links between vehicles and
infrastructure safety subsystems that can increase highway safety. The 5.9 GHz DSRC link uses
RF broadcast techniques to transfer data over short distances between roadside and mobile units,
between mobile units themselves and between portable and mobile units. This link enables
operations related to the improvement of traffic flow, highway safety, and other ITS applications
in a variety of application environments called DSRC/ WAVE. 5.9 GHz DSRC system requires
robust, fast, localized transmissions from vehicle¡ Vto- vehicle and roadside- to- vehicle to serve
the many public safety and private commercial applications. However, for high- speed vehicular
applications, significant changes were required to provide latency minimization, channel
switching/ prioritization, authorization, prioritization and anonymity without compromising
messaging integrity, correctness, privacy, & robustness attributes.
The National ITS Architecture has identified DSRC as a primary means of communicating
between the roadside and vehicles, and from vehicle- to- vehicle. There are a large number of
applications planned within the ITS domain, including collision avoidance, traffic management,
toll collection, transit operations, commercial vehicle operations, and traveler information. In
addition to these ITS applications, WAVE and DSRC are expected to support another set of
applications that would be of broader interest to motorists and those interested in providing
services to these motorists. Some of these applications would be using the DSRC device as a
means of connecting the vehicle to the Internet.
4.2.8 NTRIP Broadcasting Methods
Networked Transport of RTCM via Internet Protocol ( Ntrip) is an application- level protocol that
supports streaming DGPS corrections over the Internet. Ntrip is a generic, stateless protocol
based on the Hypertext Transfer Protocol HTTP/ 1.1. Ntrip supports wireless Internet access
through Mobile IP Networks like GSM, GPRS, EDGE, or UMTS.
Ntrip consists of three system software components: NtripClients, NtripServers, and
NtripCasters:
- NtripServers - transfer the data streams from a source to the NtripCaster;
- NtripCaster - the major system component; and
- NtripClients - receives data streams of desired NtripSources on the NtripCaster.
The NtripCaster is the actual HTTP server program, while NtripClient and NtripServer act as
HTTP clients. Figure 4- 2 provides a line drawing of the Ntrip architecture.
47 of 133
Figure 4- 2: Ntrip architecture [ GNSS Data Center, 2009].
NtripServers define a source ID called ― mountpoint‖ for every streamed NtripSource. Several
NtripClients can access the data of desired NtripSources at the same time by requesting a source
by its mountpoint on the NtripCaster. If implemented in the NtripCaster program, authorized
personnel may remotely control the NtripCaster via a password- protected Telnet, VPN, or
receive status information via a password- protected HTTP session using an Internet Browser. An
administrator running an NtripCaster is responsible for allowing new NtripServers to connect
with new NtripSources. The administrator organizes all available NtripSources and defines all
source IDs ( mountpoints).
NtripClients must be able to choose an NtripSource by its mountpoint on the NtripCaster.
Therefore a source- table is introduced into, and maintained on, the NtripCaster. Each record of
this source- table contains parameters describing attributes of a data stream, a network of data
streams, or an NtripCaster. Stream attributes ( identifier, coordinates, format, nav- system,
mountpoint, etc.) are defined at the NtripServer side for each NtripSource.
4.2.9 Integration of DSRC and NTRIP
4.2.9.1 Hardware Architecture of DSRC/ NTRIP Broadcasts
The transmission of DGPS corrections requires the integration of numerous hardware
components which aid in minimizing transmission delays and promote reliable communication.
Figure 4- 3 shows the hardware and communications architecture for the integration of DSRC
and
Ntrip DGPS broadcasts.
The architecture consists of the following components:
- Base station receiver - dual channel carrier phase receiver ( Trimble 5700);
- Ntrip server computer – networked windows computer capable of running Ntrip server
program;
- Ntrip caster – networked computer capable of running as a server;
48 of 133
- DSRC RSE – combination of DSRC transceiver, internet backhaul, and support
equipment;
- OBE – rover GPS receiver, mobile DSRC, computer capable of running Ntrip client; and,
- Misc. – GPS transmission, antennas, cables, connectors and power sources.
Figure 4- 3: Ntrip/ DSRC hardware architecture
The GPS base station consists of a GPS receiver, computer, GPS base station antenna, high
speed internet connectivity, backup p