Concept Development and Needs Identification for Intelligent Network Flow Optimization (INFLO)

1. Concept Development and Needs Identification for Intelligent Network Flow Optimization (INFLO) Functional and Performance Requirements and Communication and Data Needs Stakeholder Walkthrough Webinar August 9, 2012

2. Agenda 1:00 – 1:10 PM 1. Welcome and Introductions, 2. Background and Walkthrough Objectives 1:10 – 1:15 PM 3. High-Level Discussion of INFLO Systems and Subsystems 1:15 – 1:45 PM 4. SPD-HARM Functional and Performance Requirements 1:45 – 2:15 PM 5. Q-WARN Functional and Performance Requirements 2:15 – 2:45 PM 6. CACC Functional and Performance Requirements 2:45 – 3:00 PM BREAK 3:00 – 3:20 PM 7. SPD-HARM Data and Communication Needs 3:20 – 3:40 PM 8. Q-WARN Data and Communication Needs 3:40 – 4:00 PM 9. CACC Data and Communication Needs 4:00 PM 10. Wrap-up and Next Steps

3. 2. INFLO Background and Walkthrough Objectives

4. The INFLO Bundle Intelligent Network Flow Optimization (INFLO) bundle of applications: Dynamic Speed Harmonization (SPD-HARM) Queue Warning (Q-WARN) Cooperative Adaptive Cruise Control (CACC)

5. Goals of INFLO Utilize frequently collected and rapidly disseminated multi-source data drawn from connected travelers, vehicles, and infrastructure to: Improve roadway throughput Reduce delay Improve safety Reduce emissions and fuel consumption

6. INFLO Deployment Vision

7. Walkthrough Objectives Ensure accuracy and completeness of INFLO requirements and data and communication needs Provide functional, technical, management, and implementation comments as necessary

8. 3. INFLO Systems and Subsystems

9. Key INFLO Systems Connected Vehicle-based INFLO Application – the core in-vehicle application that processes real-time data and makes speed harmonization/queue warning/gap and speed recommendations for the individual vehicle Connected Vehicle Driver Interface System – in-vehicle system that displays output and receives user input Connected Vehicle Communication System – the in-vehicle system that communicates wirelessly with infrastructure and other Connected Vehicles (may utilize DSRC, cellular communication, or WiFi) On-board Diagnostic (OBD) reader/Vehicle Bus System – the in-vehicle systems that read real-time vehicle data (speed, heading, temperature, etc.) to make available to the INFLO Application Traffic Management Entity (TME) – the generalized system (which could refer to a TMC) responsible for making segment-specific and network-wide target speed recommendations, queue warning determinations and predictions, and gap policies for enabled Connected Vehicles and communicating these recommendations via I2V communications TME-based INFLO Application – the core infrastructure-based application that processes real-time and historical transportation network data to determine the abovementioned recommendations V2I/I2V Roadside Equipment – the infrastructure-based communication systems that receive and send information between INFLO-enabled Connected Vehicles and the TME TME Performance Monitoring Subsystem – the subsystem of the TME-based INFLO Application that monitors the effectiveness of INFLO recommendations and policies on the transportation network using safety and mobility measures Data Environments – the systems that receive, store, and summarize real-time data gathered from Connected Vehicles and Infrastructure to be made available to various Dynamic Mobility Applications

10. Generic SPD-HARM Systems Information Flow Diagram Connected Vehicle Remote Connected Vehicle Driver Interface OBD Reader/ Vehicle Bus V2V Onboard SPD-HARM App Data Communication V2I Data Environment Roadway Traffic Mgmt. Entity External Data Sources (Weather, EMS, etc.) V2X Comm. Performance Meas. Traffic Detection SPD-HARM App Weather Sensors DMS

11. 4. SPD-HARM Requirements

12. INFLO requirements are organized by user need addressed, as identified in the INFLO ConOps The near-, mid-, and long-term achievability of each requirement is indicated in the Application Evolution Statecolumns Near-term: 1-10 year horizon Mid-term: 10-20 year horizon Long-term: 20+ year horizon Key systems and subsystems involved in the given requirement are indicated in the next column Requirement type indicated in the last column (Functional, Performance, System-to-system interface, Human-machine interface, Security, Privacy) Structure of the INFLO Requirements

13. SPD-HARM User Need 1 & 8: Know the recommended speed to travel & Communicate relevant information to vehicle operator

14. SPD-HARM User Need 2 & 8: Know which lane to be in & Communicate relevant information to vehicle operator

15. SPD-HARM User Need 3 & 8: Know why given speed is being recommended & Communicate relevant information to vehicle operator

16. SPD-HARM User Need 4: Personal data to remain private and secure

17. SPD-HARM User Need 5: Collect relevant vehicle data

18. SPD-HARM User Need 6: Disseminate relevant vehicle data to other vehicles or systems

19. SPD-HARM User Need 7: Receive relevant information from other vehicles or systems

20. SPD-HARM User Need 9:Receive multi-source data

21. SPD-HARM User Need 10:Process multi-source data

22. SPD-HARM User Need 10:Process multi-source data (continued)

23. SPD-HARM User Need 10:Process multi-source data (continued)

24. SPD-HARM User Need 11:Generate speed harmonization strategies

25. SPD-HARM User Need 12: Disseminate speed harmonization recommendations and information to connected vehicles/devices

26. SPD-HARM User Need 13: Analyze performance of SPD-HARM system

27. SPD-HARM User Need 14: Collect SPD-HARM data and disseminate relevant information to other dynamic mobility applications

28. 5. Q-WARN Requirements

29. Q-WARN User Need 1 & 8: Know of a downstream traffic queue in sufficient time to react safely & Communicate queue warning to vehicle operator

30. Q-WARN User Need 2 & 8: Know what actions to take to respond to an impending queue & Communicate queue warning to vehicle operator

31. Q-WARN User Need 3: Personal data to remain private and secure

32. Q-WARN User Need 4: Detect a queued state

33. Q-WARN User Need 5: Disseminate queued status alert to upstream vehicles and other systems

34. Q-WARN User Need 6: Receive relevant queue information from other vehicles or systems

35. Q-WARN User Need 7:Generate queue response strategies

36. Q-WARN User Need 9: Collect relevant traffic, road conditions, and weather data

37. Q-WARN User Need 10: Disseminate relevant traffic, road condition, and weather data to vehicles

38. Q-WARN User Need 11:Detect a formed queue

39. Q-WARN User Need 11:Detect a formed queue (continued)

40. Q-WARN User Need 12:Predict impending queue formation

41. Q-WARN User Need 12:Predict impending queue formation (con’t)

42. Q-WARN User Need 13: Generate queue warning response strategies for upstream vehicles

43. Q-WARN User Need 14:Disseminate queue warnings

44. Q-WARN User Need 15:Analyze performance of the Q-WARN system

45. Q-WARN User Need 17: Disseminate signal phasing information to approaching vehicles

46. Q-WARN User Need 18: Collect Q-WARN data and disseminate relevant information to other dynamic mobility applications

47. Q-WARN User Need 19: Collect and aggregate Q-WARN related data and disseminate to freeway and arterial traffic management entities

48. 6. CACC Requirements

49. CACC User Need 1:Join a CACC platoon

50. CACC User Need 2:Establish or accept a speed and gap policy