VIICalifornia 8 4 06

VII California Team Meeting: 

VII California Team Meeting August 4, 2006 Metropolitan Transportation Commission

Agenda: 

Agenda RSE Status         -- New RSE @ SR 82 and 5th Ave         -- potential other CICAS-V RSE on SR 84 Network and backhaul:  progress and plans         -- Backhaul Status: T1 and 3G         -- Monitoring Sniffer installation imminent         -- next steps:  hardware, software, use CFS BAH visit (and prospective relationship with POC)        -- Recent Events/Decisions from VII Coalition Update:  HA-NDGPS (UCR work) Creation of VII Calif Website:  soliciting content ideas Applications work         -- intersection message set (in conjunction with Sniffer)         -- curve over speed warning (Kang Li, Han-Shue Tan)         -- TBD others but at least probe application (Steve Shladover) APTA Demo in October

RSE: 

RSE

RSE Status (Informational): 

RSE Status (Informational) New RSE in conjunction with CICAS-V CICAS-V desires installation/operation by ~ October Proposed locations: SR 84 (Woodside Road) and Alameda de as Pulgas SR 82 (El Camino Real) and 5th Ave (Atherton) Others may be requested Still to do: Design to integrate TechnoComm RSE Mounting Electrical and data interface Caltrans approval Integration design Structural (mounting) Others? On El Camino Real On Freeways? (See Curve Overspeed slides)

Slide5: 

Backhaul Status

Slide6: 

T1 Installation at SR82 and California Avenue

Slide7: 

Proposed T1 Sites

3G Migration Path: 

Junxion Box only supported 115kbps Aircard 860 HSDPA PCMCIA Card MB8000 also had limitations with the 860, so we tried a Verizon Aircard. Airlink Raven over EvDO through Verizon 3G Migration Path

3G Service: 

3G Service GPRS Bandwidth ~40kbps EvDO Raven w/Ethernet port (Verizon) Bandwidth ~400 - 600 kbps Airlink Raven – 3G network through an Ethernet port

3G Migration Path: 

3G Migration Path Junxion Box only supported 115kbps Aircard HSDPA PCMCIA Card MB8000 also had limitations with the 860, so we tried a Verizon Aircard. Airlink Raven over EvDO through Verizon Benefits of a Bridge

Monitoring: 

Monitoring

Sniffer: 

Sniffer

Sniffer layout: 

Sniffer layout

Sniffer status: 

Sniffer status Prototype board built and currently being tested Signal status successfully input into computer Near instanteous reading of signal

Current and near future work: 

Current and near future work Reliability testing of sniffer over long periods Sniffer packaging to make suitable for installation Software to read signal into database Tentative installation scheduled for week of August 14th at El Camino and Pagemill intersection

CFS: 

CFS Caltrans- and MTC-led Discussion Item

National Events: POC Visit / Recent VII Coalition Meeting: 

National Events: POC Visit / Recent VII Coalition Meeting Caltrans- and MTC-led Discussion Item

High Accuracy NDGPS: 

High Accuracy NDGPS

UCR HA-NDGPS Evaluation: 

UCR HA-NDGPS Evaluation Objective: Investigate feasibility of implementing US DOT High Accuracy National Differential GPS in Northern California Part of Caltrans-PATH VII California scope Approx 6 month level of effort Tasks: Review of HA-NDGPS literature review complete Develop HA-NDGPS Concept for VII Operations summary report in progress Develop HA-NDGPS Requirements for VII California recently started Develop Recommendations

HA-NDGPS: 

HA-NDGPS Task 1.  Review HA-NDGPS state of technology:  components, cost, availability performance expectations comparison with other lane and sub-lane level GPS-based positioning technology Task 2.  Develop HA-NDGPS Concept of VII Operations system architecture cost to turn on; cost to operate narrative or UML description of ConOps

Slide21: 

Global Positioning System Overview 24 satellites (20,000 km elevation); polar orbits each satellite transmits ranging code and navigation data on two carrier frequencies, L1 (1575.42 MHz) and L2 (1227.60 MHz); carrier frequencies are modulated by spread-spectrum signal to carry information to user 3 pseudorandom noise (PRN) information messages associated with each satellite: C/A code precise (P) code or encrypted Y code navigation message including ephemeris parameters and time

Slide22: 

Global Positioning System (cont.) GPS receivers can receive (from each satellite): pseudorange Doppler signal integrated carrier phase low cost receivers receive L1 signal, get C/A code common mode errors are typically 25m standard deviation non-common mode errors are typically 0.1 to 4 meters standard deviation can eliminate common mode errors using differential processing (DGPS) by using a based station at a known location

Slide23: 

Differential Global Positioning System (cont.) off-line: can get corrections from Internet real-time: can get from Coast Guard marine frequencies can get from FAA wide-area augmentation system (WAAS) can get from your own base station corrections have standard protocol: RTCM messages carrier phase measurements: requires dual frequency receivers must solve integer ambiguity problem capable of 1 –2 cm accuracy (RTK)

Slide24: 

DGPS Service Summary

Slide25: 

Nationwide Differential Global Positioning System (NDGPS) Presentation to CGSIC 43nd Meeting March 10, 2003 Curtis Dubay U.S. Coast Guard Five Categories of Applications Provides 1. Original Code-Based NDGPS Applications 1 - 3 meters Navigation, Precision Farming, Resource Management, Dredging, Buoy Positioning, Positive Train Control, Emergency Response & GIS 2. Post-Processing NDGPS Applications 2 - 5 centimeters Surveying, Mapping, Charting & Hydrography 3. Stationary Scientific NDGPS Applications 2 - 3 millimeters Plate Tectonics Monitoring & Earthquake Prediction 4. High Accuracy NDGPS Applications 10 - 15 centimeters Real-time Automated Surveying of Roadways, Railways & Harbors; Highway Lane Keeping; Machinery Control 5. Weather Forecasting Application Continuous measurement of water vapor in the atmosphere

Proposed NDGPS Coverage: 

Proposed NDGPS Coverage Presentation to CGSIC 43nd Meeting March 10, 2003 Curtis Dubay U.S. Coast Guard

HA-NDGPS: 

HA-NDGPS High Accuracy DGPS Broadcast Broadcast Code and Carrier Phase Data All Observables (L1,L2C,L5) contained in 1000 bits in the Compact Format (for 12 SV’s) Data Rates Up to 1 KBPS Initially L1 and L2-P(Y) Observables will be Broadcast Utilize an Advanced Broadcast Link Data Synchronized to GPS Time Carrier Calibrated with GPS to sub-Hertz levels Spectrally Efficient Modulation (Raised Cosine MSK) “One Second Data” in Compact Mode High Accuracy DGPS Broadcast Jim Radice April 16th, 2002

HA-NDGPS: 

HA-NDGPS Phase 1 Develop Modulator and Data Link Receivers Single Site Concept Demonstration Broadcast Characterization and Optimization USCG, NGS, FHWA Phase 2 Optimize Broadcast Data Scheme Implement Pre-Broadcast Integrity Algorithm Multiple Site Concept Demonstration Iono/Tropo Modeling Application Development dwidth ~40kbps High Accuracy NDGPS Program Jim Radice September 22nd, 2002

Broadcast Site Configuration: 

TRANSMITTER DIPLEXER REFERENCE STATION DATA FORMATTER MODULATOR TRANSMITTER DGPS/NDGPS HIGH ACCURACY DGPS TO ANTENNA OBSERVABLES CORRECTIONS Rack Mount PC DSP/Analog Card Broadcast Site Configuration High Accuracy NDGPS Program Jim Radice September 22nd, 2002

Long Range Single Baseline Test: 

Long Range Single Baseline Test High Accuracy DGPS Broadcast Jim Radice April 16th, 2002

Vehicle Lane Position Estimation System : 

Vehicle Lane Position Estimation System System Architecture and Hardware Design On-Board System Hardware Microprocessor GPRS Wireless Modem GPS Receiver consistent 2m accuracy

VII Technologies Requiring DGPS Criteria Evaluation: 

VII Technologies Requiring DGPS Criteria Evaluation Lane/Road Departure Warning Curve Overspeed Warning Probe Vehicles Traveller Information Ramp Metering Electronic Payment Intersection Safety

HANDGPS Considerations Relative to VII Implementation Strategy: 

HANDGPS Considerations Relative to VII Implementation Strategy Positional Accuracy Required? Elevation? Data Frequency Required? Expansion? Deployment Quantity/Schedule? Real Time Requirement vs. Delay? Operational management and maintenance?

Message Traffic at Busy Intersection: 

Message Traffic at Busy Intersection Large suburban and urban intersections could have 500 - 600 vehicles within range 150 m range in dense downtown 250 m range in high-volume suburban area With high-density traffic, all vehicles may need to send their safety-critical messages to help avoid crashes: 600 vehicles x 500 bytes/s each = 300 K Bytes/s If all raw vehicle data must be backhauled to message switch, this is 300 KB/s per RSE

VII California Website: 

VII California Website

Draft Site Map: 

Draft Site Map

Draft Home Page: 

Draft Home Page

Draft Inside Page: 

Draft Inside Page

Some Applications Work: 

Some Applications Work Intersection Message Set Curve Overspeed Warning Probe Application

Curve Speed Warning Application: 

Curve Speed Warning Application Status of CSW system development System framework Ramp survey results Study of digital map (GDF) Preliminary test plans Survey of available on-board sensors in collaboration with participating automobile companies (TOYOTA & VW) Kang Li, Han-Shue Tan (2006.08.04)

Development of CSW System: 

Development of CSW System OBU Field Test

Ramp Survey Results: 

Ramp Survey Results Weighing rules: 1. 101S-Marsh 2. 101N-Emarcadero 3. 101 N- EB Marine World Pkwy 1. Objective factors: analysis of crash statistics, and ramp attributes, etc. 2. Subjective preference- proximity to Palo Alto Thanks Ashkan and Jim.

What is digital map?: 

What is digital map? Main components: Database Data searching engine- mapping program and computer Data is associated with map locations. NAVTEQ GDFv

The Overall GDF Data Model: 

The Overall GDF Data Model Key to NIAM diagrams for GDF models. (Nijssens Information Analysis Method) Main elements: Features- simple and complex Attributes- simple or composite Semantic Relationships- links between features Diagram of the conceptual data model. Reference: Bart Tielens, Navigation Technologies

GDF road network specific data modelThe building blocks of the three levels of representation: 

GDF road network specific data model The building blocks of the three levels of representation Geometry: 1. Segments 2. Node Points 3. Intermediate Points Level 0- Topology: “Cartographic Primitives” 1. Nodes 2. Edges 3. Faces. Level 1- Simple Features: 1.Point Features 2. Line Features 3. Area Features. Level 2- Complex Features: Composed of one or more other simple features. Junctions, Road Elements (level 1) are grouped into roads and intersection at level 2! Reference: Bart Tielens, Navigation Technologies

Relationships of data records in GDF map database: 

Relationships of data records in GDF map database XY-coordinate Record Source Record New Node Record Edge Record Face Record Complex Feature Record Point Feature Record Line Feature Record Area Feature Record Semantic Relationship Record Time Domain Record Segmented Attribute Record Name Record Data records are associated by pointers (record IDs).

GDF Map Example- RFS: 

GDF Map Example- RFS RFS RFS Sample road segment Map data Example of searching road attributes in the database. Extracted GDF map Google earth map Attribute IDs Initial point ID End point ID Reference: NAVTEQ GDF viewer

Available Map Attributes: 

Available Map Attributes Reference: NAVTEQ GDF reference guide.

Safety-Application Map: 

Safety-Application Map This GDF map is not for safety application: Contents are abundant but not complete for the CSW application. Many (position) records are redundant due to the three-level representation of map. Data record association is too complex. Data searching is not efficient enough for real-time application. Create a “safety-application” map: Keep data of interests. Remove duplication in the data. Compatible with original map database. Simpler data structure. More efficient data searching. Improve the local precision and accuracy, e.g. at ramps, if required. More friendly to real-time data extraction, association and computation. This map will first be validated in the preliminary field tests.

Preliminary Test Plans(with TOYOTA and VW): 

Preliminary Test Plans (with TOYOTA and VW) Objectives: Evaluate the existing map in “real-world” and define functional requirements for further enhancements Test the new safety application map Real-time vehicle-map positioning tests CSW algorithm design System prototype setup and validation Test locations: In Richmond Field Station Mock ramps with different curvatures Test track area with poor GPS reception At ramps on I-580 near RFS On chosen ramps on US 101

Mock ramps with different curvatures inside RFS: 

Mock ramps with different curvatures inside RFS Ramp examples The test conditions are more stringent than real ramps in that: 1. Smaller turning radii (10~30 m), 2. Lower speed limits, 3. No super elevation. 187 190

Curves with poor GPS reception: 

Curves with poor GPS reception To test system robustness against GPS outage.

Work Status: 

Work Status Executed: Ramp field survey Commercial digital map evaluation GDF map data process and interpretation CSW system architecture design In progress (with TOYOTA and VW): Preliminary tests Mock ramp setup OBU and RSU setup Real-time application map development CSW algorithm design Modeling Dynamics analysis Simulation On-board sensor survey- call for help of TOYOTA and VW

On-Board Sensor Survey: 

On-Board Sensor Survey

Issues in Probe Vehicle Applications of VII Data: 

Issues in Probe Vehicle Applications of VII Data Steven E. Shladover, Sc.D. July 2006

Outline: 

Outline Vehicle data broadcast volume Combined backhaul volume at busy intersections Probe data applications Opportunities for intermediate data aggregation for each Combined savings in backhaul volume Architectural trade-offs

Vehicle Broadcast Data: 

Vehicle Broadcast Data Safety applications require update rate of 10 Hz Intersection collision avoidance Vehicle-vehicle collision avoidance Minimum packet size assumed to approximate SAE’s common V2V message set – ~50 bytes  Each vehicle broadcasts 500 bytes/second Safety-critical information is only needed locally to help avoid or mitigate crashes Probe applications can “piggy-back” on the same data

What data are really needed for probe vehicle data collection?: 

What data are really needed for probe vehicle data collection? Aggregate measures (by location and time) of: Weather conditions Road surface conditions Link travel times/speeds Incident detections Traffic flow conditions for cooperative microscopic traffic control Local emissions and energy usage None of these needs individual vehicle data beyond the RSE. [One RSE may capture data collected in adjacent uninstrumented locations.]

Weather Condition Information: 

Weather Condition Information Local information on air temperature, precipitation, and special impediments to visibility (e.g., dust) Vehicle-based information from wiper status, fog lamp status, thermometer Aggregate at RSE from all approaching vehicles Minimum geographic scope: ~1000 m RSE-level resolution more than adequate in urban and suburban areas; may need multiple weather zones per RSE in rural areas Up to 10,000 vehicles per square km Minimum update interval: ~ 60 s Factor of 600 slower than vehicle updates

Road Surface Condition Information: 

Road Surface Condition Information Local information on wet vs. dry pavement, snow, or ice, as well as pavement roughness or pothole formation Vehicle-based information from ABS or TCS activations, slip estimators, or special-purpose sensors of pavement status, as well as suspension deflections Aggregate at RSE from all approaching vehicles Minimum geographic resolution ~ 100 m (RSE) Up to 600 vehicles per RSE Minimum update interval: ~ 10 s Factor of 100 slower than vehicle updates

Highway Link Speed and Travel Time: 

Highway Link Speed and Travel Time Average speed and time needed to traverse a highway link (between interchanges) Vehicle-based information from wheel-speed sensors (averaged internally), combined with GPS position and time Aggregate averages from all vehicles on that link Minimum geographic resolution ~1000 m urban, ~10,000 m rural (within RSE position resolution) Up to 800 vehicles within range Minimum update intervals ~60 s urban, ~600 s rural Factors of 600 to 6000 below vehicle updates

Arterial Link Speed and Travel Time: 

Arterial Link Speed and Travel Time Average speed and time needed to traverse an arterial link (between intersections) Vehicle-based information from wheel-speed sensors (averaged internally), combined with GPS position and time Aggregate averages from all vehicles approaching on that link Minimum geographic resolution ~150 m (several links per RSE) Up to 600 vehicles per RSE Minimum update interval ~60 s Factor of 600 below vehicle updates

Incident Detection: 

Incident Detection Identify traffic stoppage, which could be a result of excessive traffic volume, a crash, or an obstacle in the roadway Vehicle data sources include hard braking detection, forward collision warning sensor, hazard light status, and speed/time profile Aggregation of data both on vehicle and at RSE Minimum geographic resolution ~10 m, but reported at RSE level Up to 600 vehicles per RSE Minimum update interval ~1 s Factor of 10 below vehicle updates

Cooperative Microscopic Traffic Control: 

Cooperative Microscopic Traffic Control Intersection or ramp meter signal actuation, based on movements of platoons of vehicles Vehicle speed and location information, possibly vehicle speed/time profiles also Aggregation of vehicle information locally at intersection or ramp meter, where decisions need to be made Minimum geographic resolution ~10 m per vehicle before aggregation, 150 m for reporting to TMC Up to 600 vehicles within 150 m of intersection Minimum update interval ~1 s Factor of 10 below vehicle updates

Emissions and Energy Estimation: 

Emissions and Energy Estimation Use of vehicle speed profiles, including acceleration and deceleration behaviors, to estimate effects of traffic dynamics on pollutant emissions (and fuel consumption) Microscopic vehicle speed profiles, combined with additional information that may be available on some vehicles (transmission shifting, engine speed, etc.) Aggregation preferably on vehicle, then across vehicles at RSE, but could all be at RSE Minimum geographic resolution ~100 m Up to 600 vehicles per RSE Minimum update interval ~10 s for RSE outputs to backhaul Factor of 100 below vehicle updates

Summary of Aggregation Factor Savings: 

Summary of Aggregation Factor Savings

Architectural Trade-Offs: 

Architectural Trade-Offs Backhaul savings of factors between 6000 and 6 x 106 Subscribers can directly find what they need rather than having to sort through 4 to 7 orders of magnitude more data than they need in order to aggregate it themselves Added RSE costs: modest memory and processing capabilities How significant are these costs compared with other RSE costs? Weatherproof enclosure Power source or connection Field installation Backhaul installation and operations Ongoing RSE maintenance for life of the system

APTA Demo: 

APTA Demo

VII Transit Demo: 

VII Transit Demo Demo on October 9th Travel time and incident updates Sniffer demo at El Camino and Pagemill Caltrain schedule display near Caltrain station 511.org information transmitted via wireless internet into bus

511.org information: 

511.org information Computer with screen setup inside bus with a wireless cellular internet connection 511.org information downloaded via wireless connection and displayed on screen Side by side display with RSU travel time information

Travel time and incident updates: 

Travel time and incident updates Bus to get first set of travel times from mobile RSU at beginning of route Travel times updated as RSU's are passed along the demo route Information displayed side by side with data from 511.org Incidents of interest also received from RSU's and displayed accordingly

Preliminary route: 

Preliminary route Pick up at San Jose City Hall CA-87 N to US-101 N US-101 N to San Antonio Rd S San Antonio S to W El Camino Real W El Camino Real to S California Ave S California Ave to the Caltrain Station

RSU Locations for demo route: 

RSU Locations for demo route Mobile RSU placed at start of route 101 @ San Antonio* El Camino Real & Charleston* El Camino Real & Curtner* El Camino Real & Pagemill El Camino Real & California *Schedule for installation in next 6 weeks

Development tasks: 

Development tasks Testing with other vehicles as needed September 18-22 Testing of CWS and VII demos and route - need driver from 10-4 ea day October 5-6 Install demo video system and final testing - don't need driver (2 computers, 2 screens, wireless internet device and antenna) October 9 Demo of system to VIPs - need driver 12-4

Wrap-Up: 

Wrap-Up Action Items? Next Meeting