1. 1 Intersection Decision Support: A Cooperative Approach Summary of California PATH / UC Berkeley IDS Approach

2. 2 Outline Background California Approach – Work Plan – IDS Architecture Underpins California Concept of Operations – Integrating the Driver Aimed at IDS Alert System Design – Alert System Design – Approach to Cooperative Systems

3. 3 Background

4. 4 Driver Decision Support Concept Emphasis on crossing-path collisions (both signalized and unsignalized) – 80% of intersection crashes (1998 GES) Concept and architecture accommodate other intersection crash types Find “best” combinations of vehicle and infrastructure responsibilities for diverse intersections

5. 5 California Areas of Interest LTAP/OD conflicts at signals (permissive, not protected) LTAP/LD conflicts at urban stop signs Development of broad system architecture applicable to all intersection crash types, using information from infrastructure and/or vehicles Development of wireless communications to connect infrastructure and vehicles Pedestrian and bicyclist conflicts

6. 6 California’s Primary Focus Area: LTAP/OD Features of California LTAP/OD Approach – Problem is gap decision in presence of oncoming vehicles – For all traffic control devices: signal, stop sign, no controls – High potential for initial infrastructure-based warning application (“Driver Infrastructure Interface”, DII) Takes advantage of left turn dynamics –If designed correctly, DII for left turn driver is unambiguous DII located at far side corner, where driver is likely to scan – Cooperative (wireless) systems should enhance system

7. 7 Definition: Left Turn Across Path / Opposite Direction (LTAP/OD)

8. 8 Principal Expected Products Quantitative characterizations of intersection safety problems and turning behavior at intersections Recommended designs for infrastructure elements and systems (sensors and their locations, algorithms to use sensor outputs to alert drivers, and displays) Estimates of effectiveness of IDS in reducing intersection crashes Plans for public operational test(s) at selected intersections

9. 9 California Approach

10. 10 Schematic of California Approach Design IDS Alert System Characterize Intersection Driving Roadside Observations Driver Observations Evaluate COTS Technologies Develop Simulation Tool Develop Wireless Communication System Develop DII Driving Experiments At RFS Intersection Implement RFS Test Intersection

11. 11 Task List and Status (1 of 2) Completed Tasks: – A. Problem Assessment Deliverables: Problem Assessment Reports – M. Mid-term demonstration Deliverable: Year 1 Report (in process) Current Tasks: – B. Characterize Intersection Driving Deliverables: Pilot Feasibility Study, Extended Observation Study, Field Collection, Lag Acceptance Reports (early 05) – C. Wireless Communication Development Deliverables: Protocol Design Report (July 04), Communication Prototype and Performance Analysis Report (early 05) – D. Driver-Infrastructure-Interface Usability Deliverables: DII Usability Report (early 05), DII Alternatives Report (early 05) – E. Develop Warning System Deliverable: Warning System (early 05)

12. 12 Task List and Status (2 of 2) Current Tasks (Cont’d) – S1. Develop Simulation Tool Deliverables: Tool (Nov 04) – S2. Evaluate COTS Technologies Deliverables: COTS System Downselect (Sep 04), Test Reports (Sep 04 – early 05) Future Tasks – F. Countermeasure Trade-off Analysis Deliverables: Sensor Fusion Report (Oct 04), Report to Compare Countermeasures (early 05) – G. Pilot FOT Planning Deliverable: Final Report with FOT Plan (early 05)

13. 13 IDS Architecture

14. 14 StateMap-based Architecture Other Conflict predictor State Map Generator Gap predictor Stop predictor Safety applications State map Car GPS Loops Lidar/Radar Sensors Comm.

15. 15 Diverse IDS Implementations Data Sources: Information to Drivers: InfrastructureVehicle Loop Detectors Video Detectors Radar In-vehicle sensors IDS Logic: -Analyze vehicle motions -Predict future gaps, conflicts or violations -Decide to issue alert Dynamic Sign Signal Controller In-vehicle display (wireless)

16. 16 DII 2070 Controller Loops (11) EVT-300 (2) Denso LIDAR (2) Wireless Modem Serial Digital HI/LO Implementation at TFHRC (1 of 3) Fixed (Infrastructure) Sensors Ethernet QNX6 Computer (Sensor Fusion, Warning, and Tracking Algorithms) Serial Controller Cabinets

17. 17 Implementation at TFHRC (2 of 2) 2070 contr. Ethernet QNX 6.0 computer (Sensor fusion, safety IDS algorithms) Eth. cardRS232 Sensors I/O card DII Wireless 802.11a PCMCIA / PCI card infrastructure vehicles QNX 6.0 computer (State map visualizer) Wireless 802.11a PCMCIA / PCI card 802.11a safety enhanced (more DSRC like)

18. 18 PATH RFS Test Intersection Traffic Controller Cabinet 60 Meters of 3M Microloops Embedded Loop Detectors Signal Poles Radar Poles

19. 19 Implementation at the PATH Intelligent Intersection

20. 20 Elements of Cooperative System at the PATH Intelligent Intersection 40-ft Bus at PATH/RFS – DVI at driver console, with identical display for passengers – Wireless implementation of simultaneous DII and DVI In practice, need not be simultaneous – a tricky research item – Demonstrated to Barbara Sisson Associate Administrator for Research, FTA

21. 21 ‘State Map’ of Intersection at Controller We know the status of every communicating entity

22. 22 Integrating the Driver  IDS Alert System

23. 23 Perception - Difficulty Estimating Speed (Staplin, 1995) 10 50 100 150 200 30 mph 60 mph 132 m 4.96 s 80 m 3 s 184 m 6.91 s 158 m 5.93s 125 m 4.69 s 191 m 7.18 s 166 m 12.5s 104 m 7.8 s 228 m 17 s 161m 6s 108 m 4 s 214 m 8 s 100 m 7.5 s 51 m 3.8 s 149 m 11.2 s 150 m 11.7s 106 m 7.9 s 206 m 15.4 s Age 20-53 Age 56-72 Age 75-91

24. 24 Observations and Experiments (1 of 3) Three Driver Experiments 1. Downtown Berkeley (ongoing) Microscopic: 0.075-sec resolution Over 400 intersection traverses Defining key waypoints 2. Experimental Intersection: D2I vs T2I 3. Experimental Intersection: How well does our warning system / nominal DII work?

25. 25 Parameter Definitions Crossing time Turning time Waiting time

26. 26 Observations and Experiments (2 of 3) Characterizing Driver Behavior at Intersections – Four sites Two in Berkeley Pinole Burlingame (near SFO) San Francisco – Two approaches Roadside In-Vehicle – At least three warning algorithm approaches Dynamic (Shladover) “BMI-based”/Statistical (Ragland) Neural net (Misener) – Transcends LTAP/OD

27. 27 Observations and Experiments (3 of 3) Driver Infrastructure Interface (DII) Depth: “Looming Circle” DII further investigated – Our nominal DII Breadth: Based on CTCDC preparations and recommendations from committee, alternate DIIs to be considered

28. 28 Instrumented Ford Taurus for Driving Data Collection Wireless connection from laptop to PC104 in traffic signal control cabinet Intended Field data collection and controlled tests at RFS

29. 29 Output: Inputs to Alert System Design Roadside observations (by radar and video): – SV turning times – POV speed distribution – Accepted and rejected turning gaps – SV/POV speed change interactions – Behavior changes based on signal phase – Interactions with pedestrians Instrumented vehicle field tests: – Detailed SV speed-based information – Timing of turning decision Waypoints within turning movement (e.g., decision point, waiting time turning time) – Influence of driver age and gender on turning behavior

30. 30 IDS Alert System Design

31. 31 Central Role of Alert System Design Design IDS Alert System Characterize Intersection Driving Roadside Observations Driver Observations Evaluate COTS Technologies Develop Simulation Tool Develop Wireless Communication System Develop DII Driving Experiments At RFS Intersection Implement RFS Test Intersection

32. 32 Alert System Requirements Very low false negatives – consistently alert to hazardous conditions Low false positives – avoid alerting under benign conditions Appropriate timing of alert onset Do as well as possible with imperfect sensor data …while recognizing inherent limitations: – Subjective judgments of gap suitability – Diversity of driving population preferences

33. 33 Single LTAP/OD Encounter SV “Leading Buffer time” after POV1, ahead of SV “Trailing Buffer time” after SV, ahead of POV2 POV1 POV2 SV

34. 34 LTAP/OD Alert Design Goals When an SV may be planning to make a left turn (in LT pocket or left lane, if no pocket): – Provide alert for gaps in POV traffic shorter than minimum “safe” threshold – Don’t alert if POV gap is longer than acceptable threshold (avoid nuisance alerts) – Time the alert to be early enough for SV driver to be able to make a comfortable “no turn” decision, but not so early that it could be perceived a nuisance. First define alert design assuming complete and accurate sensor data, then adjust for imperfect data

35. 35 Nominal Alert Triggering Approach Develop for middle of green phase, then adjust for other conditions Anticipate when SV will enter dangerous region (in path of POVs), and how long it will need to clear that region Define acceptable time gap in approaching POV traffic after SV will clear intersection (“Trailing Buffer” time values based on field measurements and driver experiments, initial estimate ~ 3 s) Apply hysteresis in acceptable gap times to avoid chatter – T gaplow and T gaphigh, initially separated by 1 s (final value to depend on sensor and data fusion capabilities).

36. 36 Alert Development Process Define alert criteria, considering “all” expected combinations of conditions – Based on information from observation studies (roadside and in-vehicle) – Adjustments for diverse intersection conditions Test alert criteria in simulation under challenging conditions, then adjust as necessary – POV speed changes (dilemma zone decel. and accel., decel. to turn) – Range of approach speeds – Range of relative arrival times of SV, POV Test sensor alternatives to compare to “perfect” sensor information

37. 37 Sensor Coverage Alternatives Standard loops at stop bar Alt. 1 Single loop detector Double loop detector Alt. 2 Radar coverage zone Alt. 3 Alt. 4 Alt. 5 Double loop detector Alt. 6

38. 38 General Findings on Alert Design and Detection Needs Complex interactions between SV and POV speeds need to be evaluated in multiple cases Early enough detection of POV is essential (6 seconds before stop bar) Use of final four loops at SV stop bar is crucial for determining SV speed in difficult cases Alerts depend on accurate speed as well as presence information POV speed changes close to intersection are not as important as SV speed changes

39. 39 Importance of Accurate Speed Measurements If assumed speed is below true speed, alerts will be late or missed completely The larger the speed difference (faster vehicles), the higher the likelihood of a problem – Also the most important cases for issuing alerts (driver misperception of closing speed and severe consequences of crash) If assumed speed is above true speed, false alarms become more likely Variance of distribution of approaching speeds governs the importance of this

40. 40 Alert System Design Challenges Address complexity of SV-POV interactions Accommodate diversity of driver preferences within one set of alert criteria Customize to fit differing requirements of diverse intersections Implement with affordable sensor suite – Tracking individual vehicle positions and speeds, with multiple POVs – Covering center of intersection as well as approach legs

41. 41 InfrastructureVehicle IDS Infrastructure based sensors Traffic sign. contr. Traffic sign. manag. Traffic Signal Inputs Infrastructure state information (e.g. intersection type, signal state, etc); Vehicles state information (e.g. speed, position, etc); DII manager Drivers Signal controller Output Driver Interfaces State Map Generator Predictors Future State Predictor State map Future State Gap predictorStop predictorConflict predictor In-vehicle sensors In-vehicle display devices

42. 42 Cooperative System Opportunities Data from vehicles to intersection to improve IDS operation: – Longer-range (earlier) information – Acceleration to improve threat estimate – More accurate approach speed information – Enhanced weather or road surface status Data from intersection to vehicles: – IDS alert status for in-vehicle display – Information about approaching vehicle threats not visible to vehicle sensors – Enhanced weather or road surface status

43. 43 Review of Cooperative System Concepts Collaboration with DaimlerChrysler RTNA Review of assumptions from other current activities: – CAMP-VSCC message sets for violation and turning conflict cases – AMI-C Common Message Set, augmented by AAM for WAVE Message List WAVE = Wireless Access in the Vehicular Environment – SAE vehicle broadcast message packet for DSRC Intersection elements not well defined yet in vehicle industry activities

44. 44 Cooperative System Development Activities Define message sets needed for IDS applications, leaving flexibility for alternative implementations – Infrastructure-centered intelligence – Vehicle-centered intelligence – Lane – level accuracy maps Communication protocol design Test wireless communication of these message sets using 802.11a and DSRC test kits Fusion of intersection and vehicle sensor data

45. 45 Communication Needs Summary Vehicle broadcast message set per current SAE work, 42 byte payload and 70 byte overhead Assume (order of magnitude) 100 ms update interval Range of 300 m for higher-speed rural and 150 m for lower-speed urban environments Jam density could approach 600 vehicles within intersection range Accommodating 600 vehicles within DSRC safety channel (3 -- 27 Mbps) requires coordination in MAC protocol