VII California Team Meeting

1
VII California Team Meeting

• June 8, 2006
• Richmond Field Station (PATH)

2
Agenda

• A warm welcome to BMW
• Ongoing activities
• Status of remaining intersections / backhaul
• RSU monitoring
• Development activities
• Performance measurement
• Sniffer development, to include scheduled tasks
• Curve overspeed application development
• Toyota travel time application
• Changes in signage message (MTC, PBF item)
• HANGDPS investigation  work plan
• Video of the recent demo given _at_ SR82 and
  California to CICAS visitors
• Other?
• Actions / Next Steps / Next Meeting

3
Ongoing ActivitiesStatus of Remaining
Intersections/Backhaul
4
Backhaul Status
5
MB8000 3G network through an Ethernet port
6
T1 Installation
7
(No Transcript)
8
GPRS

• GPRS modem used at Mariposa 17th St., 101 at
  University, and El Camino and Pagemill
• Bandwidth 40kbps
• Has reliably been running for months (couple
  service outtage issues from Cingular)

9
HSDPA

• Aircard 860 HSDPA PCMCIA Card
• Bandwidth 400kbps-700kbps in good areas
  (100kbps in bad areas)
• Card can be plugged into Junxion box which
  provides ethernet interface to RSU, but Junxion
  box only supports 115kbps
• Currently looking for replacement for Junxion box

10
DSL

• DSL service used at El Camino and California
• Bandwidth 6Mbps
• Netopia DSL router provides ethernet interface to
  RSU for easy setup

11
Ongoing ActivitiesRSU Monitoring
12
VII-CA Monitor Architecture
RSE
path.berkeley.edu
RSE
Report server (UDP)
RSE
HTML generator
WRM
Periodic sensors (software)
backhaul
Reports (UDP)
Database
viicatl --rsu process
Email generator
Database
b'casts
system config
Report generator
RSS generator
pc104 status
non-monitor component
more work needed
monitor component
13
Data in Existing Reports

• Config network, WRM, OS, software
• Status
• Disk, memory, CPU, WRM, uptime, system clock
• Backhaul round-trip time stats, loss rate
• Recent messages
• Beacon and signage broadcasts
• Time and originating address of message from OBU
  (e.g. probe message)
• viicatl software status
• Recent error conditions, uptime, diagnostics

14
Proposed Data

• During backhaul outage
• Record attempts by host to restore connection
• Report is sent when backhaul restored
• More info on received messages
• Probes quantity, destinations
• RSSI (signal strength) of messages from OBU
• Aggregated at RSU (not at server)
• Upload/download speed estimate
• Estimate performed when viicatl --rsu not busy
• GPS position and signal status, if available

15
Processing Needs

• Current display is detailed but hard to use
• http//path.berkeley.edu/vii/monitor
• Need more historical data so we can identify
  trouble spots and effect of changes
• Need aggregation to manage large data set
• Need plotting to make patterns easy to see
• Plot demand, resource usage, error rate together
• Plot several RSUs together for comparison

16
Proposed Processing (on server)

• History and aggregation of
• outages (backhaul, DSRC)
• performance measures
• resource usage
• Plots
• Auto-generated using gnuplot
• Displayed on web site
• Email and RSS notification of events
• Email is better for major events requiring
  attention
• RSS feed is better for recent news summary

17
Suggestions?

• Any other useful data?
• What views of data are especially useful?
• Should any monitor data sets be available for
  download?
• Bear in mind
• Monitor does not collect exhaustive data
• Only periodic samples
• Only aggregated data
• For diagnostics--not a substitute for probes

18
Development ActivitiesPerformance Measurement
19
Performance Measurement Activities

• Recent activities
• In partnership with ARINC, constructed test rig
  for simultaneous DSRC transmission
• Began testing with 9 Denso WRMs on one vehicle at
  Richmond Field Station and in San Francisco
• Planned activities
• Complete round of testing and prepare report
• Develop Linux kernel mode driver to perform
  measurements and channel switching
• Use driver as basis for further tests and
  higher-level software implementation

20
ARINC Test Set-up

• 4 portable assemblies
• Each contain 3 400 MHz gumstix computers.
• Each of the 12 individual computers runs an
  embedded Linux system.
• Each gumstix is paired with its own Denso WAVE
  radio module and rooftop antenna.
• Flexible configuration
• All the assemblies can be connected via a router
  and deployed in one vehicle for tests to an RSU.
• Or individual assemblies can be placed in
  different vehicles for a variety of approach
  paths.

21
Test assembly with 3 gumstix
22
Performance Measurement Status, 06/06

• Developed testing software to
• Change channel and power
• Get RSSI (Received Signal Strength Indication)
• Record transit trip time and dropped packet count
  
• Performed extensive desk-checking to
• Validate software
• Calibrate timing when at rest, in range
• Began tests with 9 WRMs on a single vehicle
• With RSU at Richmond Field Station
• At ARINC site in San Francisco
• Site characterization planned for all VIICA RSUs

23
Development ActivitiesSniffer
24
Active Signal Sniffer Development

• Short-term
• Install sniffer prototype at Page Mill road
  intersection
• Collect data at several sites with different
  traffic signal and controller types, to
  characterize range of relevant electrical
  parameters
• Long-term
• Design more robust hardware for permanent
  installations
• Evaluate what applications can be supported with
  sniffing alone, and what may require an enhanced
  sniffer with more information (e.g. loop detector
  input ) for effective message broadcasts

25
Signal Sniffer Circuit Components

• Non-contact inductor to detect the current
• Input signal conditioning (clean up detection
  signal to use as input to comparator)
• Comparator (determine whether on or off)
• Output signal conditioning (clean up result of
  comparison so that it can be read by a computer)
• Block diagram in next slide is general, applies
  to future designs as well as to current prototype

26
Signal Sniffer Block Diagram
27
Schematic of sniffer prototype
Detection and signal conditioning
Comparison and output signal conditioning
28
Sniffer Hardware Development (1)

• Requirement
• Sniffer needs to work with different traffic
  signal and controller types in common use
• Plan
• Characterize current flow to signal light at
  several sites using a portable data collection
  system
• Analyze data for current flow and noise
  parameters
• Extrapolate fixed comparator thresholds and
  hysteresis levels based on data analysis
• Testing and data analysis will require several
  months

29
Sniffer Hardware Development(2)

• Requirement
• Sniffer device for deployment must be compact and
  robust
• Plan
• Design compact and efficient printed circuit
  board based on SMT (surface mount technology)
• Integrate sniffer with USB, Ethernet or other
  system input device

30
Sniffer Prototype at Page Mill Rd

• Full-featured intersection with actuation
• Prototype boards have been built to sniff up to
  12 signal currents (using 2 boards)
• Linux digital I/O driver being tested, count down
  software being ported from QNX

31
Plans to Use Sniffer at Page Mill

• Instrument output of load switches for phases 2,
  4 and 8 (6 has timing identical with 2)
• Provide accurate timing for yellow period and
  best effort reporting for red and green periods
• Test prototype with car company applications,
  evaluating performance and developing reporting
  requirements

32
Page Mill Installation Schedule

• Digital I/O testing with 4 signal board
  completed, June 12
• 8 board integrated with digital I/O, June 16
• Phase count-down software integrated with
  broadcast, June 21
• Design review and installation approval, June 23
• Installation with Caltrans assistance, two weeks
  later, July 7
• Begin site testing and any required software
  refinement immediately after installation

33
Longer Term Sniffer Schedule

• Complete portable data collection hardware and
  software and begin multiple-site data
  collection, September 2006
• Complete data collection and begin data analysis,
  November 2006
• Begin PCB design based on data analysis and
  requirements from Page Mill testing, January 2007
• Send PCB design out for fab March 2007
• Receive PCB sniffer and install for testing April
  2007

34
Development ActivitiesCurve Overspeed
35
Concept of Operation
OBU
Block Diagram
RSU
Detailed road attributes provider
36
Curve Speed Warning on Ramps

• First phase - detection of ramp
• RSU keeps broadcasting message to notify
  approaching vehicles of the existence of ramps
• Pertinent static and dynamic attributes
  unavailable on the road-level map are provided in
  the message from RSU
• Measured by the infrastructure or
• Reported by dynamic behavior of prior vehicles
• Second phase - preparing
• On-board pre-computation of speed limit for
  safely entering the ramp

37
Curve Speed Warning on Ramps CONTD

• Third phase decision making
• Case 1 not entering the ramp and no warning
  message generated
• Case 2 entering the ramp
• The system keeps computing speed limits along the
  whole path on the ramp
• A waning message/alarm is activated whenever
  detecting the actual speed higher than the safety
  limit
• Case 3 in the ramp
• Curvature changes provided by RSU, particularly
  where
• Superelevation causes prior drivers to not take
  constant radius turn
• Weather conditions causes nonconstant
  trajectories
• Speed advisory continuously given based on
  experience from previous vehicles
• Fourth phase warning
• VMS may warn unequipped vehiles
• This might be notional as this is an experimental
  system

38
Notes

• According to EDMap report, the map-based approach
  has high missed-detection rate on ramps due to
  low accuracy of road-level map and GPS. A
  countermeasure is proposed using available
  on-board sensors and RSU message.
• Road curvature can be pre-recoded or computed
  on-board depending on system design and map
  accuracy.
• Curve speed warning by VII-Map approach is
  expected to achieve higher performance than
  map-based approach.

39
Crash vs. Curvature on Chosen Ramps
Listed curvatures correspond to sharpest curves
of ramps.
40
Crash Statistics for 101 Northbound (1of 3)
41
Crash Statistics for 101 Northbound (2 of 3)
42
Crash Statistics for 101 Northbound (3 of 3)
43
Crash Statistics for 101 Southbound (1of 3)
44
Crash Statistics for 101 Southbound (2 of 3)
45
Crash Statistics for 101 Southbound (3 of 3)
46
Chosen ramps based on study of accident statistics
101S off-ramp to Willow (southbound)/114
101N on-ramp from Univ. Ave. (northbound)
101 N on-ramp from Holly (eastbound)
101 N on-ramp from MARINE WR PKWY
47
Next Steps

• Programmatic
• Reconvene Curve Overspeed Working Group
• DCX has chosen not to participate, except in an
  advisory mode
• Technical
• Choose/measure attributes for implementation
• Static attributes curvature, bank, grade, road
  surface type, width, length, speed limit, etc.
• Dynamic attributes temperature, weather,
  traffic.
• Address ositioning issues (for adopted
  navigation system)
• GPS/DGPS accuracy
• Digital map accuracy
• Local enhancement (concept of hybrid map)

48
Next Steps CONTD

• Technical (Contd)
• Address communication issues
• Positioning correction
• Latency
• Bandwidth
• RSU location
• Communication means DSRC vs. other broadcast
  means
• Consider other issues
• Real-time calculation of curvature using spline
  data
• Curvature calculation static record vs.
  real-time computation
• Backup solution for missed-detection of ramps
• Implementation
• Decide on location and quantity of RSU
• Deploy experimental system
• Design and conduct experiments

49
Development ActivitiesChange in Signage Message
50
Development ActivitiesToyota Travel Time
Application
51
Toyota Travel Time Application

• Signage generator at Toyota labs
• Messages in non-public format
• Broadcast at Page Mill / El Camino (RSU 4)
• RSSI (received signal strength)
• Signage will use WAVE TX options so that receiver
  can extract RSSI info from received packets
• Application travel time between intersections
• Use probe messages to gather data
• Process data to generate signage messages

52
Toyota probe server
PATH signage server
Signage with travel time to RSU1
Probe with 2 snapshots at RSU2 and at RSU1
RSU1
RSU2
v1
v2

• v1 passes RSU2 and then RSU1
• v1 sends time-of-first-contact for both RSUs
• Toyota server estimates travel time
• Travel time broadcast to v2 via signage

53
Development ActivitiesHANDGPS Investigation
54
HANDGPS

• 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
• PATH (UC Berkeley) ? UC Riverside intercampus
  funds transfer
• Task 1.  Review HANDGPS
• state of technology  components, cost,
  availability
• performance expectations
• comparison with other lane and sub-lane level
  GPS-based positioning technology

55
HANDGPS CONTD

• Task 2.  Develop HANDGPS Concept of Operations
  for VII California in Northern California
• system architecture
• cost to turn on cost to operate
• narrative or UML description of ConOps
• Task 3.  Develop HANDGPS Requirements for VII
  California
• Task 4.  Recommended Next Steps
• outline and suggested timeline of sequence of
  steps to implement HANDGPS
• rough cost (labor hours, components) for each
  step along the timeline
• inputs to go/no_go decision
• If go, Caltrans-PATH VII California project
  expected to fund implementation

56
Short VII California Video
57
Other?
58
Wrapup

• Actions?
• Next Steps?
• Next Meeting?