Connected Vehicle Pilot Deployment Program Performance Measurement and Evaluation Support Plan, Phase 2 UPDATE – Tampa (THEA)
www.its.dot.gov/index.htm Report — July 8, 2019 Publication Number: FHWA-JPO-16-314
1.1.1.1.1.1
Produced by Tampa Hillsborough Expressway Authority U.S. Department of Transportation Intelligent Transportation Systems (ITS) Joint Program Office
Notice
This document is disseminated under the sponsorship of the Department of Transportation in the interest of information exchange. The United States Government assumes no liability for its contents or use thereof. The U.S. Government is not endorsing any manufacturers, products, or services cited herein and any trade name that may appear in the work has been included only because it is essential to the contents of the work.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |i
Technical Report Documentation Page 1. Report No. 2. Government Accession No. 3. Recipient’s Catalog No. FHWA-JPO-16-314 4. Title and Subtitle 5. Report Date Connected Vehicle Pilot Deployment Program, Performance Measurement and July 8, 2019 Evaluation Support Plan, Phase 2 UPDATE – Tampa Hillsborough Expressway 6. Performing Organization Code Authority 7. Author(s) 8. Performing Organization Report No. Sisinnio Concas, Achilleas Kourtellis, Stephen L. Reich Center for Urban Transportation Research, University of South Florida 9. Performing Organization Name and Address 10. Work Unit No. (TRAIS) Tampa Hillsborough Expressway Authority
1104 East Twiggs-Tampa-FL-33602 Center for Urban Transportation Research 11. Contract or Grant No. University of South Florida Sisinnio Concas, Achilleas Kourtellis, Stephen Reich 12. Sponsoring Agency Name and Address 13. Type of Report and Period Covered ITS-Joint Program Office Final Report 1200 New Jersey Ave., S.E., 14. Sponsoring Agency Code Washington, DC 20590 15. Supplementary Notes Govind Vadakpat, Tampa CV site Agreement Office Representative and Sarah Tarpgaard, Agreement Officer.
16. Abstract The Performance Measurement and Evaluation Support Plan for the Connected Vehicle Pilot Deployment Program Phase 2, Tampa Hillsborough Expressway Authority, outlines the goals and objectives for the Pilot as well as the performance metrics. The document addresses the issues, operational needs, and the targeted improvements for the Pilot focus areas. Goal-related performance measures are presented for each of the six Use Cases, followed by assessment and system deployment impact evaluation design that controls for observed and unobserved confounding factors. A detailed approach to participant selection and to the treatment of confounding factors is presented as evidence of a scientifically sound approach to the design of the entire CV Pilot evaluation. The six Use Cases are considered individually for experimental design, participant selection, and measurements of performance. Finally, the report outlines the methods and procedures for data collection, methods for estimating each identified performance measures, performance measure reporting, and the interface between THEA and its core agency partners with the Independent Evaluation effort.
17. Key Words CV Pilot Deployment, Performance Measures, Confounding Factors, 18. Distribution Statement Experimental Design, Data Reporting
19. Security Classif. (of this report) 20. Security Classif. (of this page) 21. No. of Pages 22. Price Unclassified Unclassified 152
Form DOT F 1700.7 (8-72) Reproduction of completed page authorized
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |ii
Contents 1 Introduction ...... 1 1.1 PURPOSE OF THE REPORT ...... 1 1.2 ASSUMPTIONS ...... 2 1.3 CONSTRAINTS ...... 2 1.4 ORGANIZATION OF THE REPORT ...... 3 2 CV Pilot Needs ...... 5 2.1 PILOT FOCUS AREA SYSTEM DESCRIPTION ...... 5 2.2 TRANSPORTATION-RELATED ISSUES – MOBILITY, SAFETY, AND ENVIRONMENTAL ...... 7 3 CV Pilot Goals and Objectives ...... 10 3.1 INTRODUCTION ...... 10 3.1.1 Goal 1: Develop and Deploy CV Infrastructure to Support the Applications Identified During Phase 1 ...... 10 3.1.2 Goal 2: Improve Mobility in the CBD ...... 10 3.1.3 Goal 3: Reduce the Number of Crashes within the Pilot Area...... 10 3.1.4 Goal 4: Reduce Environmental Impacts within the Pilot Area ...... 11 3.1.5 Goal 5: Improve Agency Efficiency ...... 11 3.1.6 Goal 6: Develop Business Environment for Sustainability ...... 11 3.2 USE CASES ...... 12 3.2.1 Use Case 1: Morning Backups ...... 12 3.2.2 Use Case 2: Wrong-Way Entries ...... 13 3.2.3 Use Case 3: Pedestrian Conflicts ...... 14 3.2.4 Use Case 4: Transit Signal Priority ...... 15 3.2.5 Use Case 5: Streetcar Conflicts ...... 18 3.2.6 Use Case 6: Traffic Progression ...... 19 4 Performance Measures and Targets ...... 22 4.1 INTRODUCTION ...... 22 4.2 USE CASE 1: MORNING BACKUPS ...... 22 4.2.1 Mobility ...... 22 4.2.2 Safety ...... 23 4.2.3 Environment...... 23 4.2.4 Agency Efficiency ...... 24 4.3 USE CASE 2: WRONG-WAY ENTRIES ...... 24 4.3.1 Mobility ...... 24 4.3.2 Safety ...... 24 4.3.3 Environment...... 24 4.3.4 Agency Efficiency ...... 25 4.4 USE CASE 3: PEDESTRIAN SAFETY ...... 25 4.4.1 Mobility ...... 25 4.4.2 Safety ...... 25 4.4.3 Environment...... 26 4.4.4 Agency Efficiency ...... 26 U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |iii
4.5 USE CASE 4: TRANSIT SIGNAL PRIORITY ...... 26 4.5.1 Mobility ...... 26 4.5.2 Safety ...... 27 4.5.3 Environment...... 27 4.5.4 Agency Efficiency ...... 27 4.6 USE CASE 5: STREETCAR CONFLICTS ...... 27 4.6.1 Mobility ...... 27 4.6.2 Safety ...... 27 4.6.3 Environment...... 28 4.6.4 Agency Efficiency ...... 28 4.7 USE CASE 6: TRAFFIC PROGRESSION ...... 28 4.7.1 Mobility ...... 28 4.7.2 Safety ...... 29 4.7.3 Environment...... 29 4.7.4 Agency Efficiency ...... 29 4.8 PERFORMANCE MEASURE TARGETS ...... 29 5 Confounding Factors ...... 32 5.1 INTRODUCTION ...... 32 5.2 IDENTIFICATION OF CONFOUNDING FACTORS ...... 32 5.3 STUDY AREA-SPECIFIC FACTORS ...... 32 5.3.1 Weather ...... 32 5.3.2 Special Events ...... 34 5.3.3 Tampa Downtown Waterfront Planned Construction ...... 35 5.4 DEPLOYMENT-SPECIFIC FACTORS ...... 35 5.4.1 ConOps Failure and Anomaly Conditions ...... 36 5.4.2 ConOps Maintenance Conditions ...... 36 5.4.3 Measurement Errors Due to Concurrent Use of Applications to Measure Performance ...... 36 5.5 EXPERIMENTAL DESIGN-INDUCED CONFOUNDING FACTORS ...... 36 5.5.1 Participant Self-Selection ...... 36 5.5.2 Participant Attrition ...... 37 5.5.3 Participant Moral Hazard ...... 37 6 System Deployment Impact Evaluation Design ...... 38 6.1 INTRODUCTION ...... 38 6.2 EXPERIMENTAL STRATEGIES ...... 38 6.2.1 Random Design ...... 39 6.2.2 Quasi-Experimental Design ...... 40 6.2.3 Before and After Comparison (Time Series Analysis) ...... 42 6.3 USE CASE 1: MORNING BACKUPS ...... 43 6.3.1 Background on Baseline Commuting Patterns ...... 43 6.3.2 Recommended Experimental Design ...... 44 6.3.3 Performance Measurement (Statistical Modeling) ...... 46
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |iv
6.4 USE CASE 2: WRONG-WAY ENTRIES ...... 46 6.4.1 Background on Baseline Driver Patterns ...... 47 6.4.2 Recommended Experimental Design ...... 47 6.4.3 Performance Measurement (Statistical Modeling) ...... 47 6.5 USE CASE 3: PEDESTRIAN SAFETY ...... 47 6.5.1 Recommended Experimental Design ...... 48 6.5.2 Performance Measurement...... 48 6.6 USE CASE 4: TRANSIT SIGNAL PRIORITY ...... 48 6.6.1 Background on Baseline Bus Conditions ...... 48 6.6.2 Recommended Experimental Design ...... 48 6.6.3 Performance Measurement (Statistical Modeling) ...... 48 6.7 USE CASE 5: STREETCAR CONFLICTS ...... 49 6.7.1 Background on Baseline Streetcar Conditions ...... 49 6.7.2 Recommended Experimental Design ...... 49 6.7.3 Performance Measurement...... 49 6.8 USE CASE 6: TRAFFIC PROGRESSION ...... 49 6.8.1 Recommended Experimental Design ...... 49 6.8.2 Performance Measurement (Statistical Modeling) ...... 50 6.9 SUMMARY OF RECOMMENDED EXPERIMENTAL DESIGN METHODS BY USE CASE ...... 50 6.9.1 Sample Size Determination ...... 51 7 Data Collection Plan ...... 55 7.1 DATA COLLECTION PLAN ...... 55 7.1.1 Use Case 1: Morning Backups ...... 55 7.1.2 Use Case 1: Morning Backups ...... 57 7.1.3 Use Case 3: Pedestrian Safety ...... 58 7.1.4 Use Case 4: Transit Signal Priority ...... 59 7.1.5 Use Case 5: Streetcar Conflicts ...... 60 7.1.6 Use Case 6: Traffic Progression ...... 61 7.1.7 Participant Action Feedback Protocols ...... 62 7.1.8 Passenger Vehicle Participants ...... 62 7.1.9 Bus Operators ...... 62 7.1.10 Streetcar Operators ...... 62 7.2 DOCUMENT PROCEDURES FOR DATA QUALITY VERIFICATION, DATA CLEANING, PII REMOVAL, AND FUSION OF CV DATA WITH DATA FROM OTHER SOURCES...... 63 7.2.1 CUTR Server ...... 63 7.2.2 Data Quality Checking and Cleaning ...... 65 7.2.3 PII Removal ...... 66 7.2.4 Fusion of CV Data with Other Sources ...... 66 7.3 DOCUMENT PROCEDURES FOR DATA ARCHIVAL ...... 68 8 System Impact Evaluation Plan...... 70 8.1 USE CASE 1: MORNING BACKUPS ...... 70 8.1.1 Mobility ...... 70 U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |v
8.1.2 Safety ...... 71 8.1.3 Environment...... 71 8.2 USE CASE 2: WRONG-WAY ENTRIES ...... 72 8.2.1 Mobility ...... 73 8.2.2 Safety ...... 73 8.2.3 Environment...... 73 8.3 USE CASE 3: PEDESTRIAN SAFETY ...... 73 8.3.1 Mobility ...... 73 8.3.2 Safety ...... 74 8.3.3 Environment...... 74 8.4 USE CASE 4: TRANSIT SIGNAL PRIORITY ...... 75 8.4.1 Mobility ...... 75 8.4.2 Safety ...... 76 8.4.3 Environment...... 76 8.5 USE CASE 5: STREETCAR CONFLICTS ...... 76 8.5.1 Mobility ...... 76 8.5.2 Safety ...... 76 8.5.3 Environment...... 76 8.6 USE CASE 6: TRAFFIC PROGRESSION ...... 76 8.6.1 Mobility ...... 76 8.6.2 Safety ...... 77 8.6.3 Environment...... 77 9 Performance Reporting ...... 78 9.1 REPORTING TO THE COMMUNITY AND STAKEHOLDERS ...... 78 9.1.1 Performance Measurement Evaluation Dashboard (PMED) ...... 78 9.2 REPORTING TO INDEPENDENT EVALUATORS ...... 79 9.3 REPORTING FREQUENCY ...... 79 10 Support for Independent Evaluation (IE) Effort ...... 80 10.1 PHYSICAL ELEMENTS DATA FLOW ...... 80 10.1.1 Safety CV Evaluation Data ...... 80 10.1.2 Mobility CV Evaluation Data ...... 80 10.1.3 Non-CV Data ...... 80 10.2 PARTICIPANT SURVEYS ...... 81 11 Data Sharing Framework ...... 82 11.1 CV PILOT DATA ...... 82 11.2 NON-CV DATA ...... 83 11.3 DATA PRIVACY ...... 83 11.3.1 PII Removal from Data Logs ...... 83 11.3.2 Data Sharing Agreement ...... 84 11.4 DATA PREPARATION ...... 84 11.5 TRANSMITTING DATA ...... 85 12 Conclusions ...... 87 U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |vi
13 References ...... 88 14 Appendices ...... 90 14.1 APPENDIX A: REPORT ON PEDESTRIAN APPLICATION RELIABILITY ...... 91 14.1.1 Overview ...... 91 14.1.2 Findings ...... 91 14.1.3 Improved PED-X Operation ...... 93 14.2 APPENDIX B: CV DATASETS METADATA AND DATA DICTIONARY ...... 95 14.2.1 RSU Data Logs ...... 95 14.2.2 Basic Safety Message (BSM) ...... 96 14.2.3 Signal Phasing and Timing Message (SPaT) Messages ...... 100 14.2.4 MAP Data Message ...... 102 14.2.5 Traveler Information Message (TIM) ...... 113 14.2.6 Signal Request Message (SRM) ...... 121 14.2.7 Signal Status Message (SSM) ...... 124 14.2.8 Multi-Modal Intelligent Traffic Signal System (MMITSS) ...... 125 14.2.9 PED-X Personal Safety Message (PSM) ...... 128 14.3 APPENDIX C: OBU DATA LOGS ...... 129 14.4 APPENDIX D: NON-CV DATASETS METADATA AND DICTIONARY ...... 131 14.4.1 Bluetooth Data ...... 131 14.4.2 Transit Data ...... 135 14.4.3 Weather Data...... 137 14.4.4 Event Logs ...... 138
List of Figures Figure 2-1 THEA Focused Pilot Area ...... 6 Figure 2-2 Selmon Expressway and Environs ...... 7 Figure 2-3 Collisions REL at E. Twiggs St...... 8 Figure 2-4 TECO Line Streetcar ...... 9 Figure 3-1 Use Case 1 – Routes and Roadside Equipment ...... 13 Figure 3-2 Use Case 2 – Routes and Roadside Equipment ...... 14 Figure 3-3 Use Case 3 – Routes and Roadside Equipment ...... 15 Figure 3-4 Use Case 4 – Routes and Roadside Equipment ...... 16 Figure 3-5 Use Case 4 – CV Pilot Transit Routes ...... 17 Figure 3-6 Use Case 5 – Routes and Roadside Equipment ...... 18 Figure 3-7 Use Case 6 – Routes and Roadside Equipment ...... 19 Figure 3-8 THEA CV Pilot Deployment Locations ...... 20 Figure 5-1 Average Daily Precipitation – January 2016 ...... 33 Figure 5-2 City of Tampa Attraction Sites ...... 34 Figure 6-1 CV Pilot Study Area – Workers’ Place of Residence ...... 44 Figure 6-2: Required Sample Size and Power ...... 53 Figure 7-1 THEA CV Pilot Planned Data Flow – CUTR Server ...... 64 U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |vii
Figure 7-2 Example of Emission Rates from MOVES ...... 67 Figure 7-3 Example of Building up a Neural Network for Travel Time Fusion ...... 68 Figure 8-1 Moves Project Data Manager ...... 72 Figure 9-1 Performance Measures Reporting Dashboard ...... 79 Figure 11-1 Data Sharing from CUTR Server to USDOT ...... 82 Figure 11-2 Snapshot of SDC New Dataset Provider Form ...... 84 Figure 11-3 Data Transmission Flow ...... 86 Figure 14-1 Pedestrian App ...... 91 Figure 14-2 Pedestrian Crossing ...... 92 Figure 14-3 PED-X Operation - Original ...... 93 Figure 14-4 PED-X Operation - Improved...... 94 Figure 14-6 Sample BSM in JSON Format...... 100 Figure 14-7 Example of SPaT in JSON Format...... 102 Figure 14-8 Example (1) of MMITSS in JSON Format ...... 126 Figure 14-9 Example (2) of MMITSS in JSON Format ...... 127 Figure 14-10 BlueTOAD Readers Within THEA CV Pilot Study Area ...... 131 Figure 14-11 City of Tampa Advisories and Road Closures Website ...... 139 Figure 14-12 RSS Feed Providing Information for Events and Road Closures ...... 139
List of Tables Table 3-1 THEA CV Pilot Deployment Use Case Summary ...... 12 Table 3-2 THEA CV Pilot Deployment Goals and Objectives Summary ...... 20 Table 4-1 Summary of Performance Measures ...... 30 Table 6-1 LEHD OnTheMap - Workers Employed in the CV Pilot Study Area ...... 43 Table 6-2 Recommended Experimental Design ...... 50 Table 6-3 UC1 Baseline Travel Times and Expected CV Improvements – Example 1 ...... 51 Table 6-4 UC1 Baseline Travel Times and Expected CV Improvements – Example 2 ...... 53 Table 7-1 Use Case 1: Morning Backups Data Collection ...... 56 Table 7-2 Use Case 2: Wrong Way Entry Data Collection ...... 57 Table 7-3 Use Case 3: Pedestrian Safety Data Collection ...... 58 Table 7-4 Use Case 4: Transit Signal Priority Data Collection ...... 59 Table 7-5 Use Case 5: Streetcar Conflicts Data Collection ...... 60 Table 7-6 Use Case 6: Traffic Progression Data Collection ...... 61 Table 7-7 Requirements of the Subscribers to the Data Coming from CUTR Server...... 65 Table 14-1 Tampa CV Pilot Metadata – RSU Data Logs ...... 95 Table 14-2 BSM Payload ...... 96 Table 14-3 SPaT Message Payload ...... 100 Table 14-4 MAP Data Message Payload ...... 102 Table 14-5 TIM Payload...... 113 Table 14-6 SRM Payload ...... 122 Table 14-7 SSM Payload ...... 124 Table 14-8 MMITSS Payload ...... 125 Table 14-9 PSM Payload ...... 128 U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |viii
Table 14-10 OBU Data Logs Content ...... 129 Table 14-11 Pre-defined Bluetooth Pairs...... 132 Table 14-12 Bluetooth Data Dictionary...... 133 Table 14-13 Bluetooth-based Sample Travel Time ...... 133 Table 14-14 Field Description ...... 134 Table 14-15-1 Travel Time Reliability Sample Data ...... 135 Table 14-16 Field Description ...... 136 Table 14-17 Transit Sample Data ...... 136 Table 14-18 Weather Data Dictionary ...... 137 Table 14-19 Weather Sample Data-Part 1 ...... 138 Table 14-20 Weather Sample Data-Part 2 ...... 138 Table 14-21 Sample Data ...... 140 Table 14-22 Event Log Data Dictionary ...... 140
List of Acronyms AADT Annual Average Daily Traffic AET All-electronic Toll API Automated Protocol Interface ATE Average Treatment Effect BAA Broad Agency Announcement BSM Basic Safety Message CAMP Crash Avoidance Metrics Partners, LLC CBD Central Business District ConOps Concept of Operations CUTR Center for Urban Transportation Research University of South Florida CoT City of Tampa CV Connected Vehicle DiD Difference-in-Differences DSRC Dedicated Short Range Communication EEBL Emergency Electronic Brake Light Warning ERDW Exit Ramp Deceleration Warning FCW Forward Collision Warning FDOT Florida Department of Transportation FHWA Federal Highway Administration GIS Geographical Information System HART Hillsborough Area Regional Transit IE Independent Evaluator IMA Intersection Movement Assist I-SIG Intelligent Traffic Signal System JSON Java Script Object Notification
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |ix
LEHD U.S. Census Bureau Longitudinal Employer-Household Dynamics LOS Level of Service MAFB MacDill Air Force Base MOVES Motor Vehicle Emission Simulator O&M Operations and Maintenance OBU On-Board Unit ODE Operational Data Environment OEM Original Equipment Manufacturer PCW Pedestrian Collision Warning PED-SIG Mobile Accessible Pedestrian Signal PED-X Pedestrian in Signalized Crosswalk PII Personal Identifiable Information PMED Performance Measurement Evaluation Dashboard PMESP Performance Measurement and Evaluation Support Plan PSM Propensity Score Matching PTMW Pedestrian Transit Movement Warning REL Reversible Express Lanes RSU Roadside Unit SPF Safety Performance Function SDC Secure Data Commons SRM Signal Request Message SSM Signal Status Message TECO Tampa Electric Company THEA Tampa Hillsborough Expressway Authority TMC Traffic Management Center TSP Transit Signal Priority UC Use Case USDOT United States Department of Transportation USF University of South Florida V2I Vehicle to Infrastructure V2V Vehicle to Vehicle V2X Vehicle to Everything VTRFTV Vehicle Turning Right in Front of Transit Vehicle VIN Vehicle Identification Number XML Extensible Markup Language
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |x
1 Introduction
The Tampa Hillsborough Expressway Authority (THEA) CV Pilot Deployment (Pilot) is one of the three connected vehicles (CV) deployment projects selected by Federal Highway Administration (FHWA) in September 2015 as a part of a United States Department of Transportation (USDOT) funded program. This program consists of three phases: Concept Development, Design-Build-Test, and Operations and Maintenance (O&M). The Pilot identifies areas for improved traffic management in Tampa, Florida, that may be improved by the deployment of CV applications. The project team then developed a system concept for deploying these CV applications and after approval from the USDOT designed, deployed, and operates the system.
This document describes the performance measures that will be employed and details the methods that will be used to evaluate impacts of the Pilot deployment and contribute to a national data repository on CV for use by global research partners in furthering the development, deployment, and standardization of connected vehicle technology. The deployment in downtown Tampa, Florida, includes several CV applications, deployed across the highway, transit, and pedestrian modes of transportation on a variety of facility and vehicle types. This Pilot “aims to create a connected urban environment to measure the effect and impact of CVs in Tampa’s vibrant downtown.”
This Pilot project deploys CV applications on an urban expressway, urban arterials, in Tampa’s Central Business District (CBD) and involves vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I) and vehicle-to-“everything” (V2X) technologies.
As the evaluation of the impacts of the Pilot deployment is central to the overall purpose of the project and is a prime motivation for USDOT funding, the Performance Measurement and Evaluation Support Plan represents another critical portion of the development the Pilot. The Broad Agency Announcement (BAA) and subsequent FHWA direction specify that the evaluation “pillars” of Mobility, Safety, Environment, and Agency Efficiency be measured. This report serves to detail THEA’s approach to accomplishing the evaluation of the pilot deployment for these four areas.
1.1 Purpose of the Report
This report is an update of the Performance Measurement and Evaluation Support Plan (PMESP) that was developed during Phase I of the Tampa Pilot Deployment. This update is current through January 2019, describes the performance measurement and evaluation support plan, and details the approaches being planned for providing understandable results of the deployment of CV technologies to FHWA, stakeholders, other users of the system, and research entities. This update also defines how the Tampa team is supporting the efforts of the Independent Evaluators that have been designated by the USDOT.
For each of the six use cases that have been developed and defined through the Pilot planning and design, the data needs, measurement criteria, and experiment type are detailed. Included in this document are discussions of confounding factors and methods that will be used to adjust for them. Also presented are the methods for collecting data and sharing that data. Central to this Performance
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |1
Measurement and Evaluation Support Plan is the description of the linkages between the goals and objectives of the CV Pilot and how achievements of these benefits will be measured and reported.
1.2 Assumptions
The following are assumptions on which the measurement of performance and evaluation support are based:
• Most of the roadside equipment that has been installed remain operational for the duration of Phase 3. • A sufficient number of participant vehicles will remain equipped for the project duration. • The numbers of vehicles and participants recruited and retained throughout the Pilot deployment will be sufficient to perform the evaluation that this plan details. • There are no major changes to the highway and street network within the Study Area (there are several being planned that will be accounted for as confounding factors). • The streetcar will maintain operations through the Pilot. • There are no changes to the bus routes that will be employing CV technologies during the Pilot (as of November 2018). • All data that are anticipated to be available and that are described in this report remain available for the duration of the Pilot. • All data connections detailed in this report, the System Design Document, and the Data Management Plan, are in place and are uninterrupted. • The participant identifier described in this report remains constant throughout the end of Phase 3. • Performance measurement will be based largely on actual data and minimize the employment of simulations. • V2V and V2I application perform as described in the System Design document. If some assumptions are not met, which prohibit the analysis as outlined in this plan, then there will be adjustments to what has been committed to in this version of the plan and revisions made to meet the new conditions.
1.3 Constraints
The following statements have been identified as constraints to the measurement of performance of the Tampa CV Pilot. The number of equipped vehicles and intersections relative to the entire study area necessitates the employment of use cases to measure changes associated with the deployment of CV technology appropriately.
• The number of crashes likely to occur with or without the use of CV technologies will be low or minimal. • High participant turnover will negatively impact the evaluation. • Changes to the operation of the street system within the study area are being planned and must be addressed as a confounding factor. • Any changes to the schedule or route of any of the three express routes included in the Pilot will be problematic for the evaluation team. • A high level of equipment failure will compromise the evaluation results.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |2
• V2V and V2I not performing per design specifications. • The functionality of the TMC Centracs system to route data to the CUTR server.
1.4 Organization of the Report
The remainder of the report is organized into the following sections: Section 2 – CV Pilot Needs The problems and operational needs of the Pilot focus areas are outlined as are the current operational situation and potential improvements resulting from the deployment. Section 3 – CV Pilot Goals and Objectives This section defines the CV Pilot goals, and objectives from a user perspective to enable users, stakeholders, system owners, agency partners, and system developers to achieve consensus and understanding of how the new system will operate and benefit their interests. Section 4 – Performance Measures and Targets The goal-related performance measures are detailed for each of the six use cases that are both quantitative and qualitative, depending on the case. Section 5 – Confounding Factors Confounding factors for the Pilot target area are presented, and those that are identifiable and measurable beforehand (a priori) are discussed. Section 6 – System Deployment Impact Evaluation Design The system deployment’s impact evaluation design is outlined for each of the use cases. Section 7 – Data Collection Plan This section outlines the methods of data collection, protocols for participant action logs, plans for data scrubbing, and procedures for the archiving of the data. Section 8 – System Impact Evaluation Plan Detailed methods for estimating each identified performance measure for each of the use cases are presented. Section 9 – Performance Reporting How performance will be reported to the USDOT, stakeholders, and other users of the system is proposed in this section, along with the anticipated frequency of reporting. Section 10 – Support to Independent Evaluation (IE) Effort The interface between THEA and its core agency partners with the Independent Evaluation effort is addressed. Section 11 – Data Sharing Network Data sharing plans, including providing information to the Secure Data Commons (SDC) and the Intelligent Transportation System (ITS) Public Data Hub, are discussed. Section 12 – Conclusions U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |3
Section 13 – References
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |4
2 CV Pilot Needs
The THEA CV Pilot aims to meet the purposes set forth in the USDOT’s Broad Agency Announcement and the Cooperative Agreements for Phase 2 and Phase 3 of this Pilot to advance and enable safe, interoperable, networked wireless communications among vehicles, the infrastructure, and travelers' personal communications devices and to make surface transportation safer, smarter, and more environmentally friendly. The THEA CV Pilot aims to demonstrate the kinds of improvements that can be made in an urban environment, with Tampa’s CBD as the example site. THEA is deploying site-tailored collections of applications that address specific local needs while laying a foundation for additional local/regional deployment and providing transferable lessons learned for other prospective deployers across the nation.
2.1 Pilot Focus Area System Description
Ybor Channel borders downtown Tampa (Cruise Ship and Commercial Port Channel) to the east, Garrison Channel (a local waterway) to the south, Florida Avenue to the west, and Scott Street to the north. A virtually flat topography near sea level helps to simplify the evaluation of traffic flow parameters. The Focused Pilot Area is depicted in Figure 2-1.
In terms of transportation infrastructure, THEA owns and operates the Selmon Expressway and the Reversible Express Lanes (REL), a reversible elevated express lane, an all-electronic toll (AET) facility that serves as the main commuter route. The Selmon Expressway connects the community of Brandon (a large residential area with a population of 103,000) and Interstate I-75 with downtown Tampa, the Tampa Cruise and Commercial Port, and MacDill Air Force Base (MAFB). THEA also owns Meridian Avenue. Figure 2-2 illustrates the Selmon Expressway and environs.
REL traffic exits at the intersection of Twiggs Street and Meridian Avenue in downtown. The Selmon Expressway, also an AET facility, runs parallel to the REL. Exits 7 and 8 provide ingress and egress for downtown traffic as well. The final exit is at Dale Mabry Highway, which is the location of MAFB’s main gate. Since the spring of 2010, all vehicles on the expressway are electronically tolled as they pass under toll gantries. Payment is made through SunPass or license plate-based accounts.
The area targeted for the Pilot deployment is multi-modal. Meridian Avenue is a major gateway to downtown Tampa and will be the focal point for several of this pilot’s applications.
Channelside Drive, on the east and south borders of the test area, connects to Amalie Arena. Hillsborough Area Regional Transit (HART) bus lines route through this area, and express routes utilize the Selmon Expressway to serve commuters from the Brandon area. The Marion Transit Center is in the northwest section of the Pilot focus area on Marion Street at Laurel Street near I-275. It also serves other express bus routes. The Tampa Electric Company (TECO) Line Streetcar extends through the project area servicing local businesses and the Amalie Arena, special event traffic generators.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |5
Figure 2-1 THEA Focused Pilot Area Source: THEA Global-5 The Tampa Port Authority operates three international cruise ship terminals, as well as cargo facilities located in the Pilot focus area. The Tampa CBD has a high volume of pedestrian activity and an active bike share program. MAFB is located eight miles south of downtown Tampa adjacent to the western terminus of the Selmon Expressway. The Air Force Base has a Transportation Incentive Program (TIP) in which about 1,450 base personnel use express buses or vanpools, and the program provides monthly express HART bus passes to commuters who live in suburban areas east of Tampa. The vanpool program provides commuters, in groups of five or more, funding to secure a passenger van for their daily commute.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |6
Figure 2-2 Selmon Expressway and Environs Source: THEA, HNTB
2.2 Transportation-Related Issues – Mobility, Safety, and Environmental
The Pilot deployment area experiences several different mobility and safety issues daily. The Pilot deployment is designed to try to mitigate these issues using connected vehicle applications. The following are examples of the current conditions that affect safety and mobility in the Pilot focus area and contribute to increased vehicle-related emissions.
The Selmon Expressway’s REL toll lanes’ morning commute endpoint is at the intersection of Twiggs Street and Meridian Avenue. Drivers experience a significant delay during the morning peak hour resulting in and often caused by a correspondingly large number of rear-end crashes and red-light running collisions. Figure 2-3 illustrates the crash experience from January 2010 to December 2013 for the intersection at the terminus of the REL at E. Twiggs Street. Accidents clustered in the vicinity of the terminus of the REL at Meridian Avenue and Twiggs Street lie within the two red ovals shown in Figure 2-3.
The unique nature of the reversible feature of the REL can result in wrong-way entries, despite the numerous warning devices, including signing and gates.
Meridian Avenue and West Kennedy Boulevard experience transit signal delay, pedestrian conflicts, red-light running, and signal coordination issues. At the Hillsborough County Courthouse on Twiggs Street, there is significant competing vehicular and pedestrian traffic during the morning peak hour.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |7
Figure 2-3 Collisions REL at E. Twiggs St. Source: HNTB Arterial Safety Analysis, April 2015 Vehicles conflict with the TECO Line Streetcar (shown in Figure 2-3) at crossing locations throughout the project area, particularly along Channelside Drive. On the eastern portion of the project area along Channelside Drive corridor, visitors experience delays and path-finding difficulties associated with arrivals and departures at the international cruise ship terminals and the Amalie Arena.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |8
Figure 2-4 TECO Line Streetcar Source: THEA Global-5 To improve mobility, enhance safety, mitigate the environmental impacts of queuing, and enhance agency efficiency, a set of six use cases that deploy site-specific CV applications were developed. These use cases are presented in the following section and are consistent with those detailed in the ConOps for the THEA Pilot previously submitted to FHWA.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |9
3 CV Pilot Goals and Objectives
3.1 Introduction
THEA has developed partnerships of multiple stakeholders to deploy applications using data captured from multiple sources (e.g., vehicles, roadside devices, and infrastructure) across multiple elements of the surface transportation system (i.e., transit, arterial, and electronically tolled roadways) to support improved system performance.
3.1.1 Goal 1: Develop and Deploy CV Infrastructure to Support the Applications Identified During Phase 1
Objective 1: Deploy Dedicated Short-Range Communication (DSRC) technologies to support V2V, V2I, and V2X applications.
Objective 2: Upgrade the TMC software to ensure compatibility with CV applications.
Objective 3: Recruit a fleet of transit and private vehicle owners to participate in the CV Pilot by installing and using CV technology offered in the Pilot. (Initially, the plan was also to recruit a group of smartphone owners to participate in the CV Pilot by installing and using a pedestrian app offered in the Pilot. This was later found not to be prudent based on the limitations presented by the current cell phone technology. This is discussed in detail in Use Case 3, Section 4.4.2.
It should be noted that measurement of the accomplishment of Goal 1 will not be measured in the same fashion as this plan details for the remaining goals. Demonstration of progress towards the achievement of Goal 1 is assumed to be an ongoing process of progress meetings, reports, and deliverables to the sponsoring agency, and has been demonstrated by the project’s successful progression through Phase 2 to Phase 3.
Also, the numbers of vehicles equipped, participants, and intersections that are equipped are quantified to provide some measures of the extent of the deployment.
3.1.2 Goal 2: Improve Mobility in the CBD
Objective 1: Replace existing traffic controllers and control systems at key intersections with Intelligent Traffic Signal System (I-SIG) CV technology to improve traffic progression at identified problem areas.
Objective 2: Provide Transit Signal Priority (TSP) applications to help HART buses stay on a predictable schedule.
3.1.3 Goal 3: Reduce the Number of Crashes within the Pilot Area
Objective 1: Provide detection of pedestrians and warnings to drivers of potential pedestrian conflicts.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |10
Objective 2: Provide detection of potential vehicle conflicts with pedestrians. (This will not be achieved and is discussed in detail in Use Case 3, Section 4.4.2)
Objective 3: Provide early detection of wrong-way drivers and issue warnings to wrong-way drivers and upstream motorists.
Objective 4: Give drivers warnings of the REL exit curve speed and stopped vehicles ahead.
Objective 5: Provide detection and warning of potential conflicts between streetcars, vehicles, and pedestrians.
Objective 6: Provide informational messages to pedestrians of a bus starting/stopping (Again, this objective will not be met based on safety-based decisions relating to the location accuracy of current cell phone GPS capabilities.)
3.1.4 Goal 4: Reduce Environmental Impacts within the Pilot Area
Objective 1: Provide CV Mobility and Safety applications to improve overall mobility and reduce stops and idle time within the CBD, thus reducing emissions.
Objective 2: Provide TSP applications to reduce idle time of HART buses.
3.1.5 Goal 5: Improve Agency Efficiency
Objective 1: Improve traffic data collection capability, reducing the costs of collecting data.
Objective 2: Reduce the number of incidents and police and rescue responses to incidents.
Objective 3: Reduce crashes and time agencies take to gather data.
Objective 4: Improve technology for crash statistics gathering.
Objective 5: Improve scheduling and dispatching of HART vehicles with improved trip times and vehicle information.
Objective 6: Reduce overhead of THEA responding to wrong-way entries and crashes on REL exit ramp.
3.1.6 Goal 6: Develop Business Environment for Sustainability
Objective 1: Work with industry sectors that will benefit from CV implementation, i.e., insurance carriers, fleet managers, safety organizations, etc., to provide education on the benefits and seek support for the advancement of the system.
Objective 2: Work with Chambers of Commerce and other business organizations to educate members on the return on investment from increased mobility.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |11
Objective 3: Work with state and local government to encourage positive legislation and funding in support of CV technology.
3.2 Use Cases
The THEA Connected Vehicle Pilot has developed six use cases (UCs) to describe the issues that the project will address (Table 3-1). The next section introduces each use case and CV applications, along with maps showing deployment at specific routes and intersections. Table 3-1 THEA CV Pilot Deployment Use Case Summary Use Case Condition Location
UC1 Morning Backups REL at E. Twiggs Street
UC2 Wrong-Way Entries REL at E. Twiggs Street and Meridian Avenue
UC3 Pedestrian Conflicts E. Twiggs Street at George E. Edgecombe Courthouse Marion Street Transit Mall; Study area sections of Kennedy Boulevard and Jackson Street; Portions of Florida Avenue UC4 Transit Signal Priority and Tampa Street
UC5 Streetcar Conflicts Channelside Drive Meridian Avenue; Portions of Nebraska Avenue and Florida UC6 Traffic Progression Avenue.
3.2.1 Use Case 1: Morning Backups As drivers approach the end of the REL, they enter a curve where the speed limit reduces from 70 miles per hour (MPH) to 40 mph. During morning rush hour, as vehicles exit the REL onto Meridian Street to make a right turn onto East Twiggs Street, the right turn lane backs up. An additional issue is that many of these vehicles then want to make a right turn onto Nebraska Avenue, which is almost an immediate right turn after turning onto East Twiggs Street. The combination of these issues causes the queue to back up onto the REL. This backup causes exiting vehicles wanting to turn right to use the shoulder as part of the right turn lane. As vehicles approach the REL exit, they may not be able to anticipate where the end of the queue is for the right-turn lane, potentially causing them to hard brake or attempt a rapid lane change. The following applications will be deployed for this use case:
• End of Ramp Deceleration Warning (ERDW) • Emergency Electronic Brake Light Warning (EEBL) • Forward Collision Warning (FCW) • Intelligent Signal Control (I-SIG)
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |12
Figure 3-1 Use Case 1 – Routes and Roadside Equipment Source: THEA, Global-5
3.2.2 Use Case 2: Wrong-Way Entries At the exit of the REL on East Twiggs Street, there is a relatively easy opportunity for a driver to become confused and attempt to enter the REL going the wrong way. There are no gates or barriers at the west-bound downtown terminus of the REL to prevent drivers from entering the REL going the wrong way. Drivers that are traveling on East Twiggs Street approaching the intersection where the REL ends, and Meridian Street begins, can mistakenly (or knowingly) enter the REL going the wrong way. Drivers approaching this intersection coming from downtown can inadvertently (or knowingly) make a left turn onto the REL exit. Conversely, drivers on East Twiggs Street approaching this intersection, going towards downtown can inadvertently make a right turn onto the REL exit. Finally, drivers approaching the intersection on Meridian Avenue can potentially veer slightly to the left onto the REL exit. Each of these possibilities is a safety concern. The CV applications to be used in this use case are:
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |13
• Wrong-Way Entry (WWE) • Intersection Movement Assist (IMA) • I-SIG
Figure 3-2 Use Case 2 – Routes and Roadside Equipment Source: THEA, Global-5
3.2.3 Use Case 3: Pedestrian Conflicts At the George E. Edgecombe Hillsborough County Courthouse, there is one primary crosswalk for pedestrian access to the main parking garage. The crosswalk is marked and has a yellow flashing beacon light to warn drivers that they are approaching a crosswalk. This crosswalk is the primary route for jurors, lawyers, and other people to get to and from the courthouse. During morning rush hour, there is significant pedestrian traffic as potential jurors unfamiliar with the area are attempting to arrive on time. This significant pedestrian traffic is compounded on Mondays and Tuesdays when new juror pools of up to 400 persons are required to report during rush hour. Lack of attention by drivers causes a safety concern for pedestrians trying to reach the courthouse. Some pedestrians elect to
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |14
take a shortcut by crossing East Twiggs Street mid-block and outside the crosswalk. Planned CV deployment at this location includes the following application:
• Pedestrian Collision Warning (PCW)
Figure 3-3 Use Case 3 – Routes and Roadside Equipment Source: THEA, Global-5
3.2.4 Use Case 4: Transit Signal Priority Two express bus routes (24 LX and 25 LX) use the Selmon Expressway to connect the east and west sides of the metropolitan area and exit the Expressway to serve a stop in downtown. There are large residential communities in areas of Brandon, Riverview, and Fish Hawk to the east of downtown. Aside from the employment center associated with the CBD, MAFB is situated close to the western or southern terminus of the Selmon Expressway. CV technologies will be deployed to attempt to create a
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |15
“virtual transit connection” between the two portions of the expressway by providing more reliable transit mobility using TSP as the express buses negotiate the surface streets of downtown in the morning and evening peaks.
Figure 3-4 Use Case 4 – Routes and Roadside Equipment Source: THEA, Global-5 Marion Street is a two-lane urban arterial road in the heart of the Tampa CBD that serves as a primary bus route, which on the north end terminates at the Marion Transit Center. During weekdays it is dedicated solely to transit vehicle use. HART operates several routes that converge onto Marion Street and heads to Marion Street Transit Station. The third express route that will be included in this use case is Route 20X that provides limited express bus service to and from the northern residential communities in New Tampa and Wesley Chapel through the CBD and south using the Selmon Expressway to and from MAFB. There are several morning drop off points and evening pick up points along the Marion Street transit facility.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |16
As the express service departs the controlled-access highway system and enters the downtown grid, the buses experience congestion. When congestion occurs, the buses are unable to reach their stops promptly, causing them to fall behind schedule and compromising mobility. CV Technology will be used to address mobility concerns. Buses and traffic signals will communicate, and if a bus is behind schedule, the traffic signal system will either give the bus priority or flush the queue allowing the bus to reach its stop, assuming there are no other higher priorities. The buses on the routes described here will benefit from TSP while in the study area in this use case.
Figure 3-5 Use Case 4 – CV Pilot Transit Routes Source: HART, CUTR It is currently planned to equip 10 HART vehicles that will be assigned to three express routes for the duration of the Pilot. Lastly, a pedestrian cell phone application will be deployed to alert nearby participants with the PTMW app installed on their smartphones that an equipped bus is about to begin to move or stop. CV applications planned for deployment of this use case include:
• IMA
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |17
• I-SIG • Transit Signal Priority (TSP)
3.2.5 Use Case 5: Streetcar Conflicts The TECO Streetcar runs along Channelside Drive from the Amalie Arena area up Channelside Drive, north, past the Selmon Expressway. The streetcar is a steel wheel on steel rail fixed-guideway system in a dedicated right of way. An overhead catenary powers it and crosses intersections at grade. As a result, at various stops along the streetcar route, vehicles may have to turn right in front of a stopped streetcar. As the pedestrians disembark from the streetcar and the streetcar prepares to depart, a vehicle may turn right in front of the streetcar. This situation occurs at signalized and non-signalized intersections, and none have a right turn protected movement. CV technology will be used to provide information to streetcar operators and drivers to improve safety around these locations. The CV application to be used in this use case is:
• Vehicle Turning Right in Front of Transit Vehicle (VTRFTV)
Figure 3-6 Use Case 5 – Routes and Roadside Equipment Source: THEA, Global-5
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |18
3.2.6 Use Case 6: Traffic Progression Meridian Avenue has significant congestion and delay during morning peak travel periods. This congestion is due to many MAFB commuters exiting the Selmon Expressway at downtown and traveling through downtown arterial routes to reach the MAFB entrance. As some of these commuters are using surface roads through downtown, they interact with other traffic and pedestrians, increasing the likelihood of entering into conflicts. In addition to Meridian Avenue, Florida Avenue, and Nebraska Avenue (sections within the study area) experience similar issues for downtown commuters. The CV application that will be used in this use case is:
• I-SIG
Figure 3-7 Use Case 6 – Routes and Roadside Equipment Source: THEA, Global-5 Figure 3-8 illustrates the combination of all of the use cases in the study area.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |19
Figure 3-8 THEA CV Pilot Deployment Locations Source: THEA, Global-5 Table 3-2 illustrates the relationships between the goals and objectives from the ConOps document to the use cases. Not all of the objectives relate to all use cases.
Table 3-2 THEA CV Pilot Deployment Goals and Objectives Summary Goal Objectives Use Case Objective 1: Deploy Dedicated Short-Range Communication (DSCR) technologies to support V2V, V2I, and V2X Goal 1: Develop and applications Deploy CV Objective 2: Upgrade TMC software to ensure compatibility Infrastructure to All Use Cases with CV applications Support Applications Objective 3: Recruit a fleet of transit and private vehicle Identified in Phase 1 owners to participate in the CV Pilot by installing and using CV technology offered in the pilot Objective 1: Replace existing traffic controllers and control Use Case 1 systems at key intersections with I-SIG CV technology to Goal 2: Improve Use Case 3 improve traffic progression Mobility in CBD Use Case 4 Objective 2: Help HART buses stay on predictable schedule Use Case 6 through TSP applications
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |20
Goal Objectives Use Case Objective 1: Provide detection of pedestrians and warnings to drivers of potential pedestrian conflicts. Use Case 1 Goal 3: Reduce Number Objective 2: Provide early detection of wrong-way drivers and Use Case 2 of Crashes within the issue warnings to wrong-way drivers and upstream motorists. Use Case 3 Pilot Area Objective 3: Give drivers warnings of the REL exit curve speed Use Case 5 and stopped vehicles ahead. Use Case 6 Objective 4: Provide detection and warning of potential conflicts between streetcars, vehicles, and pedestrians. Objective 1: Provide CV mobility and safety applications to Use Case 1 Goal 4: Reduce improve overall mobility and reduce stops and idle time within Use Case 2 Environmental Impacts the CBD, thus reducing emissions Use Case 3 within the Pilot Area Objective 2: Provide TSP applications to reduce HART buses Use Case 4 idle time Use Case 6 Objective 1: Improve data collection capability, reducing the costs of collecting data Objective 2: Reduce the number of incidents and police and rescue responses to incidents Objective 3: Reduce crashes and time agencies take to gather Goal 5: Improve data All Use Cases Agency Efficiency Objective 4: Improve technology for crash statistics gathering Objective 5: Improve scheduling and dispatching of HART vehicles with improved trip times and vehicle information Objective 6: Reduce THEA’s overhead in responding to wrong-way entries and crashes on REL exit ramp Objective 1: Work with CAMP, OEMs, and third-party developers to develop business cases for advancing CV-ready vehicles Objective 2: Work with industry sectors that will benefit from CV implementation to provide education on the benefits and Goal 6: Develop Ongoing and a seek support for the advancement of the system Business Environment post Pilot Objective 3: Work with Chambers of Commerce and other for Sustainability initiative business organizations to educate members on the return on investment from increased mobility Objective 4: Work with state and local government to encourage positive legislation and funding in support of CV technology
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |21
4 Performance Measures and Targets
4.1 Introduction
Performance Measures for the THEA CV Pilot will ascertain the effectiveness of the use cases based on the four “pillars” of mobility, safety, environment, and agency efficiency. This section identifies performance measures at the use-case level as tied to the overall goals of the CV Pilot. The performance measures are intended to be clear, reliable, and responsive to change and are tied to the target values discussed in the approved ConOps document. The performance measures will be computed for each use case, with output stored at the CUTR server and transmitted to the secure data commons (SDC) and performance measurement evaluation dashboard (PMED) to inform the public at large. Beyond meeting reporting requirements and IE needs, these data will serve to conduct a system-deployment impact evaluation (see Section 8).
For the Performance Measurement for this Pilot, the CV activation conditions reflect the conditions under which a connected vehicle application has been activated and generated warnings for the driver. These conditions can occur at all times, and for the whole participant population.
4.2 Use Case 1: Morning Backups
Performance evaluation measurement will include mobility, safety, environment, and agency efficiency.
4.2.1 Mobility To determine the mobility benefits for Use Case 1, analyzation of the following measures will be performed for the before and after CV deployment:
• Travel time and travel time reliability, using segment-level travel time reliability analysis for auto-mode travel-time reliability (by comparing the 90th or 95th percentile travel times, measured in minutes, before and after deployment conditions): o From the intersection of East Twiggs Street and REL to 2500 ft. on REL (end of the study area) o From East Twiggs Street and Meridian Avenue to Nebraska Avenue and Cass Street • Queue length (maximum queue length in meters as measured by I-SIG output) • Delay (average delay for auto mode: compared to the average delay data obtained during before implementation, as explained under Section 6) • Throughput (for auto mode, from the intersection of East Twiggs Street and REL to 2500 feet on REL • Percentage (%) of arrival on green (at REL off-ramp exit and East Twiggs Street and Meridian Avenue)
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |22
4.2.2 Safety To determine the safety benefits for use case 1, the following performance measures are considered for the REL/Twiggs/Meridian intersection and the segment length described above: • Number, type, and severity of crashes/crash rate. The types of crashes to be considered include rear end, and sideswipe/angle crashes due to sudden lane change maneuvers. Crash information will be obtained from Florida’s Integrated Report Exchange System (FIRES) provided by the Department of Highway Safety and Motor Vehicles (DHSMV). The severity will be determined based on the injury level in the KABCO scale. Crash information is added daily but is not considered to be official until reconciled by DHSMV. This usually occurs four to six months after the end of the calendar year. Crash details might, therefore, change until the crash data is deemed official. • Number, type, and severity of conflicts or near misses from BSM analysis. The types of conflicts are the same as the types of crashes, i.e., rear-end conflicts, and sideswipe/angle conflicts due to sudden lane change maneuvers. • Number of alerts (warnings) from ERDW, EEBL, and FCW CV apps. • Approaching speed and queue on the REL segment from BSM analysis.
Changes in safety for the REL segment will be analyzed through a collection of vehicle crash rates by type and severity and by assessing changes in vehicular conflicts and near misses for the before and after CV activation scenarios via the treatment (i.e., participants receiving warning from apps) and control (i.e., participants not receiving warning from apps) groups. The number of alerts generated by the ERDW, EEBL, and FCW apps will be compared for treatment and control groups, and the corresponding reaction to the alerts from the treatment group (via BSM data) will be evaluated for timeliness. Also, the approaching vehicle speed on the REL will be considered for the safety performance measurement analysis, since this approach speed will be a good indication of whether the equipped vehicles receive and react to the CV advanced warning of a queue forming on the REL from the ERDW app. The approaching speed on the REL will be evaluated along the segment defined in Section 4.2.1 and by speed zone to aid in evaluating if the drivers respond to the alerts.
4.2.3 Environment To determine environmental benefits for Use Case 1, the following vehicle-caused emission types will be considered: • Running exhaust • Crankcase running exhaust • Crankcase extended idle exhaust
The major input of measuring vehicle-caused emissions relies on history trajectory vehicle-path information, including instantaneous speed, acceleration rate, distance traveled, and the number of vehicles. The emissions are measured using the changes in speed and acceleration rate. The Environmental Protection Agency (EPA) Motor Vehicle Emission Simulator (MOVES) modeling system is used to assist in estimating emission rates (measured in grams per mile). Section 8 discusses the approach to MOVES customization to reflect the CV Pilot study area baseline environmental and travel conditions.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |23
4.2.4 Agency Efficiency To determine the agency efficiency benefits for Use Case 1, as outlined in Section 3.1.5, the research team will be required to analyze the following performance measures: • Mobility improvements observed from mobility performance measures described above as mobility improvements will lead to facility efficiency and perceived and actual agency efficiency benefits. • Safety improvements observed from safety performance measures described above as safety improvements (fewer incidents) will decrease delays, decrease required response to incidents, and increase agency efficiency benefits. • Customer satisfaction through opinion survey and/or CV app feedback, as participants are welcomed to provide feedback for the services they obtain and their interaction with the CV applications.
4.3 Use Case 2: Wrong-Way Entries 4.3.1 Mobility This use case is not expected to generate measurable changes in mobility.
4.3.2 Safety Changes in crashes for East Twiggs Street at REL intersection will be analyzed through vehicle crash rates along with the type of vehicular conflicts or near misses for the before and after CV deployment and activation periods. Crash history analysis for the pre-deployment period does not indicate many crashes due to wrong-way entry; therefore, the main measure will be the reduction of the wrong-way entry maneuver and subsequent conflicts because of it.
To determine the safety benefits for Use Case 2, the following performance measures are considered for the REL/Twiggs/Meridian intersection described above:
• Number, type, and severity of crashes/crash rate • Number, type, and severity of conflicts/near misses from BSM analysis • Number and frequency of alerts from WWE app
Crash comparison for East Twiggs Street and the REL segment will be analyzed through vehicle crash rates for the before and after CV deployment periods. Also, the number, type, and severity of vehicular conflicts and near misses will be evaluated via the treatment and control groups through BSM data. Finally, the number of alerts generated from the WWE app and the drivers’ reaction to the alert will be compared for the treatment and control groups. The WWE app provides a sequence of events, where a driver is first warned not to enter the wrong way, but if they do, subsequent and escalating alerts are shown to the driver. In cases of actual wrong-way driving (not just entry), the number of wrong-way driver (WWD) alerts sent to oncoming traffic will also be measured.
4.3.3 Environment This use case is not expected to generate measurable changes in emissions.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |24
4.3.4 Agency Efficiency To assess agency efficiency gains, the following performance measures will be considered:
• Mobility improvements observed from mobility performance measures described above. • Safety improvements observed from safety performance measures described above. • Customer satisfaction through opinion survey and/or CV app feedback.
4.4 Use Case 3: Pedestrian Safety
Performance measurement and monitoring will consider the four pillars of mobility, safety, environment, and agency efficiency.
4.4.1 Mobility Performance measurement will consider vehicle travel time and vehicle travel time reliability. Measurement will be on the segment of roadway in front of the George E. Edgecomb Courthouse, which the crosswalk is located and will be analyzed before and after CV deployment. Also, the determination of maximum vehicle queue length in feet and average vehicular delay in seconds/minutes will be measured. To determine the mobility benefits, the following performance measures will be considered:
• Travel time and travel time reliability using segment-level travel time analysis for auto mode from REL exit at East Twiggs Street and Meridian to East Twiggs Street and North Jefferson Street. • Queue length using maximum queue length measured from REL exit at East Twiggs Street and Meridian to East Twiggs Street and North Jefferson Street. • Vehicle Delay (the average delay for auto mode: compared to the average delay data obtained during before implementation, as explained under Section 6).
4.4.2 Safety For safety, comparison of crashes (both vehicle/vehicle and vehicle/pedestrian) for the segment that includes the crosswalk will be analyzed using vehicle crash rates. Also, the type and severity of vehicular conflicts and near misses for the before and after CV deployment scenarios will be analyzed, and comparison of the number of alerts generated by the PCW application to the drivers will be compared for the treatment and control groups. According to the infrastructure vendor (SIEMENS), during Phase 2 integration testing, the PED-X application was rendered inaccurate and was modified to be able to provide an accurate position of pedestrians for safety purposes. To assess the safety benefits, the following performance measures will be measured:
• Number, type, and severity of crashes/crash rate between vehicles and between vehicles and pedestrians • Number, type, and severity of conflicts/near misses from BSM and PSM analysis* • Number and frequency of alerts from PCW and PED-X apps*
*The PED-X app will be evaluated based on data provided by the LiDARs installed at the crosswalk. On an experimental basis, the app will be used to cross the crosswalk 100 times, and the GPS U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |25
location log from the phone will be compared to the position provided by the LiDAR. The GPS inaccuracies can be determined and logged to support the testing and results of the infrastructure integrator. Appendix A provides a white paper explaining the shortcomings of the pedestrian app. This experiment will be done for research purposes and not for Performance Measurement.
4.4.3 Environment To determine the environmental benefits for Use Case 1, the research team will analyze the following performance measures:
• Changes in idle speed emissions • Changes in running emissions
4.4.4 Agency Efficiency To determine the agency efficiency benefits for Use Case 3, the research team will analyze the following performance measures:
• Mobility improvements observed from mobility performance measures described above. • Safety improvements observed from safety performance measures described above. • Customer satisfaction and CV app feedback through driver surveys.
4.5 Use Case 4: Transit Signal Priority
This use case will be assessed in terms of mobility, environment, and agency efficiency on three major bus regional routes (24LX, 25LX, and 20X) using RSUs installed along Marion Street and at Florida Avenue and Whiting Street, Tampa Street and Whiting Street, and Tampa Street and Kennedy Boulevard.
4.5.1 Mobility Bus travel time and bus route travel-time reliability of its route will be analyzed for the before and after CV deployment scenarios along with the determination of the percentage of bus arrivals on schedule, and percentage of bus arrivals on green for the before and after CV implementation cases. To assess mobility benefits, the following performance measures will be addressed for the three routes included in this use case:
• Bus travel time and bus travel-time reliability average using segment and stop level analysis for transit/bus mode, along with the travel segments of: o From Kennedy Boulevard and Jefferson Street to Tampa Street and Whiting Street (24LX and 25LX A.M.) o From Whiting Street and Florida Avenue to Nebraska Avenue at Kennedy Boulevard (24LX and 25LX P.M.) o From East Tyler Avenue and Marion Street to Tampa Street and Whiting Street (20X A.M.) o From Whiting Street and Florida Avenue to East Tyler Avenue and Marion Street (20X P.M.) • Percentage (%) arrival on schedule (at bus stops along the travel segments) U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |26
• Percentage (%) arrival on green (at signalized intersections along the travel segments) • Signal Priority (at signalized intersections along the travel segments) o Number of times priority is requested and granted o Number of times priority is requested and denied 4.5.2 Safety This use case is not expected to generate measurable changes in safety.
4.5.3 Environment The environmental performance measurement for Use Case 4 will be based on the reduction in transit vehicle emissions on the route before and after CV implementation. To determine the environmental benefits, the following performance measures will be considered:
• Changes in idle speed emissions • Changes in running emissions
4.5.4 Agency Efficiency To determine the agency efficiency benefits, the following performance measures will be tracked:
• Mobility improvements observed from mobility performance measures described above • Customer satisfaction through an opinion survey and/or CV app feedback
4.6 Use Case 5: Streetcar Conflicts
The performance measurement and evaluation for Use Case 5, Street Car Conflicts, will focus on safety and agency efficiency.
4.6.1 Mobility No mobility measurements will be considered for this use case.
4.6.2 Safety Use Case 5 is specific to safety and agency efficiency. Safety in the area surrounding the Amalie Arena area north on Channelside Drive, and past the Selmon Expressway, will be analyzed by measuring changes in vehicle vs. TECO Streetcar crash rates along with the type of the conflicts and near misses these modes experienced for the before and after CV deployment scenarios. Also, comparison of alerts generated by the VTRFTV app will be analyzed for the treatment and control groups. The following safety performance measures will be considered:
• Number, type, and severity of crashes/crash rate for streetcar route • Number, type, and severity of conflicts/near misses from BSM analysis and streetcar log reports • Number and frequency of alerts from the VTRFTV app
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |27
4.6.3 Environment No environmental measurements will be considered for this use case.
4.6.4 Agency Efficiency The agency efficiency performance measurement will be based on a combination of analysis from the safety data and metrics, along with a customer satisfaction analysis through a survey and/or CV app feedback. To assess agency efficiency benefits for Use Case 5, the following performance measures will be considered:
• Safety improvements observed from safety performance measures described above • Customer satisfaction through an opinion survey and/or CV app feedback
4.7 Use Case 6: Traffic Progression
The performance measurement and evaluation will consider all four pillars of mobility, safety, environment, and agency efficiency.
4.7.1 Mobility Mobility will be assessed in terms of vehicle travel time and vehicle travel time reliability of Meridian Avenue and Florida Avenue before and after CV deployment scenarios, along with the determination of vehicle queue length in feet and vehicular delay in seconds/minutes. Additionally, the vehicle percentage of arrivals on green will be determined and analyzed for the before and after conditions. The following performance measures will be considered:
• Travel time and travel time reliability (using segment level travel-time analysis for auto mode): o From the intersection of REL/East Twiggs Street/Meridian Avenue to 2,500 feet on the REL, which marks the end of the study area. o From the Channelside Drive signalized intersection with Meridian Avenue to the South Morgan Street intersection on Channelside Drive. o From the Florida Avenue signalized intersection with East Tyler Street to Florida Avenue signalized intersection with Jackson Street. • Queue length (using I-SIG computed maximum queue length) at each intersection along: o Meridian Avenue to the Channelside Drive signalized intersection. o From Channelside Drive signalized intersection with Meridian Avenue to the South Morgan Street intersection on Channelside Drive. o From the Florida Avenue signalized intersection with East Tyler Street to the Florida Avenue signalized intersection with Jackson Street. • Delay (average delay for auto mode: compared to the average delay data obtained during before implementation, as explained under Section 6) • Throughput: o From the intersection of REL/East Twiggs Street/Meridian Avenue to 2,500 feet on the REL o From Channelside Drive signalized intersection with Meridian Avenue to the South Morgan Street intersection on Channelside Drive. U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |28
o From the Florida Avenue signalized intersection with East Tyler Street to the Florida Avenue signalized intersection with Jackson Street. • Percentage (%) of arrival on green at each intersection along: o Meridian Avenue to the Channelside Drive signalized intersection o From Channelside Drive signalized intersection with Meridian Avenue to the South Morgan Street intersection on Channelside Drive. o From the Florida Avenue signalized intersection with East Tyler Street to the Florida Avenue signalized intersection with Jackson Street.
4.7.2 Safety Although the primary objective of this use case is mobility, safety can also play a role in the improvement of the traffic progression. For safety, comparison of the number, types, and severity of crashes along Meridian Avenue, Florida Avenue, and part of Nebraska will be analyzed. Also, the comparison of the number, type, and severity of conflicts and near misses will be analyzed for the treatment and control groups. To assess the safety benefits, the following performance measures will be considered:
• Number, type, and severity of crashes/crash rate along the three segments • Number, type, and severity of conflicts/near misses via BSM analysis • Vehicle speeds along the segments and through the intersections
4.7.3 Environment To determine the environmental benefits, the following performance measures will be considered:
• Changes in idle speed emissions • Changes in running emissions
4.7.4 Agency Efficiency To determine agency efficiency, the following performance measures will be addressed:
• Mobility improvements observed from mobility performance measures described above • Safety improvements observed from safety performance measures described above • Customer satisfaction through an opinion survey and/or CV app feedback
4.8 Performance Measure Targets
As detailed in the approved ConOps (FHWA-JPO-16-311), it will be challenging to set performance targets. This is because the CV Pilot project is without precedent. For example, the degree of improvements due to mobility apps deployment will depend on the efficiency conditions of the current or baseline traffic network conditions. With traffic signal preemption, improvements in trip time over the signalized network might be as great as 15%, though some loss of efficiency on the side streets may occur. Signal system improvements of 10% would be considered quite effective in carefully managed traffic signal systems like Tampa’s. The study will assess the current baseline and determine project improvements. Generic mobility improvements of approximately 10% will be considered acceptable. Though no prescribed precise goal is definitive at this stage, improvements are expected.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |29
It is unlikely that safety will be directly measurable from the small numbers of crashes that will occur within the study limits. The relatively small samples of reported crashes and confounding factors (e.g., weather) will make statistically significant safety performance measures a challenge. Therefore, for this type of experimental setting, targets might not be achieved or meaningful. For instance, accident avoidance, measured by the number of alerts, may be more important than the number of incidents. This is expected to occur with processing the BSM data. User surveys will measure other surrogate parameters, such as the frequency of alerts, user experience and satisfaction with the app, ratings of distraction or helpfulness, and how an app might be improved. Table 4-1 provides a snapshot of the performance measures to be addressed.
Table 4-1 Summary of Performance Measures UC2 UC4 UC1 UC3 UC5 Performance Wrong- Transit UC6 Traffic Pillars Morning Pedestrian Streetcar Measures Way Signal Progression Backups Safety Conflicts Entries Priority Travel time Travel time reliability Queue length Vehicle delay
Percent (%) arrival on green Bus travel time Mobility Bus route travel- time reliability Percent (%) arrival on schedule Excess time spent in idle Crash comparison Types of crashes Severity of
crashes Type of conflicts
Safety Severity of conflicts Approaching vehicle speed No. of alerts from apps
Emissions reductions in idle
Emissions reductions in Environmental running
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |30
UC2 UC4 UC1 UC3 UC5 Performance Wrong- Transit UC6 Traffic Pillars Morning Pedestrian Streetcar Measures Way Signal Progression Backups Safety Conflicts Entries Priority Mobility improvements through the
mobility pillar analysis Safety improvements through the safety pillar analysis Customer Agency Efficiency Agency satisfaction through opinion survey and/or CV app feedback
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |31
5 Confounding Factors
5.1 Introduction
This section identifies confounding factors that are likely to affect the performance measurement plan.
5.2 Identification of Confounding Factors
The accuracy and effectiveness of performance measurement depend on the presence of concurrent confounding factors. Confounding factors are any events that might arise during the pilot implementation, which can be associated with having an apparent effect on some dependent variables of interest (i.e., performance measures). In a design experiment, confounding factors that are not accounted for during design could either understate or overstate the relevance of treatment effects upon treated units. In extreme cases, confounding factors can lead to spurious relationships between explanatory and dependent variables, with the variables having no direct causal connection, while it may be wrongly inferred that they do.
Two types of confounding factors are likely to arise from the pilot implementation:
• Study-area specific factors (e.g., climate, special events) • Deployment-specific factors (e.g., participant-specific, technology-specific)
Factors that can a priori (i.e., before pilot implementation) be identified, recorded, and measured are defined as observed factors. Factors that cannot be directly observed or measured are defined as unobserved factors. During performance measurement and statistical modeling, observed factors can be accounted for by their proper inclusion as explanatory variables and modeling method, while unobserved factors can be accounted for by utilizing appropriate statistical techniques to reduce omitted-variable bias.
5.3 Study Area-Specific Factors
Given the longitudinal aspect of the pilot deployment, several time-variant factors and events that are specific to the area will be accounted for, spanning from seasonal weather to planned events in the study area main points of attraction, to planned construction development plans, and seasonal cruise line tourism. These factors have the potential to generate confounding information across all use cases by influencing individual travel behavior.
5.3.1 Weather Tampa is characterized by a subtropical climate with hot and humid conditions from mid-May through mid-October coinciding with the rainy season. Summertime weather is consistent from June through September and is characterized by mid-afternoon thunderstorms. These thunderstorms may last for only a few moments to several hours or even for an entire day. During the summer, average monthly rainfall increases to about 7.5 inches from the winter average of 2.5 inches. Also, rain precipitation can U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |32
be above average even during the winter months. For example, in January 2017, rain precipitation was 6.2 inches, compared to the historical 2.2-inch average. Precipitation is not homogenous in the Tampa Bay Area and tends to be higher near bodies of water. Localized weather conditions can have spatially heterogeneous effects on travel behavior. For example, thunderstorms can affect vehicle travel speed (e.g., traveling slower than usual), pedestrian trip patterns, and bus boarding differently at either the origin or end of a trip. Figure 5-1 presents average daily rain precipitation for January 2017 and shows that precipitation in the Brandon Area, where most of the THEA morning peak traffic originates, was higher than in the CV pilot area of Tampa CBD.
Figure 5-1 Average Daily Precipitation – January 2016 Source: NOOA Advanced Hydrologic Precipitation Service; CUTR
To control for weather-related factors at the aggregate level, a daily data log recording temperature, observed precipitation, and other weather-related occurrences will be maintained throughout the study period. Data will come from the professional weather information service provider, World Weather Online. Observed daily precipitation data will be obtained using Automated Programming Interface (API), which rely on a multisensory approach to measure high-resolution weather condition (at hourly intervals) on:
• Current conditions • Hourly one-day forecast • Dynamic radar image • Severe alerts • Dynamic animated radar image • Dynamic animated satellite image • Current tropical storms
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |33
Current condition data provide time-stamped information on current temperature, weather condition, humidity, wind, “feels like” temperature, barometric pressure, and visibility. The API output can be either in eXtensible Markup Language (XML) or JavaScript Object Notification (JSON) format, which can be redacted into a database format to comprise the weather log dataset. The dataset will be then used to merge weather information with the travel datasets. These data will serve as a proxy to control for weather conditions at the disaggregated level in the absence of vehicle BSM windshield wiper data.
5.3.2 Special Events The CV Pilot Study Area is site to several attractions, which draw visitors and residents to attend leisure or business events and generate additional non-seasonal traffic with the potential to introduce confounding information throughout the pilot. Figure 5-2 shows the location of these points of interest.
Figure 5-2 City of Tampa Attraction Sites Source: CUTR
The Tampa Convention Center is a 600,000-square foot facility with a 200,000-square foot exhibit hall. It is located near the southern border of the CV Pilot area, along Channelside Drive and is served by
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |34
the THEA Selmon Expressway and by the TECO Streetcar. There are major planned events for 2018- 20191, including:
• FMEA Professional Development Conference (Jan. 9-12, 2019; attendance 10,000) • Metrocon (Jul. 11-14, 2019; attendance 15,000) • Tampa Bay Comic Con (Aug. 2-4, 2019; attendance 60,000) • Tampa Bay New Car & Truck Show (Nov. 16-18, 2019; attendance 20,000)
The Straz Center, located at the edges of the western study area, is a 335,000-square-foot venue providing a variety of cultural events and educational programs. In 2016, the Straz Center attracted about 545,000 people attending about 1,500 events. The Amalie Arena (formerly known as the Tampa Bay Times Forum) is an event facility used for sporting and concert events.
The Cruise Pier, part of the Port of Tampa, is the home port of five vessels from four cruise lines attracting more than 600,000 passengers annually (average 67,000 monthly) to travel on a variety of 4, 5, 7, and 14-day cruise itineraries.
Also, each year at the end of January, the City of Tampa hosts the Gasparilla Pirate Festival, an annual historical celebration that attracts on average about 300,000 visitors, with attendance increasing in the last few years due to increased marketing efforts.
5.3.3 Tampa Downtown Waterfront Planned Construction New commercial and residential development is expected in the downtown area. The University of South Florida (USF) is building a new facility to relocate the Morsani College of Medicine and USF Health Heart Institute, presently sited at the North Tampa Campus, in proximity to its teaching hospital, Tampa General Hospital. These plans are part of a larger development effort to construct 1.1 million square feet of office space and 660,000 square feet of residential space and turn downtown in a walkable, multimodal, and wellness-centered city. The first phase of construction is planned to be completed within five years. As a result, traffic patterns might be affected by construction mitigation plans, changing commuters’ habitual travel patterns.
All the above study area-specific factors will be accounted for by recording the time and date of the event and recording any quantitative traffic information relating the planned and unplanned event to change in traffic patterns/levels. The City of Tampa Traffic Management Center (TMC) informs the public providing transportation advisories and road closure information.2 The TMC provides schedule and archived information which will be parsed, processed, and stored into a database.
5.4 Deployment-Specific Factors
Deployment-specific confounding factors include all those factors or events that can be potentially triggered by the Pilot implementations. These include equipment malfunction instances as identified by the ConOps Failure/Anomaly/Exception Conditions and Safety Plan, and induced errors by linking data across platforms. Other confounding factors are likely to be introduced by participant
1 https://www.tampagov.net/tcc/calendar 2 https://www.tampagov.net/news-transportation-advisories-road-closures U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |35
identification and selection, their personal use of installed vehicle equipment, and improper use of downloaded applications.
5.4.1 ConOps Failure and Anomaly Conditions ConOps Failure/Anomaly/Exception Conditions, which are specific to each use case activation conditions, are expected to arise when CV technologies, system, or devices are operational and in use during the activation phases, as described in the ConOps.
5.4.2 ConOps Maintenance Conditions During the Pilot deployment, maintenance conditions are expected to arise, which will require temporarily “turning off” the CV technology/system/device(s) during the time where activation conditions will be present. Two types of maintenance situations are likely to occur: 1) Maintenance due to device failure (unexpected); and, 2) Planned system maintenance (expected). Unexpected maintenance conditions will require communication to the affected user(s) and prompt action to minimize the confounding effect. Scheduled maintenance will be conducted during expected normal conditions. When designing and planning maintenance capabilities, consideration for potential impacts to safety-related functionality will be included to eliminate or minimize potential safety risks.
5.4.3 Measurement Errors Due to Concurrent Use of Applications to Measure Performance The concurrent use of different applications to measure performance can lead to data integration issues and measurement error. These issues will be identified during the data recording and cleaning process before performance measurement.
5.5 Experimental Design-Induced Confounding Factors
Participants in the CV Pilot deployment will include drivers, pedestrians, and bus and streetcar operators. Although the primary objective of experimental design is to minimize the presence and influence of confounding factors, the experimental design approach, under use-case-specific constraints, is likely to introduce some form of error in the form of:
• Participant self-selection • Participant attrition • Participant moral hazard
5.5.1 Participant Self-Selection Participant recruitment identifies a treatment and control group following the suggested experimental design as discussed in Section 6 of this document. The recruitment goal is to select a pool of participants where treatment and control groups are randomly selected from a sample of participants that is representative of the users of a system. When sending out requests to participate in the Pilot study, some individuals, due to their specific socio-economic, residential location, and travel behavior characteristics, will tend to self-select to either participate or exclude themselves from the study. Though the experimental design approach will minimize the difference between treatment and control
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |36
units, self-selection will still be an issue, as it will also depend upon the adopted recruitment approach (e.g., phone, internet, snail mail, shopping center booth, etc.).
5.5.2 Participant Attrition Once enrolled as participants, some individuals will likely exit the study due to triggering events, such as a change of job leading to a different commute pattern, vehicle replacement, lack of interest, or other similar factors. When measuring performance at the individual level, statistical methods (e.g., unbalanced panel data methods) will be employed to reduce the impact of ensuing confounding factors.
5.5.3 Participant Moral Hazard Other confounding factors are likely to arise due to participant moral hazards that might be induced by CV equipment or application. A moral hazard is a situation where an individual might undertake a riskier behavior, knowing that it is protected against a risky situation.
Participant recruitment can reduce the impact of confounding factors due to moral hazard. In addition, selected participants will be advised of the limits of the technology and will be required to sign an Informed Consent Form to participate that will explain the limits of the technology and their liability in using the app not as prescribed.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |37
6 System Deployment Impact Evaluation Design
6.1 Introduction
This section details the proposed system deployment impact evaluation design to account and control for the confounding factors identified in Section 5. It discusses the applicable methods and modeling techniques that will be employed to evaluate performance of each of the six use cases. As discussed in Section 5, the presence of confounding factors is likely to pose a challenge in the assessment of the quantitative performance measures and targets identified in Section 4.
The CV Pilot deployment provides a unique opportunity to implement an experimental design to optimize the level of control upon observed and unobserved confounding factors. An experiment is a test or series of tests in which ad-hoc changes are made to the input variables of a process to purposefully observe and identify the reason for changes that may be observed in the output response.
Following the literature, the event for which we want to estimate and quantify the causal effect is defined as the treatment. It follows that a treatment group is a group that receives the treatment or the intervention. In the CV Pilot deployment, the treatment group is the group that is exposed to the application(s) being tested. The outcome indicates the variable(s) that is used to measure the effect of the treatment. In the CV Pilot, the outcome denotes the quantifiable performance measure(s) (e.g., travel time delay, accident reduction).
A well-designed experiment is important because the results and conclusions that can be drawn depend to a large extent on the way the experiment is laid out and the data were collected. A statistical design of experiments is a process of planning the experiment so that appropriate data can be analyzed by appropriately choosing statistical methods, resulting in valid and objective conclusions.
Furthermore, the Pilot will be implemented over time, likely to span over two years. This means that time will be an important variable used to distinguish group participation and to gauge the impact on performance measures. The passage of time, on the other hand, can introduce additional confounding factors, such as the presence of time-variant unobservable events that could mask the true performance of CV technologies.
6.2 Experimental Strategies
In an ideal context, confounding factors can be controlled for by conducting counterfactual analysis via random experimental design. Counterfactual modeling measures the potential outcome in the absence of an intervention, such as the implementation of the CV technologies. Empirically, there are different options for assessing the counterfactual, ranging from a simple before vs. after comparison of outcomes to measuring responses in the context of a randomized experiment. The applicability of each approach is contingent upon the baseline characteristics of each use case defined in the ConOps. U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |38
This plan identifies three approaches to control and minimize the impact of study-area specific and deployment-specific confounding factors:
1. Random Design 2. Quasi-Experimental Design 3. Before and After Comparison (Time Series Analysis)
6.2.1 Random Design In a completely randomized design, study participants are randomly drawn from a representative sample and randomly assigned to a treatment group and a control group. The treatment group comprises those individuals who are assigned to the intervention (i.e., the treatment) and the control group consists of those individuals who are assigned to be excluded from the intervention. Random assignment to the treatment and control groups ensures the two groups are similar and have the same probability of being assigned to either one of the groups. Each unit has one outcome that would manifest if the unit were exposed to the treatment and another outcome that would manifest if the unit were exposed to the control. The treatment effect is the difference between these two potential outcomes. However, the individual-level treatment effect is unobservable because individual units can only receive the treatment or the control, but not both. Random assignment to treatment ensures that units assigned to the treatment and units assigned to the control are identical (over many iterations of the experiment). Indeed, units in both groups have identical distributions of covariates (i.e., explanatory variables) and potential outcomes. Thus, the average outcome among the treatment units serves as a counterfactual for the average outcome among the control units. The differences between these two averages is the average treatment effect (ATE), which is an estimate of the central tendency of the distribution of unobservable individual-level treatment effects. If a sample is randomly drawn from a population, the ATE from the sample is also an estimate of the population ATE. In a fully randomized experiment for the CV Pilot, the ATE would then be:
= ( ) ( ) 𝐴𝐴 𝑁𝑁 𝐴𝐴 𝑁𝑁 1 0 where is treatment at CV technology𝐴𝐴𝐴𝐴𝐴𝐴 activation𝑇𝑇 − 𝑇𝑇 (A);− 𝐶𝐶is treatment− 𝐶𝐶 at normal conditions; is 𝐴𝐴 𝐴𝐴 control at1 CV activation; and is control at normal conditions0 . In the ConOps, normal conditions (N) are those𝑇𝑇 conditions characterized𝑁𝑁 by a “no problem” or𝑇𝑇 “no issue” perspective, without any initiation𝐶𝐶 of the proposed CV technologies,𝐶𝐶 which is as the system operates today. Activation conditions (A), are those “conditions that activate or trigger the CV application.” Note that in the context of this experimental design, those participants selected as controls will have CV applications installed, but the equipment will not be activated to send out warnings. Section 6.3.2 provides details in discussing the preferred experimental design to assess Use Case 1.
While an experiment ensures, in expectation, that potential outcomes (and all covariates) are equivalently distributed in the treatment and control groups, this is not the case in an observational study. In an observational study, units are not assigned to treatment and control randomly, so their assignment to treatment may depend on unobserved or unobservable factors. Observed factors can be statistically controlled (e.g., through regression or matching), but any estimate of the ATE could be confounded by unobservable factors that influenced which units received the treatment versus the control.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |39
During the CV Pilot deployment, full random assignment of participants might be very hard to achieve due to several constraints. For example, in some use cases where users will be adopting an app, it will be difficult (if not impractical) to determine which individual can be assigned to receive information from the app at any given time. In other use cases where individual recruitment is necessary to proceed to CV technology installation within the vehicle, implementation of a randomized design may be feasible. When a fully randomized experimental design cannot be implemented, performance measurement will be based on a quasi-experimental approach.
6.2.2 Quasi-Experimental Design Whenever random assignment to treatment and control group cannot be achieved, a bias in the selection arises. For example, this situation could arise when sampling participants to Use Case 1 (morning backups), as discussed in the next section. Furthermore, self-selection can also occur, which could result in a pool of participants where random assignment to treatment and control might not be achievable. Self-selection leads to bias. If this bias is not controlled for, then statistical inference and estimation of performance measures can either underestimate or overestimate the relevance of a given deployed CV technology.
In this event, quasi-experimental design approaches will be adopted to minimize the bias introduced by not randomly matching treatment and control groups. Quasi-experimental methods share many characteristics of randomized experiments, with the exception that they do not use random assignment. Quasi-experiments can be more representative of real-world conditions, such as when only participants who are willing to be randomly assigned to treatment are available and might form an unrepresentative subset of all participants. However, one of the major disadvantages of quasi- experiments is that the estimates of treatment effects that they produce may not be unbiased. This is because the nonrandom selection process can result in the difference between groups that can be mistakenly ascribed to treatment effects (e.g., the efficacy of CV technology in improving mobility, when mobility improvements might not be realized).
In the empirical literature, several approaches have been developed to reduce this selection bias. The most widely used methods fall within propensity score matching (PSM). PSM is a non-experimental method employed to select comparable units of observation for estimating intervention impacts using comparison group data. Since first introduced by Rosenbaum and Rubin PSM techniques have been applied in several fields of research, such as to study the impact of training on labor wage differentials and to estimate the impact of welfare programs [5]. It has also been used to evaluate the impact of transportation investments on land-use [6], employment [7], and population growth [7, 8]. For example, Funderburg et al. [8] used PSM to select a set of comparable census tracts to use as controls in evaluating the impact of transportation infrastructure investments on employment and population growth.
Quasi-experimental approaches have been increasingly used to reduce estimation bias and to economize on behavioral specification complexity and data requirements. For example, Rephann and Isserman [9] devised methods to match control to treatment counties for policy evaluation of infrastructure investments on county development. At a less aggregate level, Concas [6] used propensity score matching to analyze the impact of transportation infrastructure improvements on residential and commercial property prices.
The proposed approach is to use propensity score matching to match controls to treatment. To identify suitable controls, the first step is to estimate the propensity score for each treatment and potential U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |40
control by running a logistic regression with the dependent variable set to Y=1 if the individual is selected as part of the treatment group and Y=0 if otherwise (i.e., the rest of the participants), and using a set of controls as explanatory variables. The controls or explanatory variables would include socio-demographic factors, variables describing the individual current travel behavior, and vehicle stock information. In a parametric model, the propensity score is the predicted probability:
( ) = ′ 1 𝛼𝛼�+( 𝛽𝛽� 𝑥𝑥 ) 𝑒𝑒 ′ 𝑝𝑝̂ 𝛼𝛼�+𝛽𝛽� 𝑥𝑥 where indicates the intercept parameter estimate,− 𝑒𝑒 represents the vector of parameter estimates, and x is the vector of explanatory variables (e.g., the socio-demographic variables). ̂ 𝛼𝛼� 𝛽𝛽 To ensure the best selection of controls, the performance plan will also employ a data-driven approach, to derive a non-parametric propensity score. This study will use the nonparametric conditional density estimation method discussed in Li and Racine [10] and implemented by the R np package [11]. The use of nonparametric generated propensity score in addition to the logistic regression generated propensity score is intended to ensure a robust selection of matched controls.
6.2.2.1 Choice of Matching Algorithms The logistic regression and the nonparametric regression scores are used in this step to find the matching controls by applying a set of matching algorithms. Using the estimated propensity scores (from the logistic and from the nonparametric regressions), three different matching algorithms will be applied: 1) the nearest neighbor matching (one-to-one without replacement); 2) the global minimization algorithm based on Ming and Rosenbaum [12]; and, 3) the genetic matching method of Abadie and Imbens [13]. Matching is conducted using the R MatchIt package [14].
The nearest neighbor employs a “greedy” algorithm to cycle through each treatment unit (T) one at a time, selecting the control unit (C) with the smallest distance to the treatment unit (T). The global minimization algorithm treats the distance between treatment and potential controls as a cost from going from one node to another over a network. The problem requires assigning distances to each node and finding the path that minimizes the total distance. Rosenbaum and Rubin [4] argued that the collection of matches found using optimal matching can have substantially better balance than matches found using greedy matching, without much loss in computational speed. Genetic matching automates the process of finding by implementing matching with replacement using the method of Abadie and Imbens [13] where balance is determined by a set of two univariate tests, paired t-test for dichotomous variables and a Kolmogorov-Smirnov test for multinomial and continuous variables.
The accuracy of the matching process will be ensured by comparing the differences in means of before vs. after matching and summaries based on quantile-quantile plots that compare the empirical distributions of each explanatory variable.
Finally, the analysis will rank the matched controls based on the number of matching algorithms. This allows further selecting a subset of matched control groups based on the number of matched algorithms.
Non-parametric regression produces a second propensity score upon which the matching algorithms are applied to select the matched controls. Finally, the matched controls identified with the logistic regression score are compared to those identified using the non-parametric regression score. The U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |41
matched controls will then be selected for quasi-experimental analysis using the difference-in- differences approach, as discussed below.
6.2.2.2 Difference-in-Differences (DiD) Approach Given the longitudinal context of the study, evaluation under randomized design and quasi- experimental will be conducted within a Difference-in-Differences (DiD) design. DiD is a research design for estimating causal effects from randomized and quasi-experimental designs. It follows from the definition of the average treatment effect defined earlier in this document. DiD is widely used in empirical economics; for example, to estimate the effects of policy interventions and policy changes that do not affect everybody at the same time and in the same way.
To analyze the impact on performance measures prices, the proposed general functional specification will be adopted:3 = + + + + +
𝑖𝑖 0 1 2 3 𝑘𝑘 𝑘𝑘 𝑖𝑖 where is the mobility performance𝑦𝑦 𝛼𝛼 measure𝛼𝛼 𝑇𝑇 𝛼𝛼 tracked𝑌𝑌𝑌𝑌 𝛼𝛼for𝑇𝑇 individual𝑇𝑇𝑇𝑇 β 𝑥𝑥 (i); T𝑢𝑢 is a categorical variable indicating𝑖𝑖 that the individual belongs to the treatment group (T=1) or the control group (T=0); PH is a time categorical𝑦𝑦 variable indicating treatment phase (PH=1 treatment phase, 0= base or reference); and, is a vector of controls measuring changes study area-specific factors (e.g., changes in weather conditions). The parameter of interest ( ), the difference-in-differences estimator (DiD), 𝑥𝑥𝑖𝑖𝑖𝑖 measures the difference in housing price over treatment3 phases and is equal to: 𝛼𝛼
= , , , ,
𝛼𝛼�3 �𝑦𝑦�𝑃𝑃𝑃𝑃=1 𝑇𝑇=1 − 𝑦𝑦�𝑃𝑃𝑃𝑃=1 𝑇𝑇=0� − �𝑦𝑦�𝑃𝑃𝑃𝑃=0 𝑇𝑇=1 − 𝑦𝑦�𝑃𝑃𝑃𝑃=0 𝑇𝑇=0� The parameter measures the difference in average performance measure (e.g., travel time savings, travel time3 reliability) between treatment and control groups because of CV technology deployment, after𝛼𝛼� controlling for observed and unobserved confounding factors. Essentially, by estimating , the question we will seek to answer is: What would have happened to the treated units’ performance measures had they not been treated with the adopted CV technology? 𝛼𝛼�3 6.2.3 Before and After Comparison (Time Series Analysis) This is the least-preferred approach because it relies only on a comparison of time trends in performance measures (e.g., travel times, risk avoidance) without resorting to direct identification of treatment and control groups. The goal is to assess if the treatment (i.e., the CV technology deployment) has caused a change in pattern upon the baseline conditions using a pretest-posttest approach. The empirical analysis lends itself to comparing changes in the experimental subjects over time using an interrupted time series approach where the series is broken into intervals representing interventions [15, 16].
Whenever adopted, the approach will utilize the performance measures data collected throughout the Pilot implementation, with a design strategy focused on the timing of the treatment. In this instance, the first period of data collection will take place, which defines the baseline. In a subsequent period, the treatment (i.e., the CV technology) will be applied as data collection, and performance
3 For notational convenience the time subscript is omitted. U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |42
measurement continues. Study-area specific confounding factors are recorded concurrently to serve as explanatory variables in time series statistical analysis.
6.3 Use Case 1: Morning Backups
The focus of this use case is on drivers exiting the Selmon Expressway REL at the intersection of Meridian Avenue and Twiggs Street during the morning peak period causing morning backups in the system. As detailed in Section 4, applicable quantitative measures for this use case require data collection and analysis of travel patterns and behavior of drivers and patrons of the Selmon Expressway REL.
6.3.1 Background on Baseline Commuting Patterns Historical traffic data on the REL section leading to Twiggs Street amount to 16,000 vehicles average annual daily traffic (AADT) in 2017 [17]. AADT on the last section should approximate the number of vehicles coming to the end of the REL. Looking at AADT only, it would be impractical to proceed to the identification of the population of individuals from which to sample treatment and control groups. Although information exists about the current patrons of the THEA Expressway REL, the population of users of the system who travel during those normal conditions described in the ConOps is not known. Secondary, publicly-available data provide some insight into the REL patrons and identify the user population from which to draw a sample randomly.
The U.S. Census Bureau’s Longitudinal Employer-Household Dynamics (LEHD) program allows conducting spatial analysis of workers’ commuting patterns by combining federal, state, and Census Bureau data on employers and employees [18]. Through the OnTheMap program, a user can import Geographic Information Systems (GIS)-produced shapefiles identifying specific study areas (i.e., CV Pilot study area) and analyze worker/job commuting patterns. The most recent data is for 2015, which provide a baseline picture of workers’ travel patterns to and from the CV Pilot study area. LEHD data can be used to gather information on the potential pool of participants to the Use Case 1 (Morning Backups), Use Case 2 (Wrong-Way Entry), and Use Case 6 (Traffic Progression).
According to LEHD, there are a total of 51,071 workers employed in the CV Pilot study area, the vast majority living in surrounding areas, as detailed in Table 6-1. Most workers employed in the study area (98.0%) commute to work and travel a distance less than 24 miles. About 15.4% commute to the nearby bedroom community of Brandon and surrounding cities of Riverview and Valrico.
Table 6-1 LEHD OnTheMap - Workers Employed in the CV Pilot Study Area CV Pilot Area Workers Count/Freq. Working in the CV Pilot Area 51,071 Age 29 or younger 13.80% Age 30 to 54 61.30% Age 55 or older 24.80% Working in the CV Pilot Area but living elsewhere 51,582 Male 39.30% Female 60.70% White 78.10% Black or African American 18.10% Hispanic or Latino 17.80%
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |43
CV Pilot Area Workers Count/Freq. Earning $1,250 per month or less 9.00% Earning $1,251 to $3,333 per month 28.90% Earning more than $3,333 per month 62.00% Living in Brandon, Riverview, or Valrico 15.40% Traveling less than 10 miles 45.20% Traveling 10 to 24 miles 42.80%
Figure 6-1 is generated using LEHD data to geographically locate where workers employed in the CV Pilot study area reside.
Figure 6-1 CV Pilot Study Area – Workers’ Place of Residence Source: LEHD, CUTR
6.3.2 Recommended Experimental Design Use Case 1 presents characteristics that can lead, at a minimum, to a quasi-experimental approach, and, in a best-case scenario, to a randomized design experiment (the preferred approach). This is because there is some form of identifying and selecting treatment control participants using the information gathered above. It is recognized that participant recruitment is likely to encounter constraints leading to sample selection from which a fully random sample of controls might not be obtainable. In this case, the second-best approach is the quasi-experiment, leading first to the
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |44
identification of the treatment group, and, subsequently, to the assembling of a control group that will be matched to the treatment based on propensity score matching methods discussed above.
Given the longitudinal nature of the study, the approach to experimental design will consist of two stages. 6.3.2.1 Stage I Upon identification of the target population and required sample size (minimum sample size, plus additional buffer due to participant entry/exit), individual participation will be implemented. The experimental design approach will follow these steps:
1. Participant assignment (stratification) to treatment (T) and control (C), where both T and C have vehicles equipped with CV technology (e.g., ERDW, EEBL, FCW) 2. Baseline Establishment CV Pilot Scenarios: I. Normal Conditions ( and ), where • 𝑁𝑁 𝑁𝑁 are the0 treated participants equipped with CV technology but not receiving𝑁𝑁 𝑇𝑇 warnings;𝐶𝐶 0 • 𝑇𝑇 are the control the participants equipped with CV technology, e.g., but𝑁𝑁 not receiving warnings; II. Activation Conditions𝐶𝐶 ( and ), where • 𝐴𝐴 𝐴𝐴 are the 0treated participants equipped with CV technology, e.g., but 𝐴𝐴 𝑇𝑇 𝐶𝐶 not0 receiving warnings; • 𝑇𝑇 are the control participant equipped with CV technology, e.g., but not receiving𝐴𝐴 warnings; 3. Data recording and analysis𝐶𝐶 to establish optimal timing of Phase II I. Concurrent recording of observable confounding factors
In the ConOps, normal conditions (N) are those conditions characterized by a “no problem” or “no issue” perspective, without any initiation of the proposed CV technologies, which is as the system operates today. Activation conditions (A), are those “conditions that activate or trigger the CV application.”
The goal of Stage I (Baseline Establishment) is to define a baseline where the response in the travel behavior of the treatment group during normal and activation conditions can be measured and assessed, before entering Stage II, where the CV technologies will be “turned on” and warnings will be issued during activation conditions. Also, this baseline stage will provide information as the CV technologies go through the first installation in the participants’ vehicles to identify relevant issues at the onset of the Pilot implementation.
6.3.2.2 Stage II After performance measurement data collection and measurement of Stage I, Stage II will be initiated and timed to mimic Stage I baseline travel behavior conditions. This stage will consist of the following steps:
1. CV Normal Conditions I. are the treated participants equipped with CV technology and receiving warnings; 𝑁𝑁 II. 1 are control participant equipped with CV technology, but not receiving warnings; 2. CV Activation𝑇𝑇𝑁𝑁 Conditions where: I. 𝐶𝐶 are treated participants equipped with CV technology and receiving warnings; 𝐴𝐴 1 𝑇𝑇 U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |45
II. are control participant equipped with E CV technology, but not receiving warnings; 𝐴𝐴 6.3.3 Performance𝐶𝐶 Measurement (Statistical Modeling) Stage I will allow gathering and measuring performance during CV normal and activation conditions. At the disaggregated level, it will permit measuring individual travel behavior responses of the treated group during normal and activation condition ( and ) without receiving a warning. This 𝐴𝐴 𝑁𝑁 information will be key to establish a baseline when0 comparing0 the same treatment during normal and activation conditions while receiving treatment𝑇𝑇 from safety𝑇𝑇 -focused applications (i.e., warnings). It will also allow assessing the control group responses. At a mesoscopic level, Stage I will allow measuring performance along the Selmon Expressway REL and the intersection of Meridian Avenue and Twiggs Street during the relevant peak periods. The measurement of performance at this level will constitute the baseline normal and activation conditions of the use case.
Stage II will allow measuring treatment response to CV pilot implementation during normal and activation conditions. At the disaggregated level, it will allow measuring individual travel behavior responses of the treated group during normal and activation condition , and the responses of 𝑁𝑁 𝐴𝐴 the control group during the condition during normal1 and activation condition1 . At a mesoscopic level, Stage II will allow measuring performance𝑇𝑇 along 𝑁𝑁the Selmon Expressway𝑇𝑇 REL𝐴𝐴 and the intersection of Meridian Avenue and Twiggs Street during𝐶𝐶 the relevant peak periods𝐶𝐶 and ascertain improvements (if any) upon the baseline performance measures of Stage I.
To the extent that treatment and control participants are correctly identified, then the following can be estimated for each of the performance measure pillars (Mobility, Safety, and Environment):
A. Average treatment effect on the treated (ATET) = ( ) [( ) ( 𝐴𝐴 )𝑁𝑁] B. Average treatment effect (ATE) = 1 1 𝐴𝐴 𝑁𝑁 𝐴𝐴𝑇𝑇 − 𝑁𝑁𝑇𝑇 While (A) allows measuring individual performance𝑇𝑇1 − 𝑇𝑇0 for− those𝐶𝐶 −treated𝐶𝐶 with CV technologies, it is (B) that will provide the unbiased magnitude of the performance improvements.
Furthermore, (B) can only be achieved by setting up the experiment in two stages, where Stage I has the CV technologies installed but “turned-off” on the treatment group ( and ). In Stage II, the CV 𝑁𝑁 𝐴𝐴 technologies will be “turned on” on the treatment group for the duration 0of the Pilot0 implementation ( 𝑇𝑇 𝑇𝑇 𝑁𝑁 and ). This process is irreversible because the ad-hoc turning on and off any warnings on the 1 𝐴𝐴 𝑇𝑇 treated1 group would create disruptive behavioral responses leading to an uncontrollable experimental design.𝑇𝑇
6.4 Use Case 2: Wrong-Way Entries
The objective of this use case is to employ CV technologies to reduce the number or likelihood of wrong-way entries into the Selmon Expressway REL during the period between 6:00 A.M. and 1:30 P.M., when vehicles from the REL transfer to Meridian Avenue to enter downtown. Wrong-way drivers have become a significant problem in the Tampa Bay area and are a major safety concern at the state level as well. Potential CV technologies proposed for this location are V2I, V2V, and V2X.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |46
6.4.1 Background on Baseline Driver Patterns According to the activation conditions described in the ConOps, the same drivers identified in Use Case 1 (morning backups) exiting the Selmon Expressway REL at the intersection of Meridian Avenue and Twiggs Street might experience a situation where a driver might be induced to wrongly access the REL in an outbound direction from Twiggs Street towards Brandon.
While information is available for the driver as per Use Case 1, there is no knowledge about the population of drivers that might engage in wrong-way driving. Additionally, Use Case 2 is not intended to test if the wrong-way driving warning message is working when a wrong-way driving driver is detected on the REL off-ramp and the vehicles approaching the REL off-ramp in this segment receive this warning message to take action. What can be observed, as detailed in Section 4, is the driver behavior for the wrong-way driving vehicle and the vehicles on the adjacent street during normal and activation conditions using video surveillance and vehicle detection at entry.
Also, because the wrong-way entry is a random occurrence, having data from the vehicles used for Use Case 1 might not be enough for analysis, so observation must be deployed to access the driver behavior in response to CV applications. On the other hand, it will be possible to quantify the number of instances a vehicle might engage in a wrong-way entry and then abort when realizing travel is occurring in the wrong direction.
6.4.2 Recommended Experimental Design Use Case 2 presents characteristics that make a before vs. after assessment preferable to a quasi- experiment design. In a best-case scenario, quasi-experimental design can be adopted to measure the response of those drivers identified in Use Case 1 during Use Case 2 activation condition. In practical terms, there might be very few instances (or none) where a driver that is also a participant in Use Case 1 and Use Case 2 might be faced with a wrong entry state of activation.
A phased approach might be considered to collect baseline data first to establish the level of wrong- way entries, to compare with the after the treatment period where the CV technologies will alert the drivers when they are entering the wrong way on the REL.
6.4.3 Performance Measurement (Statistical Modeling) To the extent that treatment and control participants are correctly identified, then the following can be estimated for each of the performance measure pillars (Mobility and Safety):
A. Average treatment effect on the treated (ATET) = ( ) [( ) ( 𝐴𝐴 )𝑁𝑁] B. Average treatment effect (ATE) = 1 1 𝐴𝐴 𝑁𝑁 𝐴𝐴𝑇𝑇 − 𝑁𝑁𝑇𝑇 𝑇𝑇1 − 𝑇𝑇0 − 𝐶𝐶 − 𝐶𝐶 6.5 Use Case 3: Pedestrian Safety
The objective of this use case study is to employ CV technologies to improve pedestrian and driver safety at the Hillsborough County Courthouse on Twiggs Street. As described in the ConOps, this area is characterized by significant competing vehicular and pedestrian traffic during the morning peak hour (7:00 A.M. – 10:00 A.M.). In addition, every Monday and Tuesday, new jurors that are unfamiliar with that area cross this crosswalk, thus adding to the problem.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |47
6.5.1 Recommended Experimental Design During Phase 2 integration testing, it was ascertained that the safety app PED-X would provide inaccurate safety information to pedestrians. PED-X was subsequently modified and integrated with LiDAR sensing to improve its accuracy. Appendix A provides a detailed account of these improvements.
Due to these changes, Use Case 3 will be evaluated using a before vs. after approach.
6.5.2 Performance Measurement To assess the safety benefits, the following performance measures will be measured:
• Number, type, and severity of crashes/crash rate between vehicles and between vehicles and pedestrians • Number, type, and severity of conflicts/near misses from BSM and PSM analysis • Number and frequency of alerts from the PCW app
The number and frequency of the PCW alert issued to arriving vehicles will be measured and evaluated before CV activation and after activation conditions.
6.6 Use Case 4: Transit Signal Priority
The objective of this use case study is to employ CV technologies to reduce transit signal delay, and signal coordination issues inbound along Kennedy Boulevard, outbound along Jackson Street and in both north and southbound directions on Marion Street to improve express bus service traveling through the CBD.
6.6.1 Background on Baseline Bus Conditions
Along the selected routes identified in Section Error! Reference source not found., many of the bus stops are on the approach to an intersection. When there is congestion, buses are unable to reach their stops, causing them to potentially fall behind schedule; thus, causing a mobility concern. CV technology will be used to address the mobility concerns. Buses and traffic signals will communicate, and, if a bus is behind schedule, the traffic signal system will either give the bus priority or flush the queue allowing the bus to reach its stop assuming there are no other higher priorities.
6.6.2 Recommended Experimental Design The participants of this use case will include the bus operators, pedestrians, and drivers in the CV Pilot area. Bus operators cannot be randomly selected due to HART operating parameters. The recommended experimental design is before/after or interrupted time series approach. For Use Case 4, only the transit vehicles/buses that operate on selected routes will have a CV app on board. Therefore, this will be an interrupted time series experimental design and will call for a before and after CV analysis approach.
6.6.3 Performance Measurement (Statistical Modeling)
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |48
The before and after CV application data will allow gathering and measuring the baseline and post-CV implementation performance measures. The results will be analyzed statistically on an overall percentage increase or decrease for each measure of interest and are discussed in detail in Section 8 of this report.
6.7 Use Case 5: Streetcar Conflicts
The objective of this use case study is to employ CV technologies to reduce vehicle conflicts with the TECO Streetcar Line at crossing locations throughout the project area, particularly along Channelside Drive.
6.7.1 Background on Baseline Streetcar Conditions The streetcar passes several intersections where vehicles cross the streetcar tracks. As the pedestrians disembark from the streetcar and the streetcar prepares to start up, a vehicle may turn right in front of the streetcar. The potential of a streetcar and vehicle crash and a pedestrian incident are safety concerns. CV technologies will be used to provide warnings to vehicles and the trolley operators for potential conflicts. The streetcar operators are the same, and drivers are random users of the area.
6.7.2 Recommended Experimental Design The participants of this use case will include the streetcar operators and drivers in the CV Pilot area. Streetcar operators cannot be randomly selected. The recommended experimental design is before/after or interrupted time series approach.
6.7.3 Performance Measurement In the context of a before vs. after evaluation, performance measurement will take the form of a baseline vs. deployment evaluation in terms of percent changes upon baseline conditions.
6.8 Use Case 6: Traffic Progression
The objective of this use case study is to employ CV technologies to improve travel times on Meridian Avenue through downtown Tampa.
6.8.1 Recommended Experimental Design This use case presents the same characteristics of Use Case 1. For this reason, the use case can lead, at a minimum, to a quasi-experimental approach, and, in a best-case scenario, to randomized design experiment (preferred approach). In this case, the pool of potential participants can be drawn from Use Case 1 and augmented to be representative of the MAFB workers commuting from the Brandon area. The split/stratification of treatment and control will have to be determined by this sample augmentation.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |49
In the presence of individual self-selection, the second-best approach will be the quasi-experimental design, with the implementation of PSM methods to match treatment and control groups and minimize bias during performance measurement.
6.8.2 Performance Measurement (Statistical Modeling) To the extent that treatment and control participants are correctly identified, then the following can be estimated for each of the performance measure pillars (Mobility, Safety, and Environment):
A. Average treatment effect on the treated (ATET) = ( ) [( ) ( 𝐴𝐴 )𝑁𝑁] B. Average treatment effect (ATE) = 1 1 𝐴𝐴 𝑁𝑁 𝐴𝐴𝑇𝑇 − 𝑁𝑁𝑇𝑇 While (A) allows measuring individual performance𝑇𝑇1 − 𝑇𝑇0 for− those𝐶𝐶 −treated𝐶𝐶 with CV technologies, it is (B) that will provide the unbiased magnitude of the performance improvements.
As in Use Case 1, Stage II will allow measuring treatment response to CV Pilot implementation during normal and activation conditions. At the disaggregated level, it will allow measuring individual travel behavior responses of the treated group during normal and activation condition , and the 𝑁𝑁 𝐴𝐴 responses of the control group during normal and activation1 condition . At a mesoscopic1 level, Stage II will allow measuring performance along𝑁𝑁 the corridor𝑇𝑇 during the relevant𝐴𝐴 peak𝑇𝑇 periods and ascertain improvements (if any) upon the baseline𝐶𝐶 performance measures𝐶𝐶 of Stage I.
6.9 Summary of Recommended Experimental Design Methods by Use Case
Table 6-2 summarizes the recommended experimental method(s) for each of the six use cases. Recommendations are based on the likelihood of selecting participants and the CV technologies being considered. In the next sections, each use case performance-measurement approach is discussed, along with the rationale behind the choice of the experimental method. Table 6-2 Recommended Experimental Design UC2 UC4 UC1 UC3 UC5 UC6 Experimental Wrong- Transit Morning Pedestrian Streetcar Traffic Design Way Signal Backups Safety Conflicts Progression Entries Priority Interrupted time series Quasi- Experiment Random Design Participant YES Partially NO NO NO YES, from Recruitment from UC1 UC1/UC4
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |50
6.9.1 Sample Size Determination Statistically meaningful difference and effect size represent the magnitude of an effect of interest, such as the performance metrics outlined in Chapter 4. Changes in travel times, travel time reliability, and safety between treated and untreated units represent the magnitude of the effect of interest to be detected by a test with a specified power.
For those use cases where the experimental and quasi-experimental design approach is considered, a power and sample size (PSS) approach will be adopted to identify a minimum required sample size [19, 20]. To identify the minimum required sample size, PSS analysis will be conducted using the commercial statistical software package Stata (Stata PSS).4
It is expected that minimum sample size requirements are a function of 1) selected power of the test; 2) significance level; and, 3) expected difference in the effect size of each adopted performance measure (e.g., travel time savings, safety, emission rates) between treatment and control units.
The power of the test is a measure of the probability of correctly rejecting the null hypothesis when the null hypothesis is false. Power (π) is inversely related to the probability of a type II error (β or fail to reject null when the null is false) and is computed as = 1 . Typical values for power are 0.8 or 0.9, depending on the study objectives. 𝜋𝜋 − 𝛽𝛽 The significance level (α) identifies the type-I error probability of rejecting the null when the null is true. Typical set up is α =0.05
The examples below provide some information on the sample size selection process that will be adopted in the next phase of the Pilot deployment. The purpose is to convey an idea of how sample size requirement depends on the performance measure being considered, underlying baseline characteristics, and expected CV improvement targets.
Example 1. UC1 Mobility Performance Measure Assessment (Table 6-3) Unit of measure: changes in travel time (using segment level travel-time analysis: from the beginning of REL off-ramp to the REL signalized intersection of East Twiggs Street)
Assume that after the initial baseline assessment, the average travel time along the segment is 225 seconds per vehicle with a standard deviation of 100 (seconds per vehicle). After CV implementation, the control group will retain the baseline average travel times, while the treatment group will show an average travel time improvement of about 11% and unchanged standard deviation.
Table 6-3 UC1 Baseline Travel Times and Expected CV Improvements – Example 1 CV Metric Baseline Implementation Change Mean Travel Time (sec/veh) 225 200 -11.1% Standard Deviation (sec/veh) 100 100 0.0%
4 www.stata.com U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |51
The objective is to compare the two means and test: Null hypothesis: H0: |200 225| = 0 Alternative hypothesis: Ha: |200 225| 0 − The formula to compute the required− minimum≠ sample n size for a two-sample mean comparison with α=0.05 and π=0.90 is 2 + = 2 2 �𝑍𝑍𝑎𝑎 𝑍𝑍1−𝛽𝛽� 𝜎𝜎 Where 𝑛𝑛 2 depends on the level of significance; for α=0.05 this𝛥𝛥 is 1.96 depends on power, for π=0.90 this is 1.282 𝑍𝑍𝑎𝑎 σ is the standard deviation 𝑍𝑍1−𝛽𝛽 Δ is the expected effect size (difference in means) Substituting the numbers in the above formula:
2(1.96 + 1.282) 100 = 337 25 2 2 𝑛𝑛 2 ≅ That is, the minimum sample size for each group is 337, which corresponds to the required total sample size for treatment and control to 674. Furthermore, the sample needs to be adjusted to account for the sample drop out (i.e., participants dropping out without replacement). The standard approach is to adjust the sample size using the formula = (1 ) 𝑑𝑑 𝑛𝑛 𝑛𝑛 𝑑𝑑 Where is the inflated sample size; and, is the dropout− 𝑅𝑅 rate.
𝑑𝑑 𝑑𝑑 Assuming𝑛𝑛 a 10% dropout rate, the adjusted𝑅𝑅 sample size is
337 = 374 (1 0.1) 𝑛𝑛𝑑𝑑 ≅ Therefore, the minimum required sample size for− the treatment and control group, after accounting for drop-outs is 748.
The required sample size can be calculated for different scenarios accounting for differences in required power. This would allow matching the minimum required sample size with constraints dictated by other factors, such as budget allocated to participant recruitment and CV installation. The figure below, produced using Stata PSS, shows the simulated minimum sample size based on different power levels.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |52
Estimated total sample size for a two-sample means test
t test assuming σ1 = σ2 = σ H0: μ2 = μ1 versus Ha: μ2 ≠ μ1 700
600
500
400 Total sample size (N) 300
200 .5 .6 .7 .8 .9 Power (1-β)
Parameters: α = .05, δ = -25, μ1 = 225, μ2 = 200, σ = 100
Figure 6-2: Required Sample Size and Power
Example 2: UC1 Mobility Performance Measure Assessment Unit of measure: travel time reliability (using segment level travel-time reliability analysis: from the beginning of REL off-ramp to the REL signalized intersection of East Twiggs Street)
This example considers measuring the effectiveness of CV applications in increasing the travel time reliability of vehicles traveling along Use Case 1’s segment. As in Example 1, CV implementation will improve travel times and at the same time reduce the variability of travel times. Table 6-4 shows a 6.7% reduction in mean travel time and a 15% reduction in the standard deviation.
Table 6-4 UC1 Baseline Travel Times and Expected CV Improvements – Example 2 Metric Baseline CV Change (control) Implementation (treatment) Mean Travel Time (sec/veh) 225 210 -6.7% Standard Deviation (sec/veh) 100 85 -15.0%
Using the same power and confidence level, the minimum required sample size (computed in Stata PSS) is N=1,204 (602 for treatment and 602 for control). After accounting for 10% drop out, the total sample size is N=1,338.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |53
Alternatively, the power of the test can be identified by specifying an upper sample size boundary. This could be the case if, say, budget constraints limit the actual sample size to N=1,000. In this case, the power of the test would be π=0.72.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |54
7 Data Collection Plan
7.1 Data Collection Plan
Throughout the deployment, the performance measurement and evaluation will rely on data coming from two major sources: CV Pilot generated data and third-party generated data (e.g., Bluetooth, weather, log events, MOVES emission database, and other traffic data). CV Pilot data will come from all CV applications transmitting and receiving information, which will be saved by Onboard Units (OBUs) and transmitted to Roadside Units (RSUs) up to ten times per second. RSUs will transmit data stored by OBUs compiled as Data Logs using the “RSU Data Collector” described in the System Design Document (SDD): Data Log Collector. Data logs will contain any information logged locally on each RSU (e.g., TIMs, alerts), as well as data logs from OBUs and PIDs.
The performance evaluation team at CUTR established a dedicated server (the CUTR Server) to collect and process all CV Pilot data, and upload PII-removed data to the ITS Public Data Hub and the Secure Data Commons (SDC). The CUTR Server collects and stores third-party generated data for subsequent data fusion with CV Pilot data. This will allow controlling for confounding factors to conduct system performance evaluation as detailed in Section 8. This chapter discusses the data collection steps, documents the procedures for data cleaning, processing, and archival.
7.1.1 Use Case 1: Morning Backups Performance measurement of Use Case 1 will be based on data generated by ERDW, EEBL, FCW, and I-SIG.
The end of ramp deceleration warning (ERDW) application will provide advance warning to vehicles on the REL driving inbound of a queue that has formed at the intersection of Twiggs Street and Meridian Avenue. The warning will recommend a safe speed, which will allow the vehicle to safely stop before it reaches the end of the queue or stopped traffic. The estimated end of the queue would be transmitted to the vehicle’s OBUs using a TIM from the RSU that would then be interpreted by the OBUs to display the recommended speed to the driver. As the drivers make their way closer to the end of the queue, the recommended speed would lower so that they have ample time to safely stop their vehicle before reaching the end of the queue. The recommended speeds will be for three zones: 20, 30, and 40 MPH and based on the MUTCD and traffic engineering judgment. Data generated by the ERDW will be contained in the data logs transmitted from OBUs to the RSUs and then to THEA master server.
The EEBL will issue an alert to hard braking of an equipped vehicle occurring in the traffic stream ahead. This alert is received from one or more vehicles in the same lane ahead. The objective is to provide the driver with additional time to look for and assess situations developing ahead. The data logs contain a field recording EEBL events stored by OBUs and transmitted to RSUs.
The FCW application will present alerts to the trailing driver to help avoid or mitigate the severity of crashes into the rear end of other vehicles on the road. Forward crash warning responds to a direct and imminent threat ahead of the host vehicle. FCW works lane by lane. When two equipped vehicles interact, FCW provides a driver alert, if the right conditions occur as follows: one vehicle following the U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |55
other; the lead vehicle brakes causing the closing distances to decrease (as calculated) to warrant an alert of a potential collision. The data logs contain a field recording FCW events stored by OBUs, transmitted to RSUs, and then to THEA master server.
I-SIG receives BSMs from vehicles approaching the intersection and ITS traffic detectors (e.g., radar or video) to determine the length of the queue at the intersection. I-SIG uses the queue length to determine if an adjustment to the green phase times is required to move traffic efficiently through the intersection and the corridor. Adjustment of the phase time is limited to the range of the configured minimum and maximum green times. I-SIG is a deployment of the Multi-Modal Intelligent Traffic Signal System (MMITSS) developed by the University of Arizona. MMITSS aims to control traffic at an intersection by using CV data and combining it with available traditional detector data. MMITSS is configured to produce performance measures at the intersection level, which will be stored in the THEA master server and available for retrieval by CUTR. Table 7-1 reports the performance measures along with source and computation/collection process.
Table 7-1 Use Case 1: Morning Backups Data Collection Pillar Metric Source Collection/Computation Point speed Link travel time measurements Computed by CUTR server. from BSMs Travel time distribution analysis of link Travel time reliability Link travel times travel times. MMITSS MMITSS estimates queue lengths based Performance Queue length on a configured CV penetration rate and Measures inside BSMs.5 Data Logs
MMITSS Performance MMITSS measures delay of equipped Delay time Mobility Measures inside vehicles queuing at intersections. Data Logs The Econolite Centracs TMC collects Centracs report available detector calls and phase status % arrival on green based on traffic from intersections. Centracs supports controller data generation of a report for percent arrival on green. Point speed Idle time measurements Computed by CUTR server. from BSMs Crash change, type Crash analysis using the number of of crash, crash FIRES Portal crashes before, during, after CV severity activation for the segment. Conflict change, These events are recorded by OBUs in EEBL, FCW and Safety type of conflict, the their data logs. CUTR server analyzes BSM events from severity of the these events and derives the OBU Data Logs conflict performance measures.
5 Refer to MMITSS Detail Design (pp. 128-130), Version 1.1 dated 06/16/15 for calculation details. U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |56
Pillar Metric Source Collection/Computation Point speed Speed measurement of equipped Approaching speed measurements vehicles passing compared to ERDW on REL from BSMs recommended speeds. Point speed
Idle speed measurements Computed by CUTR master server fusing emissions from BSMs by data from MOVES. vehicle type Point speed
Emissions measurements Computed by CUTR master server fusing Running emissions from BSMs by data from MOVES. vehicle type
7.1.2 Use Case 1: Morning Backups When traffic on the REL is flowing in the inbound direction, beginning in the Brandon area, and exiting at Meridian Avenue and Twiggs Street, drivers can inadvertently enter the REL going the wrong way. Drivers approaching the REL on Twiggs Street from downtown may attempt a left turn onto the REL. Drivers that are coming from East Twiggs Street may attempt a right turn onto the REL. Drivers coming down Meridian Avenue toward the REL may veer slightly to the left and enter the REL. In each case, drivers are entering the REL going in the wrong direction. MAP and SPaT messages are broadcast at the REL/Twiggs/Meridian Intersection to detect these potential wrong-way drivers. Within the SPaT message, the revocable lane bit is set for the reversible lanes. If a vehicle initiates a move into the REL going the wrong way, the OBU Wrong-Way Entry (WWE) application determines the vehicle is entering a revoked lane and issues a warning to the driver warning he/she is on a trajectory predicted to enter the wrong way. If the driver continues up the REL, the OBU WWE application issues another alert. The RSU WWE application determines the vehicle is headed in the wrong direction and begins broadcasting a TIM to approaching equipped vehicles to warn them about the approaching vehicle traveling in the wrong direction. The RSU application sends a wrong-way alert to the TMC. RSU data logs stored in THEA master server, records all received BSMs from all involved vehicles allow calculating vehicle counts, speeds, locations, and travel times. WWE alerts are recorded in the OBU data logs, which are transmitted by RSUs to THEA master server.
Table 7-2 Use Case 2: Wrong Way Entry Data Collection Pillar Metric Source Collection/Computation
Travel time reliability Link travel times Travel time distribution analysis. MMITSS MMITSS measures the delay of Performance Delay time equipped vehicles queuing at
Mobility Measures inside intersections. Data Logs Crash change, type Crash analysis using the number of of crash, crash FIRES Portal crashes before, during, after CV severity activation for the segment. Conflict change, type These events are recorded by OBUs in EEBL, FCW, WWE of conflict, the their data logs. CUTR server analyzes events from OBU
Safety severity of the these events and derives the Data Logs conflict performance measure. Frequency of wrong- WWE events from These events are recorded by OBUs in way violations OBU Data Logs their data logs.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |57
7.1.3 Use Case 3: Pedestrian Safety The performance assessment of this use case will rely on data generated by the Pedestrian Collision Warning (PCW) and the Pedestrian in a Crosswalk Vehicle Warning (PED-X) applications.
PCW receives PSMs to calculate potential crashes with pedestrians entering and in the crosswalk at the courthouse. When PCW detects a potential crash, PCW sends an alert to the driver. Detection depends on two LiDAR sensors detecting pedestrians and the RSU translating that information to PSMs, which is used to warn cars when pedestrians, within the crosswalk, are in the intended path of the car. Equipped vehicles using the PCW app warn the driver of a crash course with a pedestrian in the roadway.
PED-X is an application that receives vehicle BSMs from the RSU via Wi-Fi. As the PID GPS is unpredictable, the feasibility of warning the pedestrian that they may collide with a vehicle will be analyzed. PED-X calculates the path trajectory of the pedestrian and approaching vehicles and logs an event if a potential conflict is identified. These alerts are recorded in the PID data logs, which are transmitted by RSUs to THEA master server. The PED-X app will be evaluated based on data provided by the LiDARs installed at the crosswalk. As mentioned in Section 4, for research purposes, the PED-X app will be evaluated during a controlled experiment.
Table 7-3 Use Case 3: Pedestrian Safety Data Collection Pillar Metric Source Collection/Computation Point speed Link travel time Computed by CUTR server. measurements from BSMs Travel time distribution Travel time reliability Link travel times analysis.
MMITSS estimates queue MMITSS Performance lengths based on a Queue length Measures inside Data configured CV penetration Mobility Logs rate and BSMs. MMITSS Performance MMITSS measures delay of Delay time Measures inside Data equipped vehicles queuing Logs at intersections. Crash analysis using the Crash change, type of number of crashes before, FIRES Portal crash, crash severity during, after CV activation for the segment.
These events are recorded Conflict change, type of by OBUs in their data logs. EEBL, FCW, PCW events conflict, the severity of the CUTR server analyzes
Safety from OBU Data Logs conflict these events and derives the performance measure. Speed measurement of Approaching speed on Point speed equipped vehicles crosswalk measurements from BSMs approaching a crosswalk.
Point speed Computed by CUTR server Idle speed emissions measurements from BSMs ons fusing data from MOVES.
Emissi by vehicle type
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |58
Pillar Metric Source Collection/Computation Point speed Computed by CUTR server Running emissions measurements from BSMs fusing data from MOVES. by vehicle type
7.1.4 Use Case 4: Transit Signal Priority The performance evaluation of this use case will rely on data generated by the I-SIG Transit Signal Priority (TSP), Intersection Movement Assist (IMA), and the Pedestrian Transit Movement Warning (PTMW) applications.
TSP is part of a larger suite of MMITSS applications working with I-SIG. TSP provides signal priority to transit vehicles at intersections and along arterial corridors only if the bus is behind schedule. To request priority, a transit vehicle equipped with an OBU sends a signal request message (SRM) to the RSU. The RSU sends a priority service request to the master server (i.e., housed on THEA master server) at the TMC. The Transit server determines if the bus is behind schedule based the current schedule deviation of the bus as reported by the one-bus-away server. If the bus is behind schedule, the priority service request is granted by the master server (otherwise rejected) and communicated back to the RSU. The RSU determines the priority of all granted SRMs received from all approaching vehicles and then selects the controller phase via NTCIP objects to extend the green, allowing the bus to proceed through the intersection. At the same time, the RSU sends the SSM to the approaching vehicles to inform which has received priority to extend the green and which vehicles have been denied priority. The RSU stores the initial priority request, timestamp, and bus information, including VIN, position, and speed data. If the RSU receives s priority granted message from transit central, the RSU stores the timestamp and the SSM (priority granted message). These alerts are recorded in the RSU data logs, which are transmitted by RSUs to THEA master server.
IMA is an application that warns the driver of a potential collision when two or more vehicles are approaching one another using the relative position, speed, and heading of those vehicles. IMA receives BSMs from approaching vehicles adjacent to the vehicle equipped with IMA. If IMA determines there is a high probability of a collision, the app warns the driver.
Table 7-4 Use Case 4: Transit Signal Priority Data Collection Pillar Metric Source Collection/Computation Bus travel time CUTR server analyzes BSMs and SRMs through the SRMs or/and BSMs which are received by RSUs at intersections deployment from RSU Data Log along the bus route and computes bus travel region time between intersections. Link-level bus travel Travel time distribution analysis. Bus Travel times time reliability stop-level transit Distribution analysis of transit vehicle on-
Mobility service reliability time arrival percentage. CUTR server analyzes SRMs received, and Bus percent corresponding SSMs sent out. SSMs contain SRMs, SSMs from arrival on granted/rejected status of priority request. RSU Data Log schedule Requests are only granted when the bus was behind schedule.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |59
Pillar Metric Source Collection/Computation MMITSS MMITSS monitors the bus BSMs and tracks Bus percent performance the bus as it travels through the intersection. arrival on measure from SRM, The bus arrived on green if it didn’t stop green bus BSM, signal traveling through the intersection. phase status Number of times priority is SRMs, SSMs from The transit server’s response (grant/reject) is requested and RSU Data Log reflected in the SSM returned to the bus. granted Number of times priority is SRMs, SSMs from The transit server’s response (grant/reject) is requested and RSU Data Log reflected in the SSM returned to the bus. denied
Point speed Idle speed Computed by CUTR server fusing data from measurements from emissions MOVES. BSMs Point speed Running Computed by CUTR server fusing data from
Emissions measurements from emissions MOVES. BSMs
7.1.5 Use Case 5: Streetcar Conflicts This use case deploys two applications: I-SIG and Vehicle Turning Right in Front of Transit Vehicle Warning (VTRFTV).
The VTRFTV app warns the streetcar operator of a vehicle turning right at the intersection the streetcar is approaching, using the BSMs that are being sent and received if the app determines the vehicles are on a potential collision trajectory. Once a blinker of the vehicle that is approaching the intersection is engaged while passing the streetcar as well as the trajectory and speed determined by the OBU match that of the potential collision, the streetcar OBU will give the streetcar driver a warning. These alerts are recorded in the OBU data logs, which are transmitted by RSUs to THEA master server.
The RSU will receive streetcar and other vehicles BSMs, determine if a vehicle is turning right in front of starting up or moving streetcar, and send a vehicle turning right warning. The RSU will store the streetcar BSMs, the other vehicle BSMs, and any warning the RSU sends. The records will represent the before, during, and after data of the warning event.
Table 7-5 Use Case 5: Streetcar Conflicts Data Collection Pillar Metric Source Collection/Computation Crash change, Crash analysis using the number of crashes type of crash, FIRES Portal before, during, after CV activation for the crash severity segment. Conflict change, VTRFTV These events are recorded by OBUs in their Safety type of conflict, events from data logs. CUTR server analyzes these events the severity of the OBU Data and derives the performance measure. conflict Logs
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |60
7.1.6 Use Case 6: Traffic Progression The Enhanced Signal Coordination and Traffic Progression rely on I-SIG, IMA, FCW, and EEBL. The apps work, as mentioned earlier, and data logs from the RSUs and OBUs will be collected to analyze the performance of the corridor. Table 7-6 outlines the data collection elements for this use case.
Table 7-6 Use Case 6: Traffic Progression Data Collection Pillar Metric Source Collection/Computation Point speed Link travel time Computed by CUTR server. measurements from BSMs Travel time distribution analysis, calculations of Travel time reliability Link travel times buffer index, planning time index, 95th and 90th percentile travel times. MMITSS estimates queue MMITSS Performance
lengths based on a Queue length Measures inside Data configured CV penetration Logs rate and BSMs.
Mobility MMITSS Performance MMITSS measures delay of Delay time Measures inside Data equipped vehicles queuing Logs at intersections. The Econolite Centracs TMC collects available detector calls and phase Percent vehicle arrival on Centracs report based on status from intersections. green traffic controller data Centracs supports generation of a report for percent arrival on green. Crash analysis using the Crash change, type of number of crashes before, FIRES Portal crash, crash severity during, after CV activation for the segment. These events are recorded Conflict change, type of by OBUs in their data logs. EEBL, FCW, IMA events conflict, the severity of the CUTR server analyzes from OBU Data Logs Safety conflict these events and derives the performance measure. Speed measurement of Point speed equipped vehicles passing Approaching speed measurements from BSMs through a virtual detection zone (geo-fence).
Point speed Computed by CUTR server Idle speed emissions measurements from BSMs fusing data from MOVES. by vehicle type Point speed Computed by CUTR server
Emissions Running emissions measurements from BSMs fusing data from MOVES. by vehicle type
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |61
7.1.7 Participant Action Feedback Protocols The primary focus of the CV Pilot is to measure improvement in safety and mobility. As such, the performance measures will focus on safety and mobility measures. To assist independent evaluators in their assessment, knowing the protocols followed by people who interact with the system can be used to determine whether the use cases/application(s) improved performance. The following users have been identified:
• Passenger vehicle participants • Bus operators • Streetcar operators • TMC operators
7.1.8 Passenger Vehicle Participants A passenger vehicle participant is someone who was recruited, went through the registration and training process, and was approved to be part of the CV Pilot. The person will allow an OBU to be installed in their light passenger vehicle. These participants’ vehicles will utilize the OBU applications when they are within the study area in which the applications operate. Note that V2V applications will work anywhere two equipped vehicles meet, and the proper conditions are met.
Passenger vehicle participants who have OBUs installed in their vehicles may receive in-vehicle warnings. These participants will be trained on how the warnings are presented and potentially how to respond to these warnings. When the participants bring their vehicles to have the equipment installed, they will be asked to fill out an anonymous survey of their previous experience with CV application and general travel behavior. Passenger vehicle participants will also answer up to three web-based surveys over the deployment phase to gauge their perception of any warnings they received, how they reacted to them, and whether the warnings had any impact on their safety and/or mobility.
7.1.9 Bus Operators Bus participants are the bus drivers on the Hillsborough Area Regional Transit (HART) buses selected for use in the CV Pilot. These bus operators will be selected by HART and trained on how to interact with the OBUs installed on the buses. The bus applications will be utilized while the bus is traversing the selected downtown streets where RSUs are installed and operating the transit application. The current plan is to have 10 buses. Periodically, the operators will be anonymously surveyed to determine their perception of any messages they received, how they reacted to them, and whether the message had any impact on their safety and/or mobility.
7.1.10 Streetcar Operators Streetcar participants are the streetcar operators who operate the streetcars selected for use in the CV Pilot. HART will provide training to the streetcar operators on how to interface with the OBUs installed on the streetcar. The streetcar applications will be utilized at two locations along the Channelside route. The current plan is to outfit 10 streetcars. Streetcar operators may be periodically asked to fill out an anonymous survey on their experience, including their perception of any warnings they received, how they reacted to them, and whether the warning had any impact on their safety and/or mobility. U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |62
7.2 Document Procedures for Data Quality Verification, Data Cleaning, PII Removal, and Fusion of CV Data with Data from Other Sources
This section outlines the procedures for quality checking, cleaning, removal of Personal Identifiable Information (PII), and fusion of CV data with data from other sources. These procedures are labor and computationally intensive, but their completion will yield data that are appropriately aggregated, logically structured, and accurately documented to enable independent evaluation once uploaded to SDC and the ITS Public Data Hub. The following framework proposes a mechanism for data handling, cleaning, structuring, fusion, and distribution. The system is centered on a data handling environment located at CUTR as outlined below.
7.2.1 CUTR Server The computer server physically located in the Center for Urban Transportation Research (the CUTR Server) has been deployed and configured to receive and archive CV Pilot data stored at the master server located in THEA. As detailed in the Data Management Plan (DMP) and System Design Document (SDD), the THEA master server is the home for all data collected for the Tampa CV Pilot. The master server software processes and archives RSU-transmitted data in the form of data logs into the NextConnect server. Through a secure VPN connection, CUTR server accesses unfiltered data logs in NextConnect for further processing and performance measurement. The CUTR Server also stores non-CV data from local agencies and third-party data providers. Figure 7-1 illustrates the data flow. Even though one server is capable of handling all the processing aspects of the Pilot, a second server has been dedicated as a data and processing backup in case of failure.
For the Tampa CV Pilot, the PMESP team set up two dedicated in-house servers:
1. Server 1 is a Dell PowerEdge R540 with four HDD drives with a capacity of 10TB each, set up in Raid 5 configuration for a total of 30TB available storage. The server operating system software is stored on high capacity SSD drives set up in Raid 1 configuration (i.e., mirroring). The primary role of this server is to parse CV pilot data, store parsed data into a SQL database for PMESP analysis, and process and upload data to the SDC and ITS Public Data Hub. The server has dual redundant power supplies, centralized power backup, and dedicated power backup. Firewall protection is as described in Figure 11-3.
2. Server 2 is a Dell PowerEdge R740 with same HDD setup as Server 1, with the main difference of using high-speed HDD drives and higher capacity SSD drives. The main role of this server is to run analytics using a variety of open source (e.g., R) and commercial (e.g., Stata) statistical software for deep learning and econometric modeling. The secondary role is to take over functions of Server 1 in case of failure. This server is also used to run data processing for the Performance Dashboard.
CUTR also has access to the College of Engineering Computer Science cluster if the need to run GPU-based approaches arises.
The combined CUTR server carries out three primary functions: 1) PII removal and upload to SDC and ITS Public Data Hub; 2) Performance measurement calculation and analysis; and, 3) Performance reporting to relevant stakeholders through the Performance Measurement Evaluation U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |63
Dashboard (PMED). To conduct the overall system impact evaluation, the CUTR server will also perform data fusion from external sources (i.e., Bluetooth reader, weather, event logs, and HART data).
Figure 7-1 THEA CV Pilot Planned Data Flow – CUTR Server Source: CUTR
The server is capable of processing multiple data streams to generate data feeds for performance assessment and dashboard reporting. Data logs stored at THEA master server as flat files flow to the CUTR server. The data screening component performs an initial quality check for data consistency (e.g., file integrity) and to ensure delivery of data geofenced within the study area.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |64
Next, the data logs undergo PII removal. After PII removal, data logs are processed and packaged for delivery to the ITS Public Data Hub for final consumption by the research community. Non-aggregated data logs, containing a new time-fixed unique identifier, flow to the SDC for further processing and analysis by the Independent Evaluator (IE). The sections below describe these data processing steps and mechanisms for archiving the data. The CUTR server also stores non-CV data from other sources, such as local weather information providers, data from the TMCs Centracs system, data from HART OneBusAway, and event data logging information on local traffic events. The collection of these data will serve to account for all observable confounding factors as described in Section 5 of this document.
7.2.2 Data Quality Checking and Cleaning Data logs from a given RSU contain any information logged locally on the RSU (e.g., sent BSMs and TIMs), as well as data logs received from OBUs and PIDs. This information is contained in a JSON object called the “dataCollectorPackage” as described in the Interface Control Document. Using this information, performance monitoring, as well as post-test performance evaluation, can be carried out. It is assumed that the CV devices (i.e., RSUs and OBUs) and other sensors are certified for data standards conformance. As part of the data quality checks, the data are checked for format and structure.
CUTR server synchronizes with THEA master server on the hour. Every night before processing data for analysis and upload to SDC and ITS Data Hub, CUTR server and THEA server synchronize the files to ensure all data in THEA server are also captured by CUTR server. Next, SDC and ITS Data Hub receive a data counter file on each upload to compare the number of files processed and uploaded from CUTR versus the number of files received. This method is automated and provides a level of assurance if for some reason data is not transferred between servers during the normal operation.
The rigor of the data checking for format and structure is dependent on the requirements of the end- users, which are the ITS Public Data Hub and SDC subscribers. Table 7-7 provides some of the basic requirements. Upon completion of the basic quality checks, PII will be removed. Note that the CUTR server does not remove redundant data (e.g., duplicate BSMs) or outliers for misbehavior detection when uploading data to the SDC and ITS Public Data Hub, which are useful for research and system performance evaluation purposes.
Table 7-7 Requirements of the Subscribers to the Data Coming from CUTR Server Users Requirements The data files are organized into datasets, which are provided under the data environment. Metadata documents must accompany all data Secure Data Commons environments. The datasets can be uploaded in batch mode. The data (SDC) files are a collection of data that can be text, zip, binary, or other file types.
ITS Public Data Hub Same as the SDC requirements for formatting of the data.
Independent Evaluators Same as SDC requirements for formatting of the data.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |65
7.2.3 PII Removal The CUTR server performs PII removal as part of a nightly batch job before uploading data logs to the SDC and ITS Data Hub. Of concern is any information contained in BSM data from the OBUs, the Roadside Unit (RSU)/sensor data, and any other driving data that can be used to identify a vehicle. Data logs are checked to remove any additional information that could support the uncovering of PII, including data elements if deemed sensitive on a case by case basis. To ensure PII removal, the data logs are subject to cordon truncation to limit the data analysis to the geographic confines of the Tampa CV Pilot Study Area. This is achieved by establishing a geofence around the CV Pilot Study Area and by eliminating all records that place the vehicles outside the study area polygon. All remaining records are those collected within the CV Pilot Study Area.
7.2.3.1 PII Removal and Data Cleansing for Upload to the SDC To conform to IE safety evaluation needs, the SDC data logs will contain a new randomly generated ID. This ID will remain constant over the study time frame to allow the IE conducting safety evaluation performance assessment. This field is removed from the data available in the ITS Public Data Hub.
7.2.4 Fusion of CV Data with Other Sources Traffic performance measures generated from a single data source may not accurately represent the actual traffic situation due to sampling and penetration rate. For example, regardless of the penetration rate, individual travel time estimated from CV generated data may be inaccurate. To address the issue, data fusion techniques powered by multiple data sources will be considered to compensate for the low CV penetration rate. The CUTR server will carry data fusion and aggregation of non-CV data along with CV data. The performance measurement calculation module will fuse data from the following two major data sources to generate a database for further statistical analysis:
• Agency Data o TMC/Centracs o TMC Event Data Logs o HART OneBusAway • Third-Party Data o Bluetooth Readers Data o EPA MOVES Database o Weather API Services
7.2.4.1 Agency Data The Traffic Management Center (TMC) at the City of Tampa area provides two major sources of traffic data, including intersection-based traffic measures from the Econolite Centracs system and TMC event data logs. The existing Econolite Centracs intersection control system collects traffic counts, available traffic detector calls, phase status, and percent arrival on green. Percent arrival on green is the most important measures for traffic signal optimization to ensure the maximum vehicles in a platoon passing through an intersection. Contingent to server firewall security protocols, CUTR server will access the information from the Centracs system.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |66
TMC event data logs contain incidents and roadway maintenance and construction information, including duration and location of a work zone, roadway, or lane closure due to a special event, severe weather information (e.g., hurricane and thunderstorms) and traveler information broadcast.
Hillsborough Area Regional Transit Authority (HART) has been working with OneBusAway to publish Tampa local transit information (e.g., bus schedule and trip plan) through OneBusAway’s platform and applications. In addition to the OneBusAway standalone website and smartphone apps, the platform provides APIs to access bus information in a real-time fashion. All the transit vehicles operated by HART can be geo-located using OneBusAway API. The CUTR server can access the information using the confidential information provided by OneBusAway.
7.2.4.2 Third-Party Data Third-party data sources primarily include Bluetooth reader data, the United States Environmental Protection Agency (EPA) MOVES data, and weather data.
A Bluetooth reader vendor has been contracted to provide high-resolution Bluetooth Median Access Control (MAC) data in the CV Pilot study area. Individual travel time is the primary data obtained from Bluetooth MAC readers. Individual detected Bluetooth travel time on pre-defined roadway segments will be fed into the CUTR server, and then, travel time will be aggregated to perform data fusion for performance measurement purposes.
Weather information is obtained through the APIs provided by the selected weather service provider. A Stratus Developer data plan is used to call the weather service API 500 times per day to retrieve high- resolution Tampa-located weather information.
Unlike abovementioned real-time and dynamic data, a static data, which is vehicle-caused emission rates generated by EPA MOVES, is also archived in the CUTR server. Figure 7-2 shows an example of the emission rate per distance.
Figure 7-2 Example of Emission Rates from MOVES
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |67
7.2.4.3 Data Fusion Data fusion is defined as a process of utilizing multiple data sources to generate more consistent, accurate information. A neural network is one of the popular techniques to fuse multiple data sources to generate more accurate traffic information representing actual traffic conditions. Figure 7-3 shows the typical topology of a single hidden layer neural network. The neural network is used to fuse travel times from various data sources. The inputs of the neural network include CV-based, Bluetooth- based, transit vehicle information, incident information, and weather information; while the output is a single value of travel time used for representing actual traffic conditions and transportation efficiency.
Figure 7-3 Example of Building up a Neural Network for Travel Time Fusion
7.3 Document Procedures for Data Archival
The procedures include the following steps: 1. Metadata generation. Since all the raw CV data collected in the CUTR server are stored in flat files and then parsed and converted into a SQL Server database, metadata are used to describe the data stored in flat files. The elements in the metadata include provider information, the purpose of data, date and time, keyword, data format, data type, file size, file location, standard use, and the relationship to the parsed data in the SQL Server database. Appendix B and Appendix C provide metadata and data dictionary information.
2. Data archival software sharing. Transit vehicle information from OneBusAway, traffic data from Bluetooth readers, weather data from a weather service are retrieved through APIs. Custom software applications are developed to access those resources and archive those data sources as flat files in the CUTR server and organize the flat files in local folders.
3. Methodology and strategy of data aggregation. The raw CV data are archived at a high frequency (up to 10 times per second). To efficiently report mobility performance measures, CV data are aggregated at the link level and lower frequency (either five- or ten-second intervals). Different methodology and strategy may produce different measures. Documenting corresponding methodology and strategy assists traffic performance evaluators in tracking the accuracy of aggregated measures.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |68
4. Data format selection. One or more data formats might be required to be specified to be the information carrier of aggregated data. Excel files, comma-separated values (CSV), text, XML, JSON, binary, etc. are the potential data formats to meet the requirements of independent traffic performance evaluators. For example, the SDC expressed a preference in terms of having CV Pilot Data in JSON, while the Independent Evaluator conducting the mobility evaluation expressed the need to receive non-CV Pilot data in CSV format.
5. Data upload requirement satisfaction. CV data are uploaded to both the SDC and the ITS Public Data Hub. The two platforms are developed with specific system structures, and they support different data formats. The CUTR server will transmit CV Pilot data to the ITS Public Data Hub and SDC based on several criteria described in Section 7.2.3. The upload to the ITS Public Data Hub and SDC will occur at regular night intervals following an automated upload protocol defined in agreement with the ITS Public Data Hub and SDC developers.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |69
8 System Impact Evaluation Plan
This section discusses the procedures and methods for estimating each identified performance measure of Section 4. It details the empirical measurement of each performance measure and the methods to ascertain system improvements that can be attributed to the CV Pilot Deployment. The reporting of all the measures will be done via monthly System Performance Reports and the Performance Measurement and Evaluation Dashboard.
8.1 Use Case 1: Morning Backups
The proposed experimental design for this use case will allow obtaining and measuring performance at the outset of the CV Pilot deployment, using a treatment/control approach. Performance assessment will be conducted on mobility, safety, and environmental metrics as detailed in Section 4. Below is the proposed approach to performance measurement for each of the identified measures.
8.1.1 Mobility Mobility will be measured in terms of changes in average travel time savings and travel time reliability (See Lyman and Bertini [21]) along the travel segments of the Selmon Expressway REL leading to the intersection of Meridian Avenue and Twiggs Street. In addition, the queue length and delay on the Selmon Expressway REL leading to the intersection of Meridian Avenue and Twiggs Street will be analyzed using Wavetronics software to report actual maximum queue length in feet and the average delay in seconds/minutes. Additionally, for assessing mobility, the percent of vehicles arriving on green will be analyzed by obtaining the number of vehicles that progress through the intersection on green.
For reporting purposes, measurements will be automated to produce daily, weekly, and monthly performance reports that include mean travel time, the 95th percentile travel time, and travel time reliability indexes. The reporting frequency will be at 15-minutes over the morning peak hours (7:00 to 9:00 A.M.). To gauge the impact of CV technology deployment to users of the system, changes in the above-mentioned performance measures during normal conditions (no backups) will be compared to changes for the same measures during activation conditions (backups).
At the mesoscopic level, mobility will be measured by comparing mean travel times between treated and control groups, controlling for concurring changes in the observed confounding factors. When comparing changes between normal and activation conditions for all participants, the analysis will be carried out in the context of panel data using the general specification of the equation. Changes in travel time reliability will be assessed by comparing the 90th or 95th percentile travel times during normal and activation conditions. Travel time distributions along the relevant travel segments will be constructed, along with mean and standard deviations. Distributional differences between normal and activation conditions will be assessed by comparing differences in the distributions between treatment and control. This will be done numerically via parametric and nonparametric measures and graphically for recurrent performance measurement and independent evaluation.
For this use case, the performance measures for the analysis segment are hypothesized to improve (all are expected to decrease except travel time reliability and percent arrival on green, since the
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |70
progression is expected to get better and, therefore, these measures to increase) for the CV applications case, when compared to the baseline scenario. The targeted improvement rates are as discussed in Section 4.
8.1.2 Safety As a system-wide measure, safety will be measured by the comparison of the number, type, and severity of crashes in the segment. Specific crashes (rear-end) that occur due to congestion will be counted for a historic five-year period baseline. This will be compared to the number of crashes occurring during the CV Pilot period. A crash rate per vehicle mile or vehicle volume will also be considered. However, it is expected that this number might not be significant, since it may not fluctuate significantly for a statistical difference to be established. To mitigate this, surrogate measures of safety, such as conflicts or near misses will be counted using high deceleration rates (<-0.5g) and the number of alerts of the FCW and EEBL apps. Also, the type of conflict and/or severity will be categorized to provide a more detailed level of analysis.
Another metric is the ERDW warning provided to the drivers. This, in conjunction with the oncoming speed of vehicles towards the queue, will determine the safety parameters that are enhanced during CV activation conditions. It is expected that the drivers will react to the ERDW and decelerate at a slower rate than without the warnings. The queue length will also be considered as a surrogate measure even though it cannot be eliminated.
With the above information and adequate sample size, it is possible to provide probabilities of a vehicle being involved in a crash due to the existing conditions and compare those with the CV activation conditions.
Conflict-based Safety Performance Functions (SPFs) or a volatility measure will be utilized to predict conflicts and then predict expected crashes in a nested Poisson-gamma model. This modeling technique developed in [22] and [23] has been shown to provide a consistent result, especially when mixed types of conflicts are combined.
For reporting purposes, the alerts from the CV technologies deployed will be automatically compiled into reports for daily, weekly, and monthly performance reporting.
8.1.3 Environment Vehicle-caused air pollution will be estimated using vehicle speed, acceleration rate, and distance traveled along the segments of THEA REL Expressway and Twiggs Street. The proposed experiments outlined in Phases I and II help compare the pollution before and after the CV technology deployment. Vehicle speed, acceleration rate, and distance traveled come from the BSMs. Default emission parameters come with the EPA’s latest version of MOVES. The MOVES produce emission rates, including:
• Atmospheric Carbon Dioxide (CO2) • Carbon Monoxide (CO) • Nitrogen Dioxide (NO2) • Nitrogen Oxide (NO) • Nitrous Oxide (N2O) • Particulate Matter (PM10)
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |71
• Particulate Matter (PM2.5) • Sulfur Dioxide (SO2) • Volatile Organic Compounds (VOC)
The approach to obtain emission rates from MOVES follows the methodology employed by FHWA in assessing the potential environmental benefits of automated vehicles [24]. To obtain detailed emission rates, MOVES will be employed at the project level, customizing the model to reflect the vehicle stock of study participants, taking into account vehicle type, age, and fuel. Additional input parameters will be obtained by using the default MOVES parameters.
Figure 8-1 Moves Project Data Manager Source: MOVES Model
To estimate the impact of CV deployment on vehicle-caused emissions, all the emission measures are estimated at Phase I in the proposed experiment design; while all the emission measure are re- estimated at Phase II. The emission rates are correspondingly compared, and statistical hypothesis tests are used to determine whether the changes are statistically significant.
8.2 Use Case 2: Wrong-Way Entries
Performance assessment will be conducted on the safety and environmental metrics as detailed in Section 4. Below is the proposed approach to performance measurement for each of the identified measures.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |72
8.2.1 Mobility There will be no mobility measurement for this use case.
8.2.2 Safety As a system-wide measure, safety will be measured by the change in crashes and/or the crash rate at the intersection and the REL segment. Specific crashes (head-on, sideswipe, angle) that occur due to a wrong-way vehicle will be counted for a historic five-year period baseline. This will be compared to the number of crashes occurring during the CV Pilot period. A crash rate per vehicle mile or vehicle volume can also provide a good metric. However, it is expected that this number might not provide much information, since it may not fluctuate significantly for a statistical difference to be established. Based on baseline data, this behavior, even though it occurs frequently, it does not usually result in crashes. However, it is dangerous behavior and needs to be addressed.
To mitigate this, surrogate measures of safety, such as conflicts or near misses, will be counted using high deceleration rates (<-0.5g) and/or alerts of FCW. Also, the type of conflict or severity will be categorized to provide a more detailed level of analysis.
With the above information and adequate sample size, it is possible to provide probabilities of a vehicle being involved in a crash due to the existing conditions and compare those with the CV activation conditions.
The number of alerts of the WWE app and the reaction of the drivers will be evaluated to determine if the app resulted in a change of the drivers’ behavior.
For reporting purposes, the alerts from the CV technologies deployed will be automatically compiled into reports for daily, weekly, and monthly performance reporting.
8.2.3 Environment There will be no emission impact assessment for this use case.
8.3 Use Case 3: Pedestrian Safety 8.3.1 Mobility At the individual level, mobility will be measured in terms of changes in average travel time savings and travel time reliability along the segment of East Twiggs Street near the courthouse crosswalk.
Frequency of measurement will be five-minute and hourly intervals so that morning and evening rush hours can be captured in the analysis. The reporting will be done at daily, weekly, and monthly levels. To gauge the impact of CV technology deployment to users of the system, average changes in the above-mentioned performance measures during normal conditions (no backups) will be compared to average changes for the same measures during activation conditions (backups).
At the mesoscopic level, mobility will be measured by comparing mean travel times between treated and control groups, controlling for concurrent changes in the observed confounding factors. When
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |73
comparing changes between normal and activation conditions for all participants, the analysis will be carried out in the context of panel data using the general specification of equation (1) detailed in Section 6.
Changes in travel time reliability will be assessed by comparing the 90th or 95th percentile travel times during normal and activation conditions. Travel time distributions along the Use Case 3 travel segment will be constructed, along with mean and standard deviations. Distributional differences between normal and activation conditions will be estimated.
For reporting purposes, measurements will be automated to produce daily, weekly, and monthly performance reports that include mean travel time, the 95th percentile travel time, and the percent of daily, weekly, and monthly readings (at a five-minute level) that were congested, with a threshold determined by a multiple of the free-flow travel time.
The first step will consist of comparing differences in the distributions between treatment and control. This will be done numerically via parametric and nonparametric (entropy-based) measures and graphically for recurrent performance measurement and independent evaluation.
For this use case, the maximum queue lengths for the analysis segment are expected to be higher (worse) in the after-CV implementation case compared to the baseline scenario. This is because drivers and pedestrians will get warnings, and the drivers are projected to react to the warnings by stopping more often for pedestrians than in the baseline scenario. Mobility is expected to be sacrificed for safer crosswalk conditions, and a compromise between mobility and safety will result.
8.3.2 Safety As in previous use cases, the number, type, and severity of crashes for the segment starting at the intersection of Twiggs Street and Meridian Avenue and ending at the intersection of Twiggs Street and Jefferson Avenue will be compared to baseline data before CV technology activation. Specific crashes (rear-end for vehicles and pedestrian-vehicle) that occur due to crossing pedestrians will be counted for a historic five-year period baseline. However, it is expected that this number might not provide much information, since it may not fluctuate significantly for a statistical difference to be established.
The data collected for this use case will include all pedestrians since LiDAR deployed at this site will be able to detect all pedestrians who cross the crosswalk. As in previous use cases, the crash rate is not expected to be significantly impacted, but the number, type, and severity of conflicts are hypothesized to be different. It is also expected that a slight increase in delay or potentially crashes might occur if more vehicle drivers receive alerts about crossing pedestrians and react to them.
For reporting purposes, the alerts from the PCW app will be automatically compiled into reports for daily, weekly, and monthly performance reporting.
8.3.3 Environment The assessment will follow the approach detailed in Section 6.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |74
8.4 Use Case 4: Transit Signal Priority 8.4.1 Mobility As detailed in Section 4, mobility will be measured in terms of:
• Bus travel time (average using segment level analysis for transit/bus mode: along the travel segments of Marion Street, starting from the Kennedy Boulevard and Marion Street intersection to the Marion Transit Center). • Bus travel time reliability. BSM data provides high-resolution point trajectory data. Bus travel time given any pair of origin and destination can be calculated using BSM data. Travel time of buses running along Marion Street, starting from the Kennedy Boulevard and Marion Street intersection to the Marion Transit Center would be calculated, and the above-mentioned travel time reliability measures will be then derived. • Percentage (%) arrival on schedule (at bus stops along the travel segments of Marion Street, starting from the Kennedy Boulevard and Marion Street intersection to the Marion Transit Center). • Percentage (%) arrival on green (at signalized intersections along the travel segments of Marion Street, starting from the Kennedy Boulevard and Marion Street intersection to the Marion Transit Center). • Signal Priority: (at signalized intersections along the travel segments of Marion Street, starting from the Kennedy Boulevard and Marion Street intersection to the Marion Transit Center). o Number of times priority is requested and granted o Number of times priority is requested and denied o Number of times priority is requested, granted, and then denied due to a higher priority
For this use case, mobility will be measured in terms of changes in average bus travel time savings and bus travel time reliability along the travel segments of Marion Street, starting from the Kennedy Boulevard and Marion Street intersection to the Marion Transit Center. Also, for assessing mobility, the percent of buses arriving on schedule, arriving on green will be analyzed through obtaining the number of buses arriving at their bus stop on schedule, that progress through the signalized intersections on this segment on green.
In addition, signal priority data, such as the number of times priority is requested and granted, the number of times priority is requested and denied, as well as the number of times priority is requested, granted, and then denied to due to a higher priority being granted such as an EMS vehicle, will be collected and analyzed.
Frequency of measurement will be 15-minute and hourly intervals so that morning and evening rush hours can be captured. The reporting will be done at daily, weekly, and monthly levels.
For this use case, the performance measures for the analysis segment are expected to improve (all are expected to decrease except bus route travel-time reliability and arrival on schedule and percent arrival on green, since the progression is expected to get better and, therefore, these measures to increase) for the CV applications case when compared to the baseline scenario.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |75
8.4.2 Safety As mentioned in Section 4, safety will not be measured for this use case.
8.4.3 Environment The assessment will follow the approach detailed in Section 4.
8.5 Use Case 5: Streetcar Conflicts 8.5.1 Mobility As detailed in Section 4, mobility will not be measured for this use case.
8.5.2 Safety As detailed in Section 4, to determine the safety benefits for Use Case 5, the research team will analyze the following performance measures:
• Number, type, and severity of crashes/crash rate for streetcar route • Number, type, and severity of conflicts/near misses • Number and frequency of alerts from VTRFTV app
Safety will be evaluated in terms of comparison of the number, type, and severity of crashes and conflicts with the streetcars equipped with CV technologies. Logs from both vehicle and streetcar OBUs will be used to assess the potential conflicts, as well as feedback obtained from the streetcar operators.
8.5.3 Environment As detailed in Section 4, mobility will not be measured for this use case.
8.6 Use Case 6: Traffic Progression 8.6.1 Mobility Mobility will be measured in terms of changes in average travel time savings and travel time. Also, the queue length and delay on the above-mentioned segments will be analyzed using Wavetronics software to report actual maximum queue length in feet and the average delay in seconds/minutes. Additionally, for assessing mobility, the percent of vehicles arriving on green will be analyzed.
Frequency of measurement will be 15-minute and hourly intervals so that morning and evening rush hours can be captured in the analysis. The reporting will be done at daily, weekly, and monthly levels. To gauge the impact of CV technology deployment to users of the system, average changes in the above-mentioned performance measures during normal conditions (no backups) will be compared to average changes for the same measures during activation conditions (backups).
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |76
At a mesoscopic level, mobility will be measured by comparing mean travel times between treated and control groups, controlling for concurring changes in the observed confounding factors. When comparing changes between normal and activation conditions for all participants, the analysis will be carried out in the context of panel data using the general specification of equation (1) detailed in Section 6.
Changes in travel time reliability will be assessed by comparing the 90th or 95th percentile travel times during normal and activation conditions. Travel time distributions along the Use Case 6 travel segment will be constructed, along with mean and standard deviations. Distributional differences between normal and activation conditions will be estimated.
For reporting purposes, measurements will be automated to produce daily, weekly, and monthly performance reports that include mean travel time, the 95th percentile travel time, and the percent of daily, weekly, and monthly readings (at a five-minute level) that were congested, with a threshold determined by a multiple of the free-flow travel time.
The first step will consist of comparing differences in the distributions between treatment and control. This will be done numerically via parametric and nonparametric (entropy-based) measures and graphically for recurrent performance measurement and independent evaluation.
For this use case, the performance measures for the analysis segment are expected to improve (all are expected to decrease except travel time reliability and percent arrival on green, since the progression is expected to get better and therefore these measures to increase) for the CV applications case when compared to the baseline scenario. The targeted improvement rates are as discussed in Section 4.
8.6.2 Safety For safety, comparison of the number, types, and severity of crashes along Meridian Avenue, Florida Avenue, and part of Nebraska will be analyzed. Also, the comparison of the number, type, and severity of conflicts and near misses will be analyzed for the treatment and control groups. The alerts provided by the apps deployed along this segment (i.e., IMA and all V2V apps) will be analyzed. With improved mobility and progression, it is hypothesized that fewer crashes will occur because of harmonization of the platoons of vehicles traveling on the three segments.
8.6.3 Environment The assessment will follow the approach detailed in Section 4.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |77
9 Performance Reporting
This section details the system performance reporting framework to inform the community, key stakeholders, and the independent evaluators. It discusses the mechanisms to report the performance measures identified in Section 4, their tracking and benchmarking against the anticipated targets, and reporting frequency. In developing a performance reporting mechanism that suits the needs of the community and key stakeholders, this section draws from and follows recommendations from a series of FHWA reports on performance reporting practices [25, 26].
9.1 Reporting to the Community and Stakeholders
To effectively communicate to the public how well the CV Pilot will be performing against the identified performance measures, the information will have to be provided to the community. In the process, it is relevant to understand that information must be presented and conveyed in a format to which the public can readily understand and relate. Information should help answer key questions, such as, has there been an improvement in the travel conditions due to CV deployment? If so, is this an improvement that matters?
9.1.1 Performance Measurement Evaluation Dashboard (PMED) This plan proposes to develop a Performance Measurement Evaluation Dashboard (PMED) that uses an interactive infographic approach to track and report performance measures. The dashboard will be structured so that users will be able to assess how each one of the six use case studies is performing in terms of the performance measures identified in Section 4 and impact measures of Section 8. The PMED will report metrics relevant to each of the six use cases, with customizable reporting frequency. Each use case will have clickable tabs labeled following the performance pillars (Mobility, Safety, Environment, and Efficiency). Performance tracking will not be static in terms of just providing a snapshot of conditions but will allow mechanisms to measure and contextualize progress towards established targets of Section 4. The dashboard has subscriber account profiles to serve different stakeholders (higher-level management, system engineering analysists, and CUTR analysts). Based on the profile, data visualization and report accessibility changes. One simple page displaying travel conditions in the study area can be used for public display, and this will be completed after discussion with USDOT officials.
9.1.1.1 Prototype Website A prototype website is being developed during Phase II to report performance measures using a data portal. The dashboard user interface is based on Google Angular and integrates interactive charts using a variety of packages and widgets written in R.6 Figure 9-1 displays a snapshot of the welcome page, which provides statistics on all CV data collected by RSUs, the number of active participant vehicles by type, which the user can interact with. The portal includes a set of tabs for each use case, reporting the performance measures applicable to each one, as detailed in Section 8.
6 https://angular.io/ U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |78
Figure 9-1 Performance Measures Reporting Dashboard Source: CUTR
9.2 Reporting to Independent Evaluators
Independent evaluators will have access to CV and non-CV data via the SDC. Section 11 discusses the data-sharing framework.
9.3 Reporting Frequency
Information to the dashboard will be updated daily. Stakeholders will be able to have information displayed by frequency (daily, weekday, or monthly basis). Reporting frequency will be daily, weekly, monthly, or by custom-set date range. Modeled performance evaluation, based on statistical modeling output, will be provided every week.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |79
10 Support for Independent Evaluation (IE) Effort
The THEA CV Pilot Deployment supports monitoring of data capable of quantifying performance measures. The impact of the deployment on the set of key performance measures identified in Section 4 of this document will be monitored and reported on a daily, weekly, and monthly basis. Performance and other data supporting a comprehensive assessment of deployment impacts will be shared with the independent evaluators via the SDC. In addition to data generated by the various CV application, support to the IE extends to participant survey design and administration.
10.1 Physical Elements Data Flow
To provide broader evaluation-related capabilities required to support the THEA site-specific independent evaluation effort, this plan identifies data flow between the physical elements.
10.1.1 Safety CV Evaluation Data The deployment of safety apps generates warning data elements that are locally stored within an OBU in the form of OBU data logs. These logs are transmitted to the RSUs and batch-uploaded to THEA master server and stored as highly compressed flat files. The data logs are pushed to the CUTR server via Secure File Transfer Protocol. The data are subject to quality control, geofencing and PII removal, as described in Section Error! Reference source not found. and are uploaded to the SDC for IE consumption.
10.1.2 Mobility CV Evaluation Data These data contain vehicle sent BSMs, SPAT, TIM, MAP, MMITSS, SRS, and SSM. These are transmitted to the RSUs and batch-uploaded to THEA master server and stored as highly compressed flat files called Data Logs. The data logs are pushed to the CUTR server via Secure File Transfer Protocol. The data are subject to quality control, geofencing and PII removal, as described in Section Error! Reference source not found., and are uploaded to the SDC.
10.1.3 Non-CV Data The CUTR server locally stores agency and third-party data which are used to conduct performance evaluation. To assist the IE, CUTR server will push these data to the SDC: • TMC Event Data Logs • HART OneBusAway GTFS data • Bluetooth Reader Data • Weather API Service Data
Appendix C provides details on the above data sources.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |80
10.2 Participant Surveys
As outlined in the Performance Measurement and Evaluation Support Schedule, the CUTR team will administer participant surveys to aid in the evaluation of the overall effectiveness of the Pilot. The participant sample is expected to be part of the study for 18 months. Therefore, it is possible to collect longitudinal data (over time) to assess behavior changes that the participants may exhibit due to their interaction with the connected vehicle technologies deployed.
The surveys are designed to collect data for the following:
• Socioeconomic conditions and factors • Demographic conditions and factors • Technology attitudes and information specific to the deployed CV apps • Risk proneness • Self-selection
The surveys are planned to be administered in the form of a questionnaire, to be taken at different times during the pilot. A minimum of three surveys will be administered for each road user (private vehicle drivers and transit operators).
An initial survey was administered before the drivers had an opportunity to interact with the technologies. This survey was administered during the installation of the equipment on their vehicles for drivers, and after a training session for transit operators.
A second survey will be administered after the technologies have been activated for the treatment group for six months in the 2nd quarter of 2019, via the same methods described above.
A final survey will be administered before the end of the pilot in the 4th quarter of 2019, for all users who have participated in the study.
An exit survey is administered to all participants who decide to drop out of the study early, and their participation is not considered complete.
The CUTR team, as requested, collaborated with the IE (Volpe) for input on the surveys to ensure the surveys cover their needs as well as the needs of the Pilot Evaluation team. The Institutional Review Board on file with the study for Human Use approval must approve all surveys.
CUTR will collect and upload processed survey data to the SDC.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |81
11 Data Sharing Framework
The objective of the data-sharing framework is to facilitate the sharing of the data generated by the CV Pilot projects so that they can be used for further research into connected vehicle applications and deployments, including other CV Pilot projects. This section describes the data-sharing mechanism in terms of CV and third-party non-CV datasets.
11.1 CV Pilot Data
The CUTR server has been deployed and configured to receive and archive data in the form of data logs stored as flat files in THEA master server protected storage. Data logs contain any information logged locally on the RSU (e.g., BSMs, TIMS, SPaTs), as well as data logs received from OBU (i.e., OBU data logs). OBU data logs contain BSMs, and safety application-generated data, as detailed in the Interface Control Document [27].
Appendix B reports the metadata document details for each of the datasets generated by the CV deployment. These data will be uploaded to the SDC and ITS Public Data Hub, as shown in Figure 11-1.
Figure 11-1 Data Sharing from CUTR Server to USDOT Source: CUTR
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |82
11.2 Non-CV Data
To conduct performance evaluation, the CUTR server conducts fusion and aggregation of non-CV data with CV data. These data sources also provide data preceding the deployment of CV technologies providing a source of pre-deployment baseline information. The following data will be uploaded to the SDC to assist IE assessment efforts:
• City of Tampa TMC Event Data Logs • Hart OneBusAway GTFS Data • Bluetooth Reader Data • Weather Data
Appendix C reports the metadata document details for each of the above data types. All the above data will be sent to SDC as raw data.
11.3 Data Privacy
Privacy issues are considered in the context in which the collection occurs. Privacy concerns for state- owned service vehicles are different from those for data collected from private vehicles. The rules related to privacy must be communicated unambiguously.
1. Establish data ownership. Generally, whoever owns the vehicle, owns the data generated by that vehicle. An OEM may also claim ownership of data published on the vehicle’s data bus. This issue must be resolved. 2. Secure consent from the data owner. The owner of data must consent to provide the data in an agreement (drafted by the CV Pilot THEA team) that spells out how the data are used and by whom. This should include the re-distribution of data to third parties. 3. Protect the privacy of the data owner. Any information that reveals the identity of the data owner must be eliminated. 4. Identify data aggregation issues. In some cases, aggregating CV data over time can reveal patterns that are sensitive from the point of view of commercial, military, or other propriety information about the internal operations of firms or agencies. These situations will be individually handled as they arise.
11.3.1 PII Removal from Data Logs Of concern is any information contained in BSM data from the OBUs, the Roadside Unit (RSU) /sensor data, and any other driving data that can be used to identify a vehicle. The contents in the raw Data Logs primarily contain Basic Safety Message (BSM) generated from vehicles equipped with on- board units (OBU). The CUTR server performs PII removal as part of a nightly batch job before uploading data logs to the SDC. To ensure PII removal, the data logs are subject to cordon truncation to limit the data analysis to the geographic confines of the Tampa CV Pilot Study Area. This is achieved by establishing a geofence around the CV Pilot Study Area and by eliminating all records that place the vehicles outside the cordon. All remaining records are those collected within the CV Pilot Study Area. To conform to IE safety evaluation needs, the SDC data logs will contain a new randomly generated ID. This ID will remain constant over the study time frame to allow the IE conducting safety evaluation performance assessment. This field is removed from the data available in the ITS Public Data Hub. U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |83
11.3.2 Data Sharing Agreement Before uploading data to any repository, necessary data sharing agreements will be obtained. To this extent, the SDC developers have designed and deployed a set of data governance procedures to manage access data generated and uploaded by the USDOT CV Pilots. The SDC developed and implemented a “New Dataset Provider Form,” which has been provided to the CV Pilot Team. The form allows the data provider specifying the information and access level for each data field, as shown in Figure 11-2.
Figure 11-2 Snapshot of SDC New Dataset Provider Form Source: Process for Capture and Addition of Data Sets for the Secure Data Commons and ITS Public Data Hub, December 2018.
11.4 Data Preparation
Within this step, the objective is to prepare the datasets for upload to the SDC and ITS Public Data Hub. Some basic checks that are required in this stage are:
1. Data documentation is complete 2. Data are categorized and structured in a manner that is understandable and useful 3. Data elements are in standard formats (e.g., comma-separated value (CSV) format that enables other parties to read the data without the need for proprietary software) 4. Data conform to an appropriate ITS Standard (e.g., SAE J2735 for DSRC communications, SAE J2354 for center-to-center communications, or IEEE 1512 for incident management) 5. Data are cleared for sharing with appropriate data sharing agreements between the data providers and USDOT
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |84
These basic checks clear the data for archiving. Some special checks are required before data can be transmitted to the SDC and ITS Public Data Hub:
1. Data are free of PII (CV data will be sanitized to remove PII as described in Section 7 and Section 11.3.1.1) 2. Data are in a manageable size and format that is useful to the users (data are broken down into chunks that can be easily downloaded over the internet) 3. Two types of data documentation will accompany each data environment on the ITS Public Data Hub and SDC: 1) metadata documentation and 2) optional data handbook/dictionary documentation. a. Metadata documentation is in a format derived from the ASTM 2468-05 standard metadata format, so there is uniformity in content, structure, and format. b. The optional data handbook/dictionary document contains some of the same information as the metadata document but with additional information regarding files and data elements that were collected. In some cases, the data provider’s existing documentation could serve or be slightly modified to serve as this optional data handbook/dictionary documentation. The additional information provided by the data handbook also includes: i. Details about how the data were collected and processed ii. Background information about the overall task that led to the collection of data being uploaded iii. Specifics regarding how the data was structured iv. Supporting information as to how the requirements and procedures were completed for a data environment v. If a data handbook/dictionary document is being provided to the public via the USDOT, it must be in Section 508 compliant format, and it needs to undergo the USDOT publication process.
If all these checks are complete, the data can be cleared for transmission.
11.5 Transmitting Data
In coordination with the SDC and ITS Public Data Hub developers, data transmission will be carried in nightly batches. Each night at 1:15 A.M. EST, the CUTR server will process and upload CV data generated during the previous day. The upload schedule contains provisions to re-upload data that are not transmitted during the previous period due to technical issues encountered either by the CUTR server or the SDC and ITS Public Data Hub.
The flow of data between servers follows security protocols established in the Data Management Plan and security protocols established by the SDC and ITS Public Data Hub Developers. Figure 11-3 shows the flow of data transmitted to/from the CUTR server.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |85
Figure 11-3 Data Transmission Flow Source: CUTR
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |86
12 Conclusions
This report details the Connected Vehicle Pilot Deployment Program Performance Measurement and Evaluation Support Plan (PMESP), Phase 2 Update– Tampa (THEA). The PMESP outlines a set of goal-related performance measures, along with a detailed data collection and experimental design conducive to comprehensive performance evaluation and assessment. The report presents a detailed approach to the CV Pilot participant selection and to the treatment of confounding factors as evidence of a scientifically sound approach to the design of the entire CV Pilot evaluation. Each of the six use cases deployed in the Pilot is considered individually for experimental design, participant selection, and measurements of performance. Finally, the plan provides a data-sharing framework to provide support to independent evaluation and system performance reporting.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |87
13 References
1. Vasudevan, M. and S.K. Asare, USDOT Guidance Summary for Connected Vehicle Deployment: Performance Measurement. 2016, U.S. Department of Transportation, ITS Joint Program Office: Washington, D.C. 2. Advanced Hydrologic Prediction Service. 2016, National Weather Service. 3. Montgomery, D.C., Design and analysis of experiments. 6th ed. ed. 2005, Hoboken, NJ: John Wiley & Sons. 4. Rosenbaum, P.R. and D.B. Rubin, The Central Role of the Propensity Score in Observational Studies for Causal Effects. Biometrika, 1983. 70(1): p. 41-45. 5. Dehejia, R.H. and S. Wahba, Causal Effects in Nonexperimental Studies: Reevaluating the Evaluation of Training Programs. Journal of the American Statistical Association, 1999. 94(448): p. 1053-1062. 6. Concas, S., Accessibility and Housing Price Resilience: Evidence from Limited-Access Roadways in Florida. Transportation Research Record: Journal of the Transportation Research Board, 2013(forthcoming). 7. Vadali, S., Toll roads and economic development: exploring effects on property values. The Annals of Regional Science, 2008. 42(3): p. 591-620. 8. Funderburg, R.G., et al., New highways and land-use change: results from a quasi- experimental research design. Transportation Research Part A: Policy and Practice, 2010. 44(2): p. 76-98. 9. Rephann, T. and A. Isserman, New highways as economic development tools: An evaluation using quasi-experimental matching methods. Regional Science and Urban Economics, 1994. 24(6): p. 723-751. 10. Li, Q. and J.S. Racine, Nonparametric Econometrics: Theory and Practice, ed. P.U. Press. 2006. 11. Hayfield, T. and J.S. Racine, Nonparametric Econometrics: The np Package. Journal of Statistical Software, 2008. 27(5): p. 1-32. 12. Ming, K. and P.R. Rosenbaum, A Note on Optimal Matching with Variable Controls Using the Assignment Algorithm. Journal of Computational and Graphical Statistics, 2001. 10(3): p. 455-463. 13. Amadie, A. and G.W. Imbens, Bias-Corrected Matching Estimators for Average Treatment Effects. Journal of Business and Economic Statistics, 2011. 29(1): p. 11. 14. Ho, D., et al., Matching as Nonparametric Preprocessing for Reducing Model Dependence in Parametric Causal Inference. Political Analysis, 2007(15): p. 199-236. 15. Reichardt, C.S., Experimental and Quasi-Experimental Designs for Generalized Causal Inference. Social Service Review, 2002(3): p. 510. 16. Shadish, W.R., T.D. Cook, and D.T. Campbell, Experimental and quasi-experimental designs for generalized causal inference. 2002: Boston: Houghton Mifflin, 2002. 17. Florida Transportation Information (TFI) DVD. 2017, Florida Department of Transportation: Tallahassee. 18. Longitudinal Employer-Household Dynamics. 2013 [cited 2016; Available from: http://lehd.ces.census.gov/. 19. Myers, J.L. and A. Well, Research Design and Statistical Analysis. Vol. 2nd ed. 2003, Mahwah, N.J.: Taylor & Francis Ltd. 20. Davey, A. and J. Savla, Statistical Power Analysis with Missing Data: A Structural Equation Modeling Approach. 2010, New York: CRC Press. 21. Lyman, K. and R. Bertini, Using Travel Time Reliability Measures to Improve Regional Transportation Planning and Operations. Transportation Research Record: Journal of the Transportation Research Board, 2008. 2046: p. 1-10. U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |88
22. Sacchi, E. and T. Sayed, Conflict based Safety Performance Functions to Predict Traffic Collisions by Type, in Transportation Research Board 96th Annual Meeting. 2016, Transportation Research Board: Washington, D.C. 23. El-Basyouny, K. and T. Sayed, Safety performance function using traffic conflicts Safety Science, 2013. 51(1): p. 160-164. 24. Smith, S., et al. Benefits Estimation Framework for Automated Vehicle Operations. 2015, U.S. Department of Transportation, Intelligent Transportation Systems Joint Program Office: Washington, D.C. 25. FHWA Performance Reporting - Part two of two. 2013, US DOT Federal Highway Administration: Washington, DC. 26. FHWA Performance Reporting - Part one of two. 2013, US DOT Federal Highway Administration: Washington, DC. 27. Buckel, W. and R. Ignatowicz, Connected Vehicle Pilot Deployment Program, Interface Control Document – THEA CV Pilot. 2018, U.S. Department of Transportation: Washington, DC.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |89
14 Appendices
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |90
14.1 Appendix A: Report on Pedestrian Application Reliability 14.1.1 Overview The THEA CV Pilot uses the following three pedestrian safety applications: • PED-SIG: Mobile Accessible Pedestrian Signal. • PTMW: Pedestrian Transit Movement Warning warns pedestrians of stopping or starting bus or streetcar. • PED-X: Pedestrian in Signalized Crosswalk warns pedestrian when a connected vehicle approaches.
During Phase 2, several reliability issues were identified that make deployment of the Pedestrian Safety application problematic. The following sections were reported by the system integrator Siemens.
14.1.2 Findings The poor positioning accuracy of a GPS device used in a standard phone introduces uncertainty in the pedestrian safety application. Additionally, the accuracy can be reduced due to satellite signal blockage by buildings or trees or due to signal reflection within an urban canyon.
Figure 14-1 Pedestrian App The PED-SIG app requires several steps for requesting the street crossing. The low positioning accuracy can lead to requests being associated with a wrong crosswalk, not the one the pedestrian intends to cross. This problem is exacerbated by the inaccuracy of the digital compass of the
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |91
smartphone. This compass is used to differentiate between requests to cross in an East-West versus North-South direction. In this case, there may be a conflict between the information displayed on the phone and the actual traffic light status of the crosswalk. A user may take the advice of the app over the actual pedestrian signal creating a safety problem.
Figure 14-2 Pedestrian Crossing For example, at Meridian and Whiting, due to the protected southbound left turn, the signal statuses of the two Meridian crossings are different. However, due to the proximity, the app could potentially select the wrong crosswalk and cause a huge safety issue.
The original Pedestrian Safety Application was an open-source application originally developed by the University of Arizona as a CV test tool. It was never designed to be deployable to the public. Siemens improved the usability and functionality of the app and integrated it into the smartphone. However, in its core, the app lacks features/architecture standard for a phone application to be perceived as a safety device by a user.
According to the original design, the smartphone application uses the same SAE J2735 messages that on-board safety devices (OBUs) use. However, instead of the dedicated low latency DSRC communication, it uses standard Wi-Fi communication. The application can lock up when Wi-Fi communication is interrupted, or latency is introduced due to the high number of Wi-Fi devices at the intersection. The smartphone app in the lockup condition may display incorrect status information, thus confusing users.
In an urban deployment like the City of Tampa, several dozen Wi-Fi access points (APs) are within range of the intersection. This creates a lot of Wi-Fi noise resulting in poor range and connection reliability. In tests with UDP communication from the RSU to the smartphone app, loss rates of 30% to 80% were observed. This results in data on the smartphone, such as SPaT becoming stale. Therefore, the information about pedestrian signal status may be outdated, potentially leading to safety concerns. For example, the app may show Flashing Don’t Walk while the signal is already in solid Don’t Walk.
The Pedestrian Transit Movement Warning (PTMW) application uses basic safety messages sent by the equipped vehicles 10 times per second to identify the speed of the transit vehicles. With the increasing number of the equipped vehicles, the number of BSMs may overwhelm the phone communication channel because it is not using DSRC. When overloaded, the app may become unresponsive and fail to display warnings. On the other hand, with loss rates of up to 80%, critical BSMs may also get lost, leading to false negatives. Additionally, it was observed that due to its size, buses disrupt Wi-Fi communicated between the RSU and the smartphone, depending on the position of the pedestrian. This leads to Wi-Fi disconnects and lost warnings.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |92
For the PED-X application, the same findings as for the PTMW app apply.
14.1.3 Improved PED-X Operation For the PED-X Use Case, the goal is to evaluate the effectiveness of using inaccurate mobile devices to generate a Pedestrian Crash Warning (PCW). After initial deployment and testing, the original PED-X operation and data collection method were changed to improve the sample size and data range for the research study. 1. Original PED-X Operation: a. Driver Pedestrian Crash Warnings (driver PCW application in OBU) RSU sends LiDAR PSMs of pedestrian locations to vehicle OBUs OBU calculates crash trajectory based on LiDAR pedestrian locations OBU generates PCWs based on LiDAR pedestrian locations BSMs, PSMs, and PCWs are offloaded from the OBU to the RSU RSU sends BSMs, PSMs, and PCWs based on LiDAR to researchers
Figure 14-3 PED-X Operation - Original b. Pedestrian Crash Warnings (PED-X application in smartphone) 500 or more participant phones are activated with PED-X application OBU sends DSRC BSMs to RSU RSU translates DSRC BSMs to Wi-Fi BSMs to phone PED-X phone application calculates crash trajectories based on phone GPS The smartphone does not display PCW based on phone GPS location PCW based on phone GPS location is sent to researchers For research, OBU PCWs based on LiDAR locations are compared to the phone app PCWs based on the phone GPS location, based on each timestamp.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |93
Figure 14-4 PED-X Operation - Improved
2. Improved PED-X operation a. Driver Warnings: Driver warnings operate identically to 1a) above. b. Pedestrian Warnings: One or more representative smartphones are enabled to log GPS locations while walking in the crosswalk and sidewalk of the study area using typical pedestrian movements observed. At the same time, LiDAR locations are recorded as ground truth of locations. Data logs of both smartphone GPS locations and the corresponding LiDAR GPS locations are provided to the researchers for the effectiveness study. Researchers determine the smartphone GPS range of inaccuracy, compared to LiDAR. PED-X phone application is emulated on the research server. For research, each OBU PCW based on LiDAR location is compared to the PED-X emulation over the range of inaccuracy previously measured in the study area. For example, the range of smartphone GPS inaccuracies is applied to the accurate LiDAR PSM locations of a PCW to determine if PED-X would have also generated a PED-X warning. 3. Advantages of Improved PED-X operation: This improved PED-X operation has the following advantages over the original PED-X operation: Increased sample size: o Original: Creates phone PED-X warning only when an equipped vehicle encounters a pedestrian equipped with the PED-X smartphone app. o Improved: Emulates smartphone PED-X whenever an equipped vehicle encounters both equipped and unequipped pedestrians. Increased sample data arrays: o Original: Collects data based on the inaccuracy of each single uncontrolled participant smartphone encountered. o Improved: Emulates the effectiveness of PED-X over a controlled range of smartphone types and accuracies recorded earlier. Measures the effect of application tuning: o Original: PED-X running in the smartphone relied on the tuning downloaded with PED-X, such as distance, speed, approach direction, pedestrian clusters, and location sample rate. Tuning improvements require software updates to the participants’ s martphones. o Improved: Emulates controlled ranges of tuning parameters to determine optimal tuning that triggers warnings.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |94
14.2 Appendix B: CV Datasets Metadata and Data Dictionary 14.2.1 RSU Data Logs The Tampa CV Pilot generates several datasets from the interaction between vehicles (via OBUs) and between vehicles and infrastructure (OBU/RSU interaction):
• Basic Safety Message (BSM) from the participant and public transit vehicles (up to 10Hz) • Signal Phase and Timing Messages (SPaT) from RSUs (10Hz) • MAP Data Message (MAP) from RSUs (1Hz) • Traveler Information Message (TIM) from RSUs at 1Hz • Signal Request Message (SRM) transmitted by OBUs within DSRC radio range of an RSU • Signal Status Message (SSM) broadcasted by RSUs for conveying back to OBUs the status of its SRM • Multimodal Intelligent Transportation Systems Signal (MMITSS), JSON-formatted Siemens- MMITSS calculated metrics • PED-X – JSON-formatted structure with element “psm” containing the PSM that triggered the collision alert as J2735 MessageFrame in XML encoding containing a PersonalSafetyMessage message.
These datasets are processed for PII removal (see Section 7.3.3.) and packaged in JSON flat files for upload. Each of the datasets above includes the metadata detailed in Table 14-1.
Table 14-1 Tampa CV Pilot Metadata – RSU Data Logs Field Name Definition schemaVersion Version of the metadata schema recordGeneratedAt Closest time to which the record was created, either signed or received by the recordGeneratedBy source in UNIX format. recordGeneratedBy Source of the device, whether (OBU, RSU, PID). logFileName The file name of original files that are received by CUTR CV Performance Evaluation group bsmSource Source of the BSM. Regular vehicle = RV, Transit bus = TB, Street car = SC kind Message type: in: WAVE Short Message (WSM) received by RSU out: WSM sent by RSU log: Internal RSU log event pedx::collision; PSM which triggered the collision alert trafPerf or queueLen: MMITSS performance measures RSUID The ID of the sending RSU, if recordGeneratedBy is RSU externalID The ID of an external source (OBU ID, PID ID) if kind is pedx:: or obu:: psid PSID of WSM sent or received; provided if kind is in or out; BSM=32; SPAT=32770;MAP=3758096407;TIM=32771; SRM=3758096406;SSM=3758096405 ;MMITSS=0: PED-X = 0
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |95
Field Name Definition datatype Type of data: BSM, SPAT, MAP, TIM, SRM, SSM, MMITSS, PED-X
payload Payload content of datatype. See Payload data dictionary
14.2.2 Basic Safety Message (BSM) BSM data are generated by participant and public transportation vehicles onboard units (OBUs) and transmitted to roadside units (RSUs) located throughout the Tampa CV Pilot Study Area. Table 14-2 details the content of the BSM payload, which follows SAE J2735 and J2945/1 standards and adopted units of measure. Table 14-2 BSM Payload Field Name Field Type ASN.1 Primitive Corresponding J2735 Type Data Element Part I, Sent at all times with each message coreData BSMcoreData J2945/1[6.1.6-V2V-STD- J2735-007] msgCnt MsgCount INTEGER (0..127) J2945/1[6.1.6-V2V-STD- J2735-007] id TemporaryID OCTET STRING (SIZE J2945/1[6.1.6-V2V-STD- (4)) J2735-007] secMark Dsecond INTEGER (0..65535) J2945/1[6.1.6-V2V-STD- J2735-007] lat Latitude INTEGER (- J2945/1[6.1.6-V2V-STD- 900000000..900000001) J2735-007] long Longitude INTEGER (- J2945/1[6.1.6-V2V-STD- 1799999999..18000000 J2735-007] 01) elev Elevation INTEGER (- J2945/1[6.1.6-V2V-STD- 4906..61439) J2735-007] accuracy PositionalAccuracy J2945/1[6.1.6-V2V-STD- J2735-007] semiMajor SemiMajorAxisAccuracy INTEGER (0..255) J2945/1[6.1.6-V2V-STD- J2735-007] semiMinor SemiMinorAxisAccuracy INTEGER (0..255) J2945/1[6.1.6-V2V-STD- J2735-007] orientation SemiMajorAxisOrientation INTEGER (0..65535) J2945/1[6.1.6-V2V-STD- J2735-007] Transmission TransmissionState ENUMERATED (0..7) J2945/1[6.1.6-V2V-STD- J2735-007] speed Speed INTEGER (0..8191) J2945/1[6.1.6-V2V-STD- J2735-007] heading Heading INTEGER (0..28800) J2945/1[6.1.6-V2V-STD- J2735-007] angle SteeringWheelAngle INTEGER (-126..127) J2945/1[6.1.6-V2V-STD- J2735-007] accelSet AccelerationSet4Way J2945/1[6.1.6-V2V-STD- J2735-007] long Acceleration INTEGER (-2000..2001) J2945/1[6.1.6-V2V-STD- J2735-007] U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |96
Field Name Field Type ASN.1 Primitive Corresponding J2735 Type Data Element lat Acceleration INTEGER (-2000..2001) J2945/1[6.1.6-V2V-STD- J2735-007] vert VerticalAcceleration INTEGER (-127..127) J2945/1[6.1.6-V2V-STD- J2735-007] yaw YawRate INTEGER (- J2945/1[6.1.6-V2V-STD- 32767..32767) J2735-007] brakes BrakeSystemStatus J2945/1[6.1.6-V2V-STD- J2735-007] wheelBrakes BrakeAppliedStatus BIT STRING (SIZE (5)) J2945/1[6.1.6-V2V-STD- J2735-007] traction TractionControlStatus ENUMERATED (0..3) J2945/1[6.1.6-V2V-STD- J2735-007] abs AntiLockBrakeStatus ENUMERATED (0..3) J2945/1[6.1.6-V2V-STD- J2735-007] scs StabilityControlStatus ENUMERATED (0..3) J2945/1[6.1.6-V2V-STD- J2735-007] brakeBoost BrakeBoostApplied ENUMERATED (0..2) J2945/1[6.1.6-V2V-STD- J2735-007] auxBrakes AuxiliaryBrakeStatus ENUMERATED (0..3) J2945/1[6.1.6-V2V-STD- J2735-007] size VehicleSize J2945/1[6.1.6-V2V-STD- J2735-007] width VehicleWidth INTEGER (0..1023) J2945/1[6.1.6-V2V-STD- J2735-007] length VehicleLength INTEGER (0..4095) J2945/1[6.1.6-V2V-STD- J2735-007] Part II Content partII PartIIcontent {{ J2735 BSMpartIIExtension }} partII-Id PartII-Id INTEGER (0..63) J2735 partII-Value BSMpartIIExtension J2945/1[6.1.6-V2V-STD- J2735-004 vehicleSafetyExten VehicleSafetyExtensions J2945/1[6.3.1-V2V- sions BSMTX-BSMCONT-003] events VehicleEventFlags BIT STRING (SIZE (13, J2945/1[6.3.1-V2V- …)) BSMTX-BSMCONT-006] pathHistory PathHistory J2945/1[6.3.1-V2V- BSMTX-BSMCONT-004] crumbData PathHistoryPointList J2945/1[6.3.6-V2V- BSMTX-DATAACC-036] crumbData[n] PathHistoryPoint J2945/1[6.3.6-V2V- BSMTX-DATAACC-039] latOffset OffsetLL-B18 INTEGER (- J2945/1[6.3.6-V2V- 131072..131071) BSMTX-DATAACC-037] lonOffset OffsetLL-B18 INTEGER (- J2945/1[6.3.6-V2V- 131072..131071) BSMTX-DATAACC-037] elevationOffset VertOffset-B12 INTEGER (-2048..2047) J2945/1[6.3.6-V2V- BSMTX-DATAACC-037]
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |97
Field Name Field Type ASN.1 Primitive Corresponding J2735 Type Data Element timeOffset TimeOffset INTEGER (1..65535) J2945/1[6.3.6-V2V- BSMTX-DATAACC-037] pathPrediction PathPrediction J2945/1[6.3.1-V2V- BSMTX-BSMCONT-004] radiusOfCurve RadiusOfCurvature INTEGER (- J2945/1[6.3.1-V2V- 32767..32767) BSMTX-BSMCONT-004] confidence Confidence INTEGER (0..200) J2945/1[6.3.1-V2V- BSMTX-BSMCONT-004] lights ExteriorLights BIT STRING (SIZE (9, J2945/1[6.3.1-V2V- …)) BSMTX-BSMCONT-005] classDetails VehicleClassification Use classDetails keyType BasicVehicleClass INTEGER (0..255) Use ”transit-LocalBus” for HART buses, use “transit- FixedGuideway” for TECO streetcars role BasicVehicleRole ENUMERATED (0..22) Use role “transit” for both HART buses and TECO streetcars hpmsType VehicleType ENUMERATED (0..15) Use HPMS classes: “car” for light vehicles, “bus” for HART buses, “unknown” for TECO streetcars vehicleData VehicleData height VehicleHeight INTEGER (0..127) bumpers BumperHeights front BumperHeight INTEGER (0..127) rear BumperHeight INTEGER (0..127) mass VehicleMass INTEGER (0..255)
Figure 14-6 reports an example of a BSM in JSON format ready for upload to the SDC and ITS Public Data Hub.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |98
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |99
Figure 14-5 Sample BSM in JSON Format
14.2.3 Signal Phasing and Timing Message (SPaT) Messages SPaTs are continuously broadcasted by RSUs (10Hz) and follow SAE J2735 data frames (Section 6) and data elements (Section 7) structure as detailed in Table 14-3. Table 14-3 SPaT Message Payload
Field Name Field Type ASN.1 Primitive Type Comments intersections IntersectionStateList intersections[n] IntersectionState id IntersectionReferenceID id IntersectionID INTEGER (0..65535)
revision MsgCount INTEGER (0..127) status IntersectionStatusObject BIT STRING (SIZE (16)) timeStamp DSecond INTEGER (0..65535)
enabledLanes EnabledLaneList enabledLanes[n] LaneID INTEGER (0..255) Used for intersection at REL ramp states MovementList states[n] MovementState signalGroup SignalGroupID INTEGER (0..255)
state-time-speed MovementEventList state-time-speed[n] MovementEvent
eventState MovementPhaseState ENUMERATED (0..9) timing TimeChangeDetails
startTime TimeMark INTEGER (0..36001) minEndTime TimeMark INTEGER (0..36001)
maxEndTime TimeMark INTEGER (0..36001) speeds[n] AdvisorySpeed
type AdvisorySpeedType ENUMERATED (0..3)
maneuverAssistList[n] ConnectionManeuverAssist connectionID LaneConnectionID INTEGER (0..255) maneuverAssistList[n] ConnectionManeuverAssist
connectionID LaneConnectionID INTEGER (0..255)
Figure 14-7 reports an example of a SPaT in JSON format ready for upload to the SDC and ITS Public Data Hub.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |100
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |101
Figure 14-6 Example of SPaT in JSON Format
14.2.4 MAP Data Message RSU broadcast MAPs at 1Hz, following structure and nomenclature per SAE J3067 Section 4.3.10 Broadcast Roadway Geometrics Information Dialog. Note that some of the fields in this table are optional for the Tampa CV Pilot, as detailed in the Interface Control Document, as shown in Table 14- 4. Table 14-4 MAP Data Message Payload Field Type ASN.1 Structural Type Clarification Comments MapData MinuteOfTheYear OPTIONAL msgIssueRevision Revision Number layerType layerID intersections SEQUENCE (SIZE(1..32)) intersectionGeometry[n] SEQUENCE 1 to 32 name Use for testing only id SEQUENCE region id revision Revision Number refPoint SEQUENCE (SIZE(1..4)) laneWidth speedLimits SEQUENCE (SIZE(1..9)) Can be provided if needed to support other sites regulatorySpeedLimit[n] SEQUENCE Covered by SpeedLimitList SSP type Covered by SpeedLimitList SSP speed Covered by SpeedLimitList SSP laneSet SEQUENCE (SIZE(1..255)) genericLane[n] SEQUENCE laneID LaneID "1" is the left-most lane of the northbound approach, ApproachID 1.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |102
Field Type ASN.1 Structural Type Clarification Comments Lanes are numbered counterclockwise and include Egress Lanes name Use for testing only ingressApproach ingress (inbound) Either ingress or egress will be set for vehicle lanes. Other lanes (e.g., crosswalk) may not have an approach set. egressApproach egress (outbound) laneAttributes SEQUENCE directionalUse sharedWith laneType CHOICE vehicle crosswalk bikeLane sidewalk median striping trackedVehicle parking regional maneuvers nodeList CHOICE For ingress, Node 1 is the Stop Bar. For egress, Node 1 is where the outbound lane begins; after traversing the intersection nodes SEQUENCE (SIZE(2..63)) nodeXY[n] SEQUENCE delta CHOICE Will use “tight” format
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |103
Field Type ASN.1 Structural Type Clarification Comments produced by ISD tool node-XY1 SEQUENCE x y node-XY2 SEQUENCE x y node-XY3 SEQUENCE x y node-XY4 SEQUENCE x y node-XY5 SEQUENCE x y node-XY6 SEQUENCE x y node-LatLon SEQUENCE lon lat regional attributes SEQUENCE localNode SEQUENCE (SIZE(1..8)) Attribute states which pertain to this node point nodeAttributeXYList disabled SEQUENCE (SIZE(1..8)) Attribute states which are disabled at this node point segmentAttributeXYList enabled SEQUENCE (SIZE(1..8)) Attribute states which are enabled at this node point and which remain enabled until disabled or the lane ends segmentAttributeXYList
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |104
Field Type ASN.1 Structural Type Clarification Comments data SEQUENCE (SIZE(1..8)) Attributes which require additional data values some of these are local to the node point, while others persist with the provided values until changed and this is indicated in each entry laneDataAttribute CHOICE pathEndPointAngle Adjusts final point/width slant of the lane to align with the stop line laneCrownPointCenter Sets the canter of the roadbed from centerline point laneCrownPointLeft Sets the canter of the roadbed from the left edge laneCrownPointRight Sets the canter of the roadbed from the right edge laneAngle The angle or direction of another lane this is required to support Japan- style when a merge point angle is required speedLimits SEQUENCE (SIZE(1..9)) Reference regulatory speed limits used by all segments regulatorySpeedLimit[n] SEQUENCE type speed regional SEQUENCE (SIZE(1..4)) dWidth A value-added to Will use for the current lane tapered width at this node lanes (e.g., and from this node merging onwards, in 1cm lanes) steps lane width between nodes is a linear taper between pts the
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |105
Field Type ASN.1 Structural Type Clarification Comments value of zero shall not be sent here
dElevation A value-added to Will use for the current elevated elevation at this roadways node from this with other node onwards, in roadways 10cm steps underneath elevations between (e.g., nodes, is a linear Selmon taper between pts Expressway) the value of zero shall not be sent here regional SEQUENCE (SIZE(1..4)) computed SEQUENCE Will consider using if MAP size gets too large and tool support exists referenceLaneId offsetXaxis CHOICE small large offsetYaxis CHOICE small large rotateXY scaleXaxis scaleYaxis regional SEQUENCE (SIZE(1..4)) connectsToList SEQUENCE (SIZE(1..16)) connection[n] SEQUENCE connectingLane SEQUENCE lane maneuver remoteIntersection region id signalGroup userClass connectionID
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |106
Field Type ASN.1 Structural Type Clarification Comments overlays SEQUENCE (SIZE(1..5)) laneID[n] regional SEQUENCE (SIZE(1..4)) preemptPriorityData SEQUENCE (SIZE(1..32)) regional SEQUENCE (SIZE(1..4)) roadSegments SEQUENCE (SIZE(1..32)) roadSegmentList name id[n] SEQUENCE regional id revision refPoint[n] SEQUENCE lat long elevation regional SEQUENCE (SIZE(1..4)) laneWidth speedLimits SEQUENCE (SIZE(1..9)) regulatorySpeedLimit[n] SEQUENCE Covered by parent SpeedLimitList SSP type Covered by parent SpeedLimitList SSP speed Covered by parent SpeedLimitList SSP roadLaneSet genericLane[n] SEQUENCE laneID LaneID "1" is the left-most lane of northbound approach, ApproachID 1. Lanes are numbered counterclockwise and include Egress Lanes name Use for testing only ingressApproach ingress (inbound) Either ingress or egress will U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |107
Field Type ASN.1 Structural Type Clarification Comments be set for vehicle lanes. Other lanes (e.g., crosswalk) may not have an approach set. egressApproach egress (outbound) laneAttributes SEQUENCE directionalUse Will use both bits set to "0" to indicate "No Travel" lanes which exist at the REL entrance ramp (intersection Meridian & Twiggs) sharedWith laneType CHOICE vehicle crosswalk bikeLane sidewalk median striping trackedVehicle parking regional maneuvers nodeList CHOICE For ingress, Node 1 is the Stop Bar. For egress, Node 1 is where the outbound lane begins; after traversing the intersection nodes SEQUENCE (SIZE(2..63)) nodeXY[n] SEQUENCE delta CHOICE Will use “tight” format U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |108
Field Type ASN.1 Structural Type Clarification Comments produced by ISD tool node-XY1 SEQUENCE x y node-XY2 SEQUENCE x y node-XY3 SEQUENCE x y node-XY4 SEQUENCE x y node-XY5 SEQUENCE x y node-XY6 SEQUENCE x y node-LatLon SEQUENCE lon lat regional attributes SEQUENCE localNode SEQUENCE (SIZE(1..8)) Attribute states that pertain to this node point nodeAttributeXYList disabled SEQUENCE (SIZE(1..8)) Attribute states are disabled at this node point segmentAttributeXYList enabled SEQUENCE (SIZE(1..8)) Attribute states that are enabled at this node point and which remain enabled until disabled or the lane ends segmentAttributeXYList
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |109
Field Type ASN.1 Structural Type Clarification Comments data SEQUENCE (SIZE(1..8)) Attributes that require additional data values some of these are local to the node point, while others persist with the provided values until changed and this is indicated in each entry laneDataAttribute CHOICE pathEndPointAngle Adjusts final point/width slant of the lane to align with the stop line laneCrownPointCenter sets the canter of the roadbed from centerline point laneCrownPointLeft Sets the canter of the roadbed from the left edge laneCrownPointRight Sets the canter of the roadbed from the right edge laneAngle The angle or direction of another lane this is required to support Japan- style when a merge point angle is required speedLimits Reference regulatory speed limits used by all segments regulatorySpeedLimit[n] SEQUENCE type speed regional SEQUENCE (SIZE(1..4)) dWidth A value-added to Will use for the current lane tapered width at this node lanes (e.g., and from this node merging onwards, in 1cm lanes) steps lane width between nodes is a linear taper between pts the
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |110
Field Type ASN.1 Structural Type Clarification Comments value of zero shall not be sent here
dElevation A value-added to Will use for the current elevated elevation at this roadways node from this with other node onwards, in roadways 10cm steps underneath elevations between (e.g., nodes, is a linear Selmon taper between pts Expressway) the value of zero shall not be sent here regional SEQUENCE (SIZE(1..4)) computed SEQUENCE Will consider using if MAP size gets too large and tool support exists referenceLaneId offsetXaxis CHOICE small large offsetYaxis CHOICE small large rotateXY scaleXaxis scaleYaxis regional SEQUENCE (SIZE(1..4)) connectsToList SEQUENCE (SIZE(1..16)) connection[n] SEQUENCE connectingLane SEQUENCE lane maneuver remoteIntersection region id signalGroup userClass connectionID
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |111
Field Type ASN.1 Structural Type Clarification Comments overlays SEQUENCE (SIZE(1..5)) laneID regional SEQUENCE (SIZE(1..4)) regional SEQUENCE (SIZE(1..4)) dataParameters SEQUENCE restrictionList SEQUENCE (SIZE(1..254)) restrictionClassAssignment[n] SEQUENCE Covered by RestrictionClassList SSP id Covered by RestrictionClassList SSP users SEQUENCE (SIZE(1..254)) Covered by RestrictionClassList SSP restrictionUserType[n] CHOICE Covered by RestrictionClassList SSP basicType Covered by RestrictionClassList SSP regional SEQUENCE (SIZE(1..4)) Covered by RestrictionClassList SSP regional SEQUENCE (SIZE(1..4))
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |112
14.2.5 Traveler Information Message (TIM) RSUs transmit TIM messages at 1Hz to OBUs within DSRC radio range. TIMS follow an SAE J2735 TIM message structure to convey important traffic information to OBUs of equipped vehicles. Refer to SAE J2735 Section 5.16 Message: MSG_TravelerInformation Message (TIM). Table 14-5 shows the payload. Table 14-5 TIM Payload Field Name Field Type ASN.1 Primitive Type Comments msgCnt MsgCount INTEGER (0..127) To be increased whenever the content of any TravelerDataFrame changes timeStamp MinuteOfTheYear INTEGER(0..527040) packetID UniqueMSGID OCTET STRING (SIZE(9)) urlB URL-Base IA5String (SIZE(1..45)) dataFrames TravelerDataFrameList dataFrames[n] TravelerDataFrame -- Part I, Frame Header sspTimRights SSPindex INTEGER (0..31) Set value to zero frameType TravelerInfoType ENUMERATED { 0..3 } Advisory msgId furtherInfoId FurtherInfoID OCTET STRING (SIZE(2)) roadSignID RoadSignID position3D Position3D Latitude and longitude of the start of speed recommendation lat Latitude INTEGER (- 900000000..900000001) long Longitude INTEGER (- 1799999999..1800000001) elevation Elevation INTEGER (-4096..61439) regional regional[n] RegionalExtension {{ REGION.Reg- Position3D }} viewAngle HeadingSlice BIT STRING (SIZE(16)) 180-degree wide range of angles from which a corresponding road sign would be viewable/legible to an oncoming driver. mutcdCode MUTCDCode ENUMERATED { 0..6 } MUTCD has no appropriate code for an ERDW speed advisory or wrong-way driver warning. msgCrc MsgCRC OCTET STRING (SIZE(2)) Unclear how this CRC would be calculated and then later verified being in the middle of a larger UPER message
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |113
Field Name Field Type ASN.1 Primitive Type Comments startYear DYear startTime MinuteOfTheYear INTEGER (0..527040) ERDW: Time when this speed recommendation goes into effect. This would usually be a past point in time. WWE: Time when wrong-way driver warning was issued duratonTime MinutesDuration INTEGER (0..32000) Duration of validity of this speed recommendation or wrong-way driver warning. priority SignPriority INTEGER (0..7) ERDW: 4 WWE: 7 -- Part II, Applicable Regions of Use sspLocationRights SSPindex INTEGER (0..31) Set value to zero regions GeographicalPath name DescriptiveName IA5String (SIZE(1..63)) For debugging purposes id RoadSegmentReferen Will populate if ceID available region RoadRegulatorID INTEGER (0..65535) id RoadSegmentID INTEGER (0..65535) anchor Position3D Latitude and longitude of the start of speed recommendation
This would be redundant with the road sign position. So possibly omitted. lat Latitude INTEGER (- 900000000..900000001) long Longitude INTEGER (- 1799999999..1800000001) elevation Elevation INTEGER (-4096..61439) regional regional[n] RegionalExtension {{ REGION.Reg- Position3D }} laneWidth LaneWidth INTEGER (0..32767) directionality DirectionOfUse ENUMERATED { 0..3 } Forward closedPath BOOLEAN Assume that omitting element indicates closedPath == false direction HeadingSlice BIT STRING (SIZE(16)) Not needed as the direction is implied by node list and directionality description
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |114
Field Name Field Type ASN.1 Primitive Type Comments path OffsetSystem scale Zoom INTEGER (0..15) offset xy NodeListXY nodes NodeSetXY nodes[n] NodeXY delta NodeOffsetPointXY node-XY1 Node-XY-20b Delta nodes will be populated based on the capabilities of the USDOT TIM tool. x Offset-B10 INTEGER (-512..511) y Offset-B10 INTEGER (-512..511) node-XY2 Node-XY-22b x Offset-B11 INTEGER (-1024..1023) y Offset-B11 INTEGER (-1024..1023) node-XY3 Node-XY-24b x Offset-B12 INTEGER (-2048..2047) y Offset-B12 INTEGER (-2048..2047) node-XY4 Node-XY-26b x Offset-B13 INTEGER (-4096..4095) y Offset-B13 INTEGER (-4096..4095) node-XY5 Node-XY-28b x Offset-B14 INTEGER (-8192..8192) y Offset-B14 INTEGER (-8192..8192) node-XY6 Node-XY-32b x Offset-B16 INTEGER (-32768..32768) y Offset-B16 INTEGER (-32768..32768) node-LatLon Node-LLmD-64b lon Longitude INTEGER (- 1799999999..1800000001) lat Latitude INTEGER (- 900000000..900000001) regional RegionalExtension {{ REGION.Reg- NodeOffsetPointXY }} attributes NodeAttributeSetXY localNode NodeAttributeXYList localNode[n] NodeAttributeXY ENUMERATED disabled SegmentAttributeXYLi st disabled[n] SegmentAttributeXY ENUMERATED enabled SegmentAttributeXYLi st enabled[n] SegmentAttributeXY ENUMERATED data LaneDataAttributeList data[n] LaneDataAttribute pathEndPointAngle DeltaAngle INTEGER (-150..150) laneCrownPointCenter RoadwayCrownAngle INTEGER (-128..127)
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |115
Field Name Field Type ASN.1 Primitive Type Comments laneCrownPointLeft RoadwayCrownAngle INTEGER (-128..127) laneCrownPointRight RoadwayCrownAngle INTEGER (-128..127) laneAngle MergeDivideNodeAngl INTEGER (-180..180) e speedLimits SpeedLimitList speedLimits[n] RegulatorySpeedLimit type SpeedLimitType ENUMERATED speed Velocity INTEGER (0..8191) regional regional[n] RegionalExtension {{ REGION.Reg- LaneDataAtrribute }} dWidth Offset-B10 INTEGER (-512..511) Need lane width changes dElevation Offset-B10 INTEGER (-512..511) Need elevation per node since the REL is an elevated roadway with other roads crossing underneath regional regional[n] RegionalExtension {{ REGION.Reg- NodeAttributeSetXY }} computed ComputedLane referenceLaneId LaneID INTEGER (0..255) offsetXaxis small DrivenLineOffsetSm INTEGER (-2047..2047) large DrivenLineOffsetLg INTEGER (-32767..32767) offsetYaxis small DrivenLineOffsetSm INTEGER (-2047..2047) large DrivenLineOffsetLg INTEGER (-32767..32767) rotateXY Angle INTEGER (0.28800) scaleXaxis Scale-B12 INTEGER (-2048..2047) scaleYaxis Scale-B12 INTEGER (-2048..2047) regional regional[n] RegionalExtension {{ REGION.Reg- ComputedLane }} ll NodeListLL nodes NodeSetLL SEQUENCE (SIZE (2..63)) nodes[n] NodeLL delta NodeOffsetPointLL node-LL1 Node-LL-24B lon OffsetLL-B12 INTEGER (-2048..2047) lat OffsetLL-B12 INTEGER (-2048..2047) node-LL2 Node-LL-28B lon OffsetLL-B14 INTEGER (-8192..8191) lat OffsetLL-B14 INTEGER (-8192..8191) node-LL3 Node-LL-32B lon OffsetLL-B16 INTEGER (-32768..32767)
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |116
Field Name Field Type ASN.1 Primitive Type Comments lat OffsetLL-B16 INTEGER (-32768..32767) node-LL4 Node-LL-36B lon OffsetLL-B18 INTEGER (-131072..131071) lat OffsetLL-B18 INTEGER (-131072..131071) node-LL5 Node-LL-44B lon OffsetLL-B22 INTEGER (-2097152..2097151) lat OffsetLL-B22 INTEGER (-2097152..2097151) node-LL6 NodeLL-48B lon OffsetLL-B24 INTEGER (-8388608..8388607) lat OffsetLL-B24 INTEGER (-8388608..8388607) node-LatLon Node-LLmD-64b lon Longitude INTEGER (- 1799999999..1800000001) lat Latitude INTEGER (- 900000000..900000001) regional RegionalExtension {{ REGION.Reg- NodeOffsetPointLL }} attributes NodeAttributeSetLL localNode NodeAttributeLLList localNode[n] NodeAttributeLL ENUMERATED disabled SegmentAttributeLLLis t disabled[n] SegmentAttributeLL ENUMERATED enabled SegmentAttributeLLLis t enabled[n] SegmentAttributeLL ENUMERATED data LaneDataAttributeList data[n] LaneDataAttribute pathEndPointAngle DeltaAngle INTEGER (-150..150) laneCrownPointCenter RoadwayCrownAngle INTEGER (-128..127) laneCrownPointLeft RoadwayCrownAngle INTEGER (-128..127) laneCrownPointRight RoadwayCrownAngle INTEGER (-128..127) laneAngle MergeDivideNodeAngl INTEGER (-180..180) e speedLimits SpeedLimitList speedLimits[n] RegulatorySpeedLimit type SpeedLimitType ENUMERATED speed Velocity INTEGER (0..8191) regional regional[n] RegionalExtension {{ REGION.Reg- LaneDataAtrribute }} dWidth Offset-B10 INTEGER (-512..511) dElevation Offset-B10 INTEGER (-512..511) regional regional[n] RegionalExtension {{ REGION.Reg- NodeAttributeSetLL }} geometry GeometricProjection
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |117
Field Name Field Type ASN.1 Primitive Type Comments direction HeadingSlice BIT STRING (SIZE(16)) extent Extent ENUMERATED laneWidth LaneWidth INTEGER (0..32767) circle Circle center Position3D lat Latitude INTEGER (- 900000000..900000001) long Longitude INTEGER (- 1799999999..1800000001) elevation Elevation INTEGER (-4096..61439) regional regional[n] RegionalExtension {{ REGION.Reg- Position3D }} radius Radius-B12 INTEGER (0..40695) units DistanceUnits ENUMERATED (0..7) regional regional[n] RegionalExtension {{ REGION.Reg- GeometricProjection }} oldRegion ValidRegion direction HeadingSlice BIT STRING (SIZE (16)) extent Extent ENUMERATED { 0..15 } area shapePointSet ShapePointSet anchor Position3D lat Latitude INTEGER (- 900000000..900000001) long Longitude INTEGER (- 1799999999..1800000001) elevation Elevation INTEGER (-4096..61439) regional regional[n] RegionalExtension {{ REGION.Reg- Position3D }} laneWidth LaneWidth INTEGER (0..32767) directionality DirectionOfUse ENUMERATED { 0..3 } nodeList NodeListXY nodes NodeSetXY nodes[n] NodeXY delta NodeOffsetPointXY node-XY1 Node-XY-20b x Offset-B10 INTEGER (-512..511) y Offset-B10 INTEGER (-512..511) node-XY2 Node-XY-22b x Offset-B11 INTEGER (-1024..1023) y Offset-B11 INTEGER (-1024..1023) node-XY3 Node-XY-24b x Offset-B12 INTEGER (-2048..2047) y Offset-B12 INTEGER (-2048..2047)
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |118
Field Name Field Type ASN.1 Primitive Type Comments node-XY4 Node-XY-26b x Offset-B13 INTEGER (-4096..4095) y Offset-B13 INTEGER (-4096..4095) node-XY5 Node-XY-28b x Offset-B14 INTEGER (-8192..8192) y Offset-B14 INTEGER (-8192..8192) node-XY6 Node-XY-32b x Offset-B16 INTEGER (-32768..32768) y Offset-B16 INTEGER (-32768..32768) node-LatLon Node-LLmD-64b lon Longitude INTEGER (- 1799999999..1800000001) lat Latitude INTEGER (- 900000000..900000001) regional RegionalExtension {{ REGION.Reg- NodeOffsetPointXY }} attributes NodeAttributeSetXY localNode NodeAttributeXYList localNode[n] NodeAttributeXY ENUMERATED disabled SegmentAttributeXYLi st disabled[n] SegmentAttributeXY ENUMERATED enabled SegmentAttributeXYLi st enabled[n] SegmentAttributeXY ENUMERATED data LaneDataAttributeList data[n] LaneDataAttribute pathEndPointAngle DeltaAngle INTEGER (-150..150) laneCrownPointCenter RoadwayCrownAngle INTEGER (-128..127) laneCrownPointLeft RoadwayCrownAngle INTEGER (-128..127) laneCrownPointRight RoadwayCrownAngle INTEGER (-128..127) laneAngle MergeDivideNodeAngl INTEGER (-180..180) e speedLimits SpeedLimitList speedLimits[n] RegulatorySpeedLimit type SpeedLimitType ENUMERATED speed Velocity INTEGER (0..8191) regional regional[n] RegionalExtension {{ REGION.Reg- LaneDataAtrribute }} dWidth Offset-B10 INTEGER (-512..511) dElevation Offset-B10 INTEGER (-512..511) regional regional[n] RegionalExtension {{ REGION.Reg- NodeAttributeSetXY }} computed ComputedLane referenceLaneId LaneID INTEGER (0..255)
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |119
Field Name Field Type ASN.1 Primitive Type Comments offsetXaxis small DrivenLineOffsetSm INTEGER (-2047..2047) large DrivenLineOffsetLg INTEGER (-32767..32767) offsetYaxis small DrivenLineOffsetSm INTEGER (-2047..2047) large DrivenLineOffsetLg INTEGER (-32767..32767) rotateXY Angle INTEGER (0.28800) scaleXaxis Scale-B12 INTEGER (-2048..2047) scaleYaxis Scale-B12 INTEGER (-2048..2047) regional regional[n] RegionalExtension {{ REGION.Reg- ComputedLane }} circle Circle center Position3D lat Latitude INTEGER (- 900000000..900000001) long Longitude INTEGER (- 1799999999..1800000001) elevation INTEGER (-4096..61439) regional regional[n] RegionalExtension {{ REGION.Reg- Position3D }} radius Radius-B12 INTEGER (0..40695) units DistanceUnits ENUMERATED (0..7) regionPointSet RegionPointSet anchor Position3D lat Latitude INTEGER (- 900000000..900000001) long Longitude INTEGER (- 1799999999..1800000001) elevation Elevation INTEGER (-4096..61439) regional regional[n] RegionalExtension {{ REGION.Reg- Position3D }} scale Zoom INTEGER (0..15) nodeList RegionList nodeList[n] RegionOffsets xOffset OffsetLL-B16 INTEGER (-32768..32767) yOffset OffsetLL-B16 INTEGER (-32768..32767) zOffset OffsetLL-B16 INTEGER (-32768..32767) regional regional[n] RegionalExtension {{ REGION.Reg- GeographicalPath -- Part III, Content sspMsgRights1 SSPindex INTEGER (0..31) Set value to zero sspMsgRights2 SSPindex INTEGER (0..31) Set value to zero
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |120
Field Name Field Type ASN.1 Primitive Type Comments content advisory ITIS.ITIScodesAndTex t item itis ITIScodes INTEGER (0..65535) ERDW: Used by a reduced speed recommendation zone. Advice for 20 MPH speed for example: speed-limit (268), n20 (12564), mPH (8720)
WWE: Used to warn oncoming traffic of wrong-way driver: Vehicle-traveling- wrong-way (1793) text ITIStext IA5String (SIZE(1.500)) workZone WorkZone item itis ITIS.ITIScodes INTEGER (0..65535) text ITIStextPhrase IA5String (SIZE(1..16)) genericSign GenericSignage item itis ITIS.ITIScodes INTEGER (0..65535) text ITIStextPhrase IA5String (SIZE(1..16)) speedLimit SpeedLimit ERDW: For posted speed limit of 40 MPH item itis ITIS.ITIScodes INTEGER (0..65535) ERDW: Used for posted speed limit of 40 MPH: Speed-limit (268), n40 (12584), mPH (8720) text ITIStextPhrase IA5String (SIZE(1..16)) exitService ExitService item itis ITIS.ITIScodes INTEGER (0..65535) text ITIStextPhrase IA5String (SIZE(1..16)) url URL-Short IA5String (SIZE(1..15))
regional regional[n] RegionalExtension {{ REGION.Reg- TravelerInformation }}
14.2.6 Signal Request Message (SRM) An OBU transmits SRM messages as it gets within DSRC radio range of an RSU. The RSU processes SRMs for multiple OBUs and responds by broadcasting SSMs (signal status) for conveying
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |121
back to OBUs the status of their priority request. An OBU uses the MAP and SPaT information to determine its precise location for a signalized intersection that it is approaching. It then decides whether to request priority service for a particular movement through the intersection (e.g., left turn movement from eastbound Main Street) and sends out a corresponding SRM. OBUs broadcast SRMs at 10 Hz until the request is mirrored back inside the SSM. Updated SRMs are sent as needed after that. Refer to SAE J2735 Section 5.14 Message: MSG_SignalRequestMessage (SRM). Table 14-6 reports the payload. Table 14-6 SRM Payload
Field Name Field Type ASN.1 Primitive Type Comments timeStamp MinuteOfTheYear INTEGER (0..527040) second DSecond INTEGER (0..65535)
MsgCount sequenceNumber requests SignalRequestList
requests[n] SignalRequestPackage request SignalRequest
id IntersectionReferenceID region RoadRegulatorID INTEGER (0..65535)
id IntersectionID INTEGER (0..65535) requestID RequestID INTEGER (0..255)
PriorityRequestType ENUMERATED (0..3) requestType IntersectionAccessPoint inBoundLane lane LaneID INTEGER (0..255) MMITSS uses lane ID ApproachID INTEGER (0..15) approach LaneConnectionID INTEGER (0..255) connection IntersectionAccessPoint outBoundLane lane LaneID INTEGER (0..255) MMITSS uses lane ID ApproachID INTEGER (0..15) approach LaneConnectionID INTEGER (0..255) connection regional
RegionalExtension {{ REGION.Reg- regional[n] SignalRequest }} minute MinuteOfTheYear INTEGER (0..527040)
second DSecond INTEGER (0..65535) duration DSecond INTEGER (0..65535)
regional RegionalExtension {{ REGION.Reg- regional[n] SignalRequestPackage }} U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |122
Field Name Field Type ASN.1 Primitive Type Comments requestor RequestorDescription id VehicleID
entityID TemporaryID OCTET STRING (SIZE (4)) stationID StationID INTEGER (0..4294967295)
type RequestorType role BasicVehicleRole ENUMERATED (0..22) Set to the appropriate role for bus requesting priority service subrole RequestSubRole ENUMERATED (0..15) request RequestImportanceLevel ENUMERATED (0..15)
iso3883 Iso3833VehicleType INTEGER (0..100) hpmsType VehicleType ENUMERATED (0..15)
regional RegionalExtension {{ REGION.Reg- RequestorType }} position RequestorPositionVector
position Position3D lat Latitude INTEGER (-900000000..900000001) long Longitude INTEGER (-1799999999..1800000001) elevation Elevation INTEGER (-4906..61439)
regional RegionalExtension {{ REGION.Reg- regional[n] Position3D }} heading Angle INTEGER (0..28800) speed TransmissionAndSpeed
TransmissionState ENUMERATED (0..7) transmission speed Velocity INTEGER (0..8191) name DescriptiveName IA5String (SIZE (1..63)) Contains VIN routeName DescriptiveName IA5String (SIZE (1..63))
transitStatus TransitVehicleStatus BIT STRING (SIZE (8)) TransitVehicleOccupancy ENUMERATED (0..7) transitOccupancy DeltaTime INTEGER (-122..121) transitSchedule regional
regional[n] RegionalExtension {{ REGION.Reg- RequestorDescription }} regional
regional[n] RegionalExtension {{ REGION.Reg- SignalRequestMessage }}
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |123
14.2.7 Signal Status Message (SSM) The RSU processes SRMs for multiple OBUs and responds by broadcasting SSMs (signal status) for conveying back to OBUs the status of their priority request. The RSU broadcasts SSM messages for as long as pending priority requests are being processed. Refer to SAE J2735 Section 5.15 Message: MSG_SignalStatusMessage (SSM). Table 14-7 shows the payload. Table 14-7 SSM Payload ASN.1 Primitive Field Name Field Type Type Comments MSG_SignalStatusMes sage timeStamp MinuteOfTheYear INTEGER (0..527040) second Dsecond sequenceNumber MsgCount INTEGER (0..127) status SignalStatusList status[n] SignalStatus MsgCount INTEGER (0..127) sequenceNumber id IntersectionReferenceID region RoadRegulatorID INTEGER (0..65535) id IntersectionID INTEGER (0..65535) sigStatus SignalStatusPackageList sigStatus[n] SignalStatusPackage requester SignalRequesterInfo id VehicleID TemporaryID OCTET STRING (SIZE entityID (4)) StationID INTEGER stationID (0..4294967295) request RequestID INTEGER (0..255) MsgCount INTEGER (0..127) sequenceNumber role BasicVehicleRole ENUMERATED (0..22) type RequestorType role BasicVehicleRole ENUMERATED (0..22) RequestSubRole ENUMERATED (0..15) subrole RequestImportanceLevel ENUMERATED (0..15) request Iso3833VehicleType INTEGER (0..100) iso3883 VehicleType ENUMERATED (0..15) hpmsType RegionalExtension {{ regional REGION.Reg-RequestorType }} inboundOn IntersectionAccessPoint lane LaneID INTEGER (0..255) MMITSS uses lane ID U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |124
ASN.1 Primitive Field Name Field Type Type Comments approach ApproachID INTEGER (0..15) LaneConnectionID INTEGER (0..255) connection IntersectionAccessPoint outboundOn lane LaneID INTEGER (0..255) MMITSS uses lane ID approach ApproachID INTEGER (0..15) LaneConnectionID INTEGER (0..255) connection minute MinuteOfTheYear INTEGER (0..527040) second DSecond INTEGER (0..65535) duration DSecond INTEGER (0..65535) status PrioritizationResponseStatus ENUMERATED (0..7) regional RegionalExtension {{ regional[n] REGION.Reg- SignalStatusPackage }} regional regional[n] RegionalExtension {{ REGION.Reg-SignalStatus }} regional regional[n] RegionalExtension {{ REGION.Reg- SignalStatusMessage }}
14.2.8 Multi-Modal Intelligent Traffic Signal System (MMITSS) This dataset contains JSON-formatted Siemens-MMITSS calculated metrics.7 Siemens-MMITSS receives BSMs from OBUs and estimates queue lengths based on monitoring each vehicle’s speed and location as it approaches the intersection. This queue length is used as input to I-SIG for optimizing the phase time allocation. Table 14-8 reports the payload. Table 14-8 MMITSS Payload Unit of Field Name Field Type Measures Comments queue_len INTEGER (0..100) meters Available for each configured movement queue_count INTEGER (0..100) count Number of vehicles in queue approach INTEGER (0..100) number MAP approach ID Lane INTEGER (0..100) number MAP lane ID vehicle_count INTEGER (0..100) count Number of vehicles Delay INTEGER (0..100) seconds Average delay
7 For a complete list of MMITSS performance metrics, see:” MMITSS Detail Design, Version 1.1 (pp.113-117)” U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |125
Unit of Field Name Field Type Measures Comments throughput INTEGER (0..100) count Total vehicle throughput traversing the intersection num_stops INTEGER (0..100) count Number of stops incurred by all vehicles at the intersection movement INTEGER (0..100) string Movement name travel_time INTEGER (0..100) seconds Average travel time
Figure 14-8 and Figure 14-9 provide examples MMITSS in JSON Format.
Figure 14-7 Example (1) of MMITSS in JSON Format
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |126
Figure 14-8 Example (2) of MMITSS in JSON Format
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |127
14.2.9 PED-X Personal Safety Message (PSM) The PED-X application on the RSU is connected with a Pedestrian Detection System, which is based on LiDAR. The system is going to be deployed at the unsignalized crosswalk across Twiggs Street near the courthouse. The LiDAR system can accurately measure a pedestrian’s location and track his/her movements. The LiDAR system converts this information into Personal Safety Messages (PSMs) for each tracked pedestrian and sends them out to equipped vehicles via the RSU. The pedestrian collision warning (PCW) app on the OBU receives the PSMs and uses the vehicle’s location and trajectory to calculate a pedestrian collision threat. The collision threat payload “psm” contains the PSM using SAE J2735 MessageFrame in XML encoding. This payload is uploaded to the SDC as a JSON formatted payload, as detailed in Table 14-9. Table 14-9 PSM Payload Field Corresponding J2735 Data Name Field Type ASN.1 Primitive Type Element basicType aPEDESTRIAN secMark Dsecond INTEGER (0..65535) J2945/1[6.1.6-V2V-STD-J2735- 007] msgCnt MsgCount INTEGER (0..127) J2945/1[6.1.6-V2V-STD-J2735- 007] Id TemporaryID OCTET STRING (SIZE (4)) J2945/1[6.1.6-V2V-STD-J2735- 007] Lat Longitude INTEGER (- J2945/1[6.1.6-V2V-STD-J2735- 1799999999..1800000001) 007] Long Elevation INTEGER (-4906..61439) J2945/1[6.1.6-V2V-STD-J2735- 007] semiMajor SemiMajorAxisAcc INTEGER (0..255) J2945/1[6.1.6-V2V-STD-J2735- uracy 007] semiMinor SemiMinorAxisAcc INTEGER (0..255) J2945/1[6.1.6-V2V-STD-J2735- uracy 007] Orientatio SemiMajorAxisOri INTEGER (0..65535) J2945/1[6.1.6-V2V-STD-J2735- n entation 007] Speed Speed INTEGER (0..8191) J2945/1[6.1.6-V2V-STD-J2735- 007] Heading Heading INTEGER (0..28800) J2945/1[6.1.6-V2V-STD-J2735- 007] pathPredi ction radiusOfC RadiusOfCurvatur INTEGER (-32767..32767) J2945/1[6.3.1-V2V-BSMTX- urve e BSMCONT-004] Confidenc Confidence INTEGER (0..200) J2945/1[6.3.1-V2V-BSMTX- e BSMCONT-004]
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |128
14.3 Appendix C: OBU Data Logs
OBU data logs contain all data received and transmitted by an OBU. OBUs collect various data falling into one of the following categories:
• WSMP messages sent or received • Warnings issued to the driver • Internal system monitoring events (e.g., SD card space, security audits)
Driver warning event records shall be created whenever one of the warnings listed in Table 9 is triggered by the OBU. The OBU creates a unique warning ID is used to identify multiple WarningEventData records belonging to the same warning event. The OBU creates a set of WarningEventData records per warning. Each record of the set will represent a point in time before, during, and after the warning triggered. A WarningEventData record always contains the host vehicle’s (HV) BSM at a given point in time within “hvBSM.” Warnings, which result from receiving a BSM from a remote vehicle (RV), populate the “rvBSM” field with the BSM of that vehicle. Before and after data records for the warning populate the “rvBSM” field with BSMs received from the same vehicle. The remote vehicle is identified by its TemporaryID contained within the BSM. Likewise, warnings, which result from receiving a PSM, shall populate the “vruPSM” field with PSMs from the vulnerable road user triggering the pedestrian collision warning. Due to their size and complexity (e.g., embedding several payloads), OBU data logs are XML encoded and compressed as flat files for upload by the CUTR server to the SDC, along with a separate data dictionary. Table 14-10 details the contents of the OBU data logs. Table 14-10 OBU Data Logs Content EventType Description sentBSM Log a single WSMP EventData entry per BSM sent by the OBU. receivedBSM Log a single WSMP_EventData entry per BSM received by the OBU. receivedMAP Log a single WSMP_EventData entry per MAP received by the OBU. The OBU shall log a new entry when it receives the first MAP for a new intersection (identified by IntersectionReferenceID). The OBU shall also log a MAP whenever the MAP’s revision has changed. receivedSPAT Log a single WSMP_EventData entry per SPaT received by the OBU. The OBU shall log a new entry when it receives the first SPaT for an intersection (identified by IntersectionReferenceID). The OBU shall also log a SPaT whenever the SPaT’s content has changed (indicated by updated IntersectionState.timeStamp). receivedTIM Log a single WSMP EventData entry per TIM received by the OBU. The OBU shall log a new entry when it receives a TIM for the first time. The OBU shall also log a TIM whenever the TIM’s content has changed (indicated by updated TravelerDataFrame.startTime and TravelerDataFrame.durationTime). sentSRM Log a single WSMP EventData entry per SRM sent by the OBU. The OBU shall log all SRMs it sends. receivedSSM Log a single WSMP EventData entry per SSM received by the OBU. The OBU shall log a new entry when it receives an SSM from an intersection (identified by IntersectionReferenceID) for the first time. The OBU shall also log an SSM whenever the SSM’s content has changed (indicated by updated SignalStatus.sequenceNumber). receivedPSM Log a single WSMP EventData entry per PSM received by the OBU. The OBU shall log all PSMs it receives.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |129
EventType Description warningFCW Log a set of WarningEventData entries for each Forward Collision Warning (FCW) triggered by the OBU. The corresponding WarningEventData records shall represent the before, during, and after data of the warning event. rvBSM shall be populated. vruPSM shall be omitted. warningWWE Log a set of WarningEventData entries for each Wrong-Way Entry warning (WWE) triggered by the OBU. The corresponding WarningEventData records shall represent the before, during, and after data of the warning event. rvBSM and vruPSM shall be omitted. warningVTRFTV Log a set of WarningEventData entries for each Vehicle Turning Right in Front of Transit Vehicle warning (VTRFTV) triggered by the OBU. The corresponding WarningEventData records shall represent the before, during, and after data of the warning event. rvBSM shall be populated. vruPSM shall be omitted. warningPCW Log a set of WarningEventData entries for each Pedestrian Collision Warning (PCW) triggered by the OBU. The corresponding WarningEventData records shall represent the before, during, and after data of the warning event. rvBSM shall be omitted. vruPSM shall be populated. warningEEBL Log a set of WarningEventData entries for each Electronic Emergency Brake Light (EEBL) warning triggered by the OBU. The corresponding WarningEventData records shall represent the before, during, and after data of the warning event. rvBSM shall be populated. vruPSM shall be omitted. warningIMA Log a set of WarningEventData entries for each Intersection Movement Assist warning (IMA) triggered by the OBU. The corresponding WarningEventData records shall represent the before, during, and after data of the warning event. rvBSM shall be populated. vruPSM shall be omitted. warningRLV Log a set of WarningEventData entries for each Red-Light Violation warning (WWE) triggered by the OBU. The corresponding WarningEventData records shall represent the before, during, and after data of the warning event. rvBSM and vruPSM shall be omitted.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |130
14.4 Appendix D: Non-CV Datasets Metadata and Dictionary 14.4.1 Bluetooth Data
14.4.1.1 Data Source To collect travel data before the CV Pilot Deployment, the Tampa-Hillsborough Expressway Authority contracted TrafficCast International, Inc. to install Bluetooth readers (i.e., BlueTOADs) in the CV Pilot study area. Bluetooth readers generate travel time data collected from pre-defined road segments and output can be manually downloaded from the secured website. Ten (10) Bluetooth-enabled devices have been installed in the study area. Figure 14-10 shows the geographical locations of the BlueTOADs.
Figure 14-9 BlueTOAD Readers Within THEA CV Pilot Study Area Source: CUTR
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |131
14.4.1.2 Bluetooth-Enabled Device Location and Pairs Table 14-11 shows the pre-defined BlueTOAD pairs to generate baseline travel time data consistent with the mobility performance evaluation detailed in the Performance Measurement Evaluation Support Plan. For example, BlueTOAD pair 1-3 collect data from Bluetooth equipped vehicles passing between BlueTOAD 1 and BlueTOAD 3 to estimate travel times between the Reversible Express Lanes (REL) system curve and the intersection at Cass and Nebraska Avenue. Table 14-11 Pre-defined Bluetooth Pairs BlueTOAD Pair ID Pair From To Distance Direction TEA-73295 1 - 3 REL North of Twiggs Cass @ Nebraska 0.42 S/W TEA-73299 1 - 6 REL North of Twiggs Kennedy @ Nebraska 0.38 S TEA-73303 1 - 7 REL North of Twiggs Meridian @ Channelside 0.80 S TEA-57887 1 - 5 REL North of Twiggs Kennedy @ Meridian 0.33 S TEA-57885 1 - 4 REL North of Twiggs Twiggs @ Nebraska 0.32 SW TEA-73306 3 - 1 Cass @ Nebraska REL North of Twiggs 0.42 E/N TEA-57875 3 - 4 Cass @ Nebraska Twiggs @ Nebraska 0.11 S TEA-57871 4 - 6 Twiggs @ Nebraska Kennedy @ Nebraska 0.11 S TEA-57873 4 - 3 Twiggs @ Nebraska Cass @ Nebraska 0.11 N TEA-73310 4 - 1 Twiggs @ Nebraska REL North of Twiggs 0.32 NE TEA-57865 4 - 8 Twiggs @ Nebraska Twiggs @ Jefferson 0.26 E TEA-73313 5 - 9 Kennedy @ Meridian Florida @ Kennedy 0.49 W TEA-57863 5 - 7 Kennedy @ Meridian Meridian @ Channelside 0.47 S TEA-73315 5 - 1 Kennedy @ Meridian REL North of Twiggs 0.33 N TEA-57859 5 - 6 Kennedy @ Meridian Kennedy @ Nebraska 0.08 W TEA-57861 7 - 5 Meridian @ Channelside Kennedy @ Meridian 0.47 N TEA-73317 7 - 1 Meridian @ Channelside REL North of Twiggs 0.92 N TEA-57867 8 - 4 Twiggs @ Jefferson Twiggs @ Nebraska 0.22 E TEA-57855 9 - 10 Florida @ Kennedy Cass @ N. Florida 0.27 N
14.4.1.3 Data Upload to SDC Data will be uploaded to the SDC in two comma-separated values files reporting travel times (filename: Bluetooth_RAW_month_day_year.csv) and travel time reliability measures (Bluetooth_TTR_month_day_year.csv). Table 14-12 shows the data dictionary for the Bluetooth data.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |132
Table 14-12 Bluetooth Data Dictionary Field name Description Unit Pair IDs are the unique IDs of PairID pre-defined route pairs. Pairs are defined in Table 14-11 Day of weeks should be one of the following DOW items: Sunday, Monday, Tuesday, Wednesday, Names of the day of week Thursday, Friday, Saturday The timestamp of collected Timestamp travel time Travel time Travel time collected from pairs Seconds Speed is calculated by travel Speed time divided by route pair length Miles Per Hour Travel Time Reliability Travel time reliability measures See Table 14-14
14.4.1.4 Bluetooth-Based Travel Time The MAC addresses are used to calculate the travel time of a vehicle between two BlueTOAD units. This time is reported in seconds, as shown in Table 14-13. Table 14-13 Bluetooth-based Sample Travel Time Speed PairID DOW Timestamp Travel time (sec) (mph) TEA-73295 Wednesday 1/10/2018 8:55:00 32 34.9 TEA-73295 Wednesday 1/10/2018 8:55:00 51 21.9 TEA-73295 Wednesday 1/10/2018 8:55:00 33 33.8 TEA-73295 Wednesday 1/10/2018 8:56:00 16 69.8 TEA-73295 Wednesday 1/10/2018 8:56:00 30 37.2 TEA-73295 Wednesday 1/10/2018 8:57:00 6 186 TEA-73295 Wednesday 1/10/2018 8:57:00 102 10.9 TEA-73295 Wednesday 1/10/2018 8:59:00 122 9.1 TEA-73295 Wednesday 1/10/2018 9:00:00 76 14.7
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |133
14.4.1.5 Bluetooth-Based Travel Time Reliability Travel time reliability is generally defined as a function of time of day (TOD), day of week (DOW), and segment of interest. TOD can be subdivided into 1-hour, 30-minutes, or 15-minutes intervals. The default reporting to SDC is at the 15-minute interval (i.e., TimeInterval = 315). The travel time reliability metrics are detailed in Table 14-14, and a sample of the data is shown in Table 14-15. Table 14-14 Field Description Field name Description Data type Unit PairID Pair IDs are the unique IDs of pre-defined string route pairs. Pairs are defined in Table 14- 13 DOW Names of the day of week string Day of the week should be one of the following items: Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday Time of day String In 15-minute intervals Sample size Travel time data size used for calculating numeric travel time reliability Standard numeric Minutes deviation Coefficient of Standard deviation divided by average numeric variation travel time Mean Travel Average travel time numeric Minutes Time 95th percentile 95th percentile travel time numeric Minutes Buffer time The buffer index represents the extra time numeric Minutes index (or time cushion) that travelers must add to their average travel time when planning trips to ensure on-time arrival Planning time The planning time index represents how numeric Minutes index much total time a traveler should allow to ensure on-time arrival. While the buffer index shows the additional travel time that is necessary, the planning time index shows the total travel time that is necessary
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |134
Table 14-15-1 Travel Time Reliability Sample Data PairID DOW Time of Sample Standard Coefficient Mean 95th Buffer Planning day size deviation of Percentile time time variation index index
TEA- Tuesday 6/25/2019 5 0.26 0.30 0.88 1.09 0.23 1.88 57855 7:00 TEA- Tuesday 6/25/2019 11 0.16 0.27 0.59 0.83 0.39 1.44 57855 7:30 TEA- Tuesday 6/25/2019 18 0.06 0.09 0.69 0.78 0.13 1.35 57855 8:00 TEA- Tuesday 6/25/2019 4 0.05 0.07 0.70 0.74 0.05 1.29 57855 8:15 TEA- Tuesday 6/25/2019 5 0.06 0.08 0.70 0.76 0.09 1.32 57855 8:30 TEA- Tuesday 6/25/2019 15 0.06 0.08 0.76 0.83 0.09 1.44 57855 8:45 TEA- Tuesday 6/25/2019 25 0.07 0.13 0.57 0.67 0.18 1.16 57855 9:00 TEA- Tuesday 6/25/2019 28 0.08 0.16 0.53 0.67 0.25 1.16 57855 9:15 TEA- Tuesday 6/25/2019 2 0.04 0.09 0.48 0.51 0.06 0.88 57855 9:30 TEA- Tuesday 6/25/2019 11 0.07 0.14 0.53 0.64 0.19 1.10 57855 9:45
14.4.2 Transit Data
14.4.2.1 Data Source The Hillsborough Area Regional Transit Authority (HART) manages regional transit operations and provides transit bus operation data in General Transit Feed Specification (GTFS) format through a dedicated application programming interface (API).8
Transit Route Data
Python scripts have been developed to automatically download the GTFS data, including vehicle and trip information. Data are provided for the selected transit routes identified for CV Pilot Deployment:
• Route 20X: Pasco/Lutz Express • Route 24LX: FishHawk/South Tampa Limited Express • Route 25LX: Bloomingdale/South Tampa Limited Express 14.4.2.2 Data Upload to SDC Table 14-16 provides the data dictionary, and Table 14-17 shows a sample of data collected for each route and uploaded to the SDC in comma-separated value format.
8 http://www.gohart.org/Pages/Travel-HART-AppCenter.aspx U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |135
For each distinct trip in the selected routes, the nearest observed coordinates (near_stop_long and near_stop_lat) and time observation (near_stop_time) for the vehicle on that trip are determined using the minimum absolute linear distance between the vehicle and the bus stops latitude and longitude.
The transit_RAW_data files can be used to estimate various travel reliability measures. The nearest stop latitude, longitude, and time can be used to estimate vehicle travel speed between stops. The difference between the nearest observed coordinate pair stop time (near_stop_time) and the posted scheduled time can be employed to estimate reliability measures.
Table 14-16 Field Description Field Description Data Type trip id Bus trip id float vehicle id Bus vehicle id float stop_code Unique bus-stop id float stop_name Intersection or location nearest to stop string stop_id Stop sequence within route float stop_lat Latitude of unique bus-stop id float stop_long Longitude of unique bus-stop id float sch_time Posted scheduled time of the stop string near_stop_long Nearest observed coordinate to stop_lat & float stop_long near_stop_lat Nearest observed coordinate to stop_lat & float stop_long near_stop_time Nearest observed coordinate pair stop time string
Table 14-17 Transit Sample Data trip_id vehicle_id stop_code stop_name stop_id stop_lat stop_long sch_time near_stop_long near_stop_lat near_stop_time 1425205 1022 3994 First Baptist Church PnR Lutz 2 28.135334 -82.464311 2019-06-25T0 -82.46427155 28.13531303 6/25/2019 6:53 1425205 1022 4319 Florida Av @ Bearss Av 3 28.086998 -82.459693 2019-06-25T0 -82.45959473 28.08455658 6/25/2019 7:05 1425205 1022 6914 Florida Av @ 148th Av 4 28.083748 -82.459672 2019-06-25T0 -82.45959473 28.08455658 6/25/2019 7:05 1425205 1022 624 Florida Av @ Fletcher Av 5 28.0708 -82.459456 NA -82.45950317 28.07078934 6/25/2019 7:08 1425205 1022 6968 Marion Transit Center 6 27.954912 -82.458426 2019-06-25T0 -82.45818329 27.95493698 6/25/2019 7:31 1425205 1022 4241 Marion St @ Cass St 7 27.951651 -82.457858 2019-06-25T0 -82.45780945 27.95154381 6/25/2019 7:34 1425205 1022 3903 Marion St @ Whiting St 9 27.946308 -82.455437 2019-06-25T0 -82.4563446 27.94826698 6/25/2019 7:40 1425205 1022 7588 Dale Mabry Hwy @ Pinewood St 10 27.868765 -82.506501 2019-06-25T0 -82.5066452 27.86727333 6/25/2019 7:51 1425205 1022 7691 Great Egret Ave Hospital/Clinic 11 27.859456 -82.500051 2019-06-25T0 -82.49707794 27.86092949 6/25/2019 7:54 1425205 1022 7712 Zemke Ave @ MacDill Ave 12 27.8611 -82.492376 NA -82.49252319 27.8611927 6/25/2019 7:55 1425205 1022 6832 Zemke Ave @ Boundary Blvd 13 27.860376 -82.489898 NA -82.49252319 27.8611927 6/25/2019 7:55 1425205 1022 6963 Florida Keys Av @ Cypress Stand S 15 27.852641 -82.486202 NA -82.48308563 27.85609436 6/25/2019 7:59 1425206 1969 3994 First Baptist Church PnR Lutz 2 28.135334 -82.464311 2019-06-25T0 -82.46337891 28.13606644 6/25/2019 6:08 1425206 1969 4319 Florida Av @ Bearss Av 3 28.086998 -82.459693 2019-06-25T0 -82.45978546 28.08935928 6/25/2019 6:20 1425206 1969 6914 Florida Av @ 148th Av 4 28.083748 -82.459672 NA -82.45969391 28.08519554 6/25/2019 6:23 1425206 1969 624 Florida Av @ Fletcher Av 5 28.0708 -82.459456 2019-06-25T0 -82.45944977 28.07124901 6/25/2019 6:24 1425206 1969 6968 Marion Transit Center 6 27.954912 -82.458426 2019-06-25T0 -82.45801544 27.95208549 6/25/2019 6:45 1425206 1969 3903 Marion St @ Whiting St 9 27.946308 -82.455437 NA -82.45548248 27.94597244 6/25/2019 6:50 1425206 1969 7588 Dale Mabry Hwy @ Pinewood St 10 27.868765 -82.506501 2019-06-25T0 -82.50647736 27.87107468 6/25/2019 7:08 1425206 1969 7691 Great Egret Ave Hospital/Clinic 11 27.859456 -82.500051 2019-06-25T0 -82.49866486 27.86089706 6/25/2019 7:13
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |136
14.4.3 Weather Data
14.4.3.1 Data Source Weather data comes from World Weather Online, which provides national weather broadcast services and downloadable data via its DarkSky API. It is an online service that provides national weather broadcast services.9
14.4.3.2 Weather Information Weather data are collected at 10-minute intervals describing humidity, visibility, and other conditions as detailed in Table 14-18. Data come from one weather station located at the University of Tampa, which is located close to the Tampa CBD. Weather data can be used to control for confounding factors affecting travel conditions in the study area by linking the timestamp field with the timestamp field in BSM Part I. Table 14-18 Weather Data Dictionary Field Description Data type city Location (city) string state Location (state) string zip Zip code string obs_city Weather observation location (city) string obs_state Weather observation location (state) string obs_longitude Weather observation (longitude) numeric obs_latitude Weather observation (longitude) numeric obs_elevation Weather sensor location (elevation) numeric nearest-station Weather sensor ID string timestamp Time of weather information collection datetime temp_F Temperature in Fahrenheit numeric humidity Relative humidity between 0 and 1, inclusive numeric visibility The average visibility in miles capped at 10 miles numeric cloud_cover The percentage of sky occluded by clouds, between 0 and 1, inclusive numeric dewpoint_F The dew point in degrees Fahrenheit numeric precip_intensity The intensity (in inches of liquid water per hour) of precipitation occurring numeric at the given time. This value is conditional on probability wind_bearing The direction that the wind is coming from in degrees, with true north at 0° numeric and progressing clockwise wind_gust Gust speed (mph) numeric wind_speed Wind speed (mph) numeric storm_bearing The approximate direction of the nearest storm in degrees, with true north numeric at 0° and progressing clockwise storm_distance The approximate distance to the nearest storm in miles. numeric pressure The sea-level air pressure (bars) numeric ozone The columnar density of total atmospheric ozone at the given time numeric uv_index The UV index numeric
9 https://www.worldweatheronline.com/lang/en-us/ U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |137
14.4.3.3 Data Upload to SDC The data will be uploaded to the SDC via a CSV file, as shown in the sample file of Table 14-19 and Table 14-20.
Table 14-19 Weather Sample Data-Part 1 timestamp datetime temp humidity visibility cloud_ dewpoint precip_ _F cover _F intensity 1550689650 2/20/2019 14:07 84.77 0.56 10 0.8 67.53 0 1550693828 2/20/2019 15:17 84.84 0.55 10 0.73 66.91 0 1550694601 2/20/2019 15:30 84.65 0.55 10 0.73 66.85 0 1550695201 2/20/2019 15:40 84.51 0.55 10 0.73 66.8 0 1550695801 2/20/2019 15:50 84.02 0.57 9.36 0.52 67.11 0 1550696401 2/20/2019 16:00 83.86 0.57 9.23 0.52 67.14 0.04 1550697001 2/20/2019 16:10 83.54 0.58 9.22 0.52 67.17 0 1550697601 2/20/2019 16:20 82.88 0.59 9.21 0.53 67.24 0 1550698201 2/20/2019 16:30 82.53 0.6 9.19 0.53 67.26 0 1550698801 2/20/2019 16:40 82.26 0.6 9.95 0.55 67.2 0.03
Table 14-20 Weather Sample Data-Part 2 timestamp wind_ wind_ wind_ storm_ storm_ pressure ozone uv_ bearing gust speed bearing distance index 1550689650 191 14.41 12.69 355 24 1018.33 223.19 5 1550693828 203 15.21 11.64 169 21 1017.54 222.94 4 1550694601 205 15.47 11.65 168 13 1017.55 222.9 3 1550695201 206 15.68 11.66 178 14 1017.55 222.87 3 1550695801 215 14.74 12.27 272 27 1017.31 222.84 3 1550696401 216 15.13 12.38 0 0 1017.4 222.81 3 1550697001 216 15.26 12.25 285 27 1017.34 222.78 2 1550697601 216 14.82 11.98 214 24 1017.25 222.76 2 1550698201 217 14.94 11.86 144 6 1017.19 222.73 2 1550698801 224 15.95 12.47 120 6 1017.19 222.73 2
14.4.4 Event Logs
14.4.4.1 Data Source Road closure and event information will be collected from the City of Tampa (CoT) Traffic Monitoring Center to collect data on events scheduled inside the CBD. The City has a public calendar for all events scheduled within it limits, and a specific news feed for road closures for different reasons including construction, weather, and special events. (https://www.tampagov.net/news- transportation-advisories-road-closures ). Figure 14-11 shows an example of current road closures website, and Figure 14-12 shows the RSS feed that provides the information. Table 14-21 shows a sample of such data in CSV.
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |138
Figure 14-10 City of Tampa Advisories and Road Closures Website Source: CoT
Figure 14-11 RSS Feed Providing Information for Events and Road Closures Source: CoT
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |139
Table 14-21 Sample Data
pubDate Title Type Location Date Time Wed, 26 Dec Temporary Lane Road Closure S West Shore 1/7/19 9:00 2018 Closure: S West Boulevard A.M.- 15:46:34 Shore Blvd between 4:00 between Melrose Melrose P.M . Avenue and Avenue and Clear Avenue Clear Avenue Wed, 2 Jan 2019 Black Heritage Special Event Curtis Hixon 1/19/19 11:00 09:11:15 Festival Waterfront Park A.M.- 8:00 P.M .
14.4.4.2 Data Upload to SDC The SDC will receive one comma-separated values file reporting the relevant information for events and road closures (filename: events_log.csv) as detailed in Table 14-22. Table 14-22 Event Log Data Dictionary Field name Description pubDate This is the date the event or road closure was published Title Title of the special event or road closure provided by the feed Type Type of event: Special event or road closure Location Location of the event or road closure Date Date of the event or road closure Time Time the event or road closure will take place
U.S. Department of Transportation Intelligent Transportation System Joint Program Office
CV Pilot Deployment Program Phase 2, Performance Measurement and Evaluation Support Plan - Update |140
U.S. Department of Transportation ITS Joint Program Office-HOIT 1200 New Jersey Ave., SE Washington, DC 20590
Toll-Free “Help Line” 866-367-7487 www.its.dot.gov
FHWA-JPO-16-314