UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Safety evaluation of connected vehicle applications using micro-simulation Fyfe, Martin R. W. 2016

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
24-ubc_2017_february_fyfe_martin.pdf [ 3.81MB ]
Metadata
JSON: 24-1.0340300.json
JSON-LD: 24-1.0340300-ld.json
RDF/XML (Pretty): 24-1.0340300-rdf.xml
RDF/JSON: 24-1.0340300-rdf.json
Turtle: 24-1.0340300-turtle.txt
N-Triples: 24-1.0340300-rdf-ntriples.txt
Original Record: 24-1.0340300-source.json
Full Text
24-1.0340300-fulltext.txt
Citation
24-1.0340300.ris

Full Text

Safety Evaluation of Connected Vehicle Applications UsingMicro-SimulationbyMartin R. W. FyfeB. Sc., University of Victoria, 2008A THESIS SUBMITTED IN PARTIAL FULFILLMENTOF THE REQUIREMENTS FOR THE DEGREE OFMaster of Applied ScienceinTHE FACULTY OF GRADUATE AND POSTDOCTORAL STUDIES(Civil Engineering)The University of British Columbia(Vancouver)December 2016c©Martin R. W. Fyfe, 2016AbstractConnected vehicles are on the cutting edge of automotive technology with applications expected toimprove mobility and safety. Several studies have evaluated the mobility benefits of connected ve-hicle technology but there is little research on its impact on safety. The first objective of this studyis to investigate the ability to evaluate the safety of a connected vehicle applications using surrogatesafety measures through a combination of the micro-simulation model VISSIM and the SurrogateSafety Assessment Model (SSAM). Two connected vehicle applications are reviewed, consideringtwo types of connected vehicle communications, specifically Vehicle-to-Vehicle and Vehicle-to-Infrastructure. The two applications are a cumulative travel time (CTT) intersection control algo-rithm connected vehicle environment, and a cooperative adaptive cruise control (CACC) applica-tion, facilitating vehicle platooning on a freeway. The CACC study investigates the improvementto the freeway segment through a simulated incident. The CTT study investigates the impactsof calibrating the micro-simulation model using real-world vehicle trajectory and conflict data.The CTT algorithm is applied to a signalized intersection and evaluated under three calibrationscenarios: uncalibrated, first step calibrated for desired speed and vehicle arrival types, and sec-ond step calibrated for conflicts observed in the field. In both studies, a comparison of safetybased on the number of conflicts at different time-to-collision thresholds is provided for the vary-ing scenarios. Results show that the combination of VISSIM and SSAM provide an appropriatetool to use in the evaluation of changes in the level of safety of connected vehicle applications,specifically the CACC application and the CTT intersection control application. Calibration of theiimicro-simulation model has a significant impact on the results of the safety evaluation. However,it is inconclusive whether the results are realistic with the lack of a real-world connected vehicleimplementation.iiiPrefaceThis thesis is an original intellectual product of the author, M. Fyfe. The methods used expandon work conducted in the Transportation group at the University of British Columbia departmentof Civil Engineering. The non-connected micro-simulation model used for the cumulative traveltime intersection control connected vehicle application in Section 4.1 and Section 5.1 is based onresearch by Essa and Sayed (2015a). Assumptions used for the micro-simulation models are basedon research by Essa and Sayed (2015a), Lee et al. (2013a) and Zhao and Sun (2013).I completed this thesis while employed at the Transportation Investment Corporation. The viewsand opinions within this thesis are my own and do not necessarily reflect the opinions of myemployer. No special considerations were made in the interest of my employer.ivTable of ContentsAbstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iiPreface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ivTable of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vList of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixList of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiGlossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvAcknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.1.1 Traffic Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.1.2 Connected Vehicles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.1.3 Micro-simulation and VISSIM . . . . . . . . . . . . . . . . . . . . . . . . 41.1.4 The Surrogate Safety Assessment Model . . . . . . . . . . . . . . . . . . . 51.1.5 Traffic Conflict Technique . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2 Research Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6v1.3 Thesis Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Literature Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1 Traditional Road Traffic Safety Research . . . . . . . . . . . . . . . . . . . . . . . 102.1.1 Traditional Road Traffic Safety Analysis . . . . . . . . . . . . . . . . . . . 112.2 Traffic Conflict Technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.1 Traffic Conflict Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.2 Challenges to the Traffic Conflict Technique . . . . . . . . . . . . . . . . . 162.2.3 Computer Vision Techniques for Conflict Analysis . . . . . . . . . . . . . 172.3 Intelligent Transportation Systems . . . . . . . . . . . . . . . . . . . . . . . . . . 182.3.1 In-Vehicle Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.3.2 Safety and Behavioural Adaptation . . . . . . . . . . . . . . . . . . . . . . 192.3.3 Connected and Autonomous Vehicles . . . . . . . . . . . . . . . . . . . . 212.4 The VISSIM Micro-Simulation Model and SSAM . . . . . . . . . . . . . . . . . . 242.5 Evaluation of Connected Vehicle Applications Using Micro-Simulation . . . . . . 283 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.1.1 VISSIM Simulation Parameter Modification . . . . . . . . . . . . . . . . . 343.1.2 The VISSIM COM Interface . . . . . . . . . . . . . . . . . . . . . . . . . 343.1.3 The Driver Behaviour DLL . . . . . . . . . . . . . . . . . . . . . . . . . . 353.2 Framework for Developing Connected Vehicle Environments within VISSIM . . . 363.2.1 Identify Connected Vehicle Application . . . . . . . . . . . . . . . . . . . 363.2.2 Identify Connected Vehicle Technology . . . . . . . . . . . . . . . . . . . 373.2.3 Determine Changes Within VISSIM . . . . . . . . . . . . . . . . . . . . . 373.2.4 Identify Tool to Perform the Changes Within VISSIM . . . . . . . . . . . . 37vi3.2.5 Apply Changes Through Appropriate Tool . . . . . . . . . . . . . . . . . . 393.2.6 Evaluation Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.2.7 Run the Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.2.8 Evaluate the Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.3 CTT Intersection Control Methodology . . . . . . . . . . . . . . . . . . . . . . . 413.4 CACC Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434 Connected Vehicle Simulations Without Calibration . . . . . . . . . . . . . . . . . . 454.1 Cumulative Travel Time Intersection Control . . . . . . . . . . . . . . . . . . . . . 454.1.1 CTT MATLAB Implementation . . . . . . . . . . . . . . . . . . . . . . . 474.1.2 CTT Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.1.3 CTT Data Collection and Analysis . . . . . . . . . . . . . . . . . . . . . . 514.1.4 Evaluation of Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.2 Cooperative Adaptive Cruise Control . . . . . . . . . . . . . . . . . . . . . . . . . 564.2.1 Simulation Development . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.2.2 Driving States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.2.3 CACC Driver Behaviour Algorithms . . . . . . . . . . . . . . . . . . . . . 604.2.4 CACC Data Collection and Analysis . . . . . . . . . . . . . . . . . . . . . 614.2.5 Evaluation of Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.2.6 Micro-Simulation Sensitivity Analysis . . . . . . . . . . . . . . . . . . . . 684.2.7 Sensitivity Analysis Evaluation . . . . . . . . . . . . . . . . . . . . . . . . 755 Calibrated Connected Vehicle Simulations . . . . . . . . . . . . . . . . . . . . . . . 775.1 Cumulative Travel Time Intersection Control . . . . . . . . . . . . . . . . . . . . . 785.1.1 Intersection First Step Calibration . . . . . . . . . . . . . . . . . . . . . . 785.1.2 Intersection Second Step Calibration . . . . . . . . . . . . . . . . . . . . . 79vii5.1.3 Automated Video-Based Computer Vision Analysis . . . . . . . . . . . . . 805.1.4 CTT Data Collection and Analysis . . . . . . . . . . . . . . . . . . . . . . 805.1.5 CTT Comparison with Lower Intersection Volume . . . . . . . . . . . . . 885.1.6 Evaluation of Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916 Summary, Conclusion and Future Research . . . . . . . . . . . . . . . . . . . . . . . 956.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966.2.1 CACC Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 976.2.2 CTT Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986.3 Future Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006.3.1 CACC Future Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006.3.2 CTT Future Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102A Cumulative Travel Time Intersection Control Background Code . . . . . . . . . . . 108A.1 MATLAB Code for Micro-Simulation . . . . . . . . . . . . . . . . . . . . . . . . 108A.2 MATLAB Code for Cumulative Travel Time Calculation . . . . . . . . . . . . . . 111B Cooperative Adaptive Cruise Control Background Code . . . . . . . . . . . . . . . . 113B.1 C++ DLL CACC Driver Behaviour Model . . . . . . . . . . . . . . . . . . . . . . 113B.2 C++ DLL ACC Driver Behaviour Model . . . . . . . . . . . . . . . . . . . . . . . 120viiiList of TablesTable 4.1 Signal Timing Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Table 4.2 CTTs to Demonstrate Signal Timing Change . . . . . . . . . . . . . . . . . . . 50Table 4.3 Travel times at varying connected vehicle market penetration levels for the un-calibrated micro-simulation model after implementing the CTT algorithm . . . . 51Table 4.4 Travel time improvements at varying connected vehicle market penetration lev-els for the uncalibrated micro-simulation model compared with the no-CTTmicro-simulation after implementing the CTT algorithm . . . . . . . . . . . . . 51Table 4.5 Time-to-Collision Conflicts at varying connected vehicle market penetrationlevels for the uncalibrated micro-simulation model after implementing the CTTalgorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Table 4.6 Time-to-Collision Conflicts at varying connected vehicle market penetrationlevels for the uncalibrated micro-simulation model compared with the no-CTTmicro-simulation after implementing the CTT algorithm (negative percent changeindicates improvement) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Table 4.7 CACC Simulation Input Connected Vehicle Penetrations . . . . . . . . . . . . . 62Table 4.8 Travel times per connected vehicle market penetration level . . . . . . . . . . . 63Table 4.9 Percent change in travel times per connected vehicle market penetration levelcompared with No CACC micro-simulation . . . . . . . . . . . . . . . . . . . . 65Table 4.10 Rear-end TTC conflicts at varying connected vehicle (CV) penetration levels . . 65Table 4.11 Percent Change to Rear-end TTC conflicts at varying connected vehicle (CV)penetration levels Compared With No CACC . . . . . . . . . . . . . . . . . . . 66Table 4.12 Travel Time Variations Based on Varying CC1 Parameter . . . . . . . . . . . . 70ixTable 4.13 Travel Time Variations Based on Varying CC1 Parameter Value Compared withDefault VISSIM Parameter (Reductions are Improvements) . . . . . . . . . . . 70Table 4.14 Rear-End Conflicts for 0.7s Headway at Varying CACC Penetration Levels . . . 70Table 4.15 Rear-End Conflicts for 0.7s Headway Compared with Default VISSIM Parameter 71Table 4.16 Rear-End Conflicts for 1.1s Headway at Varying CACC Penetration Levels . . . 71Table 4.17 Rear-End Conflicts for 1.1s Headway Compared with Default VISSIM Parameter 71Table 4.18 Rear-End Conflicts for 1.3s Headway at Varying CACC Penetration Levels . . . 71Table 4.19 Rear-End Conflicts for 1.3s Headway Compared with Default VISSIM Parameter 71Table 4.20 Rear-End Conflicts for 1.5s Headway at Varying CACC Penetration Levels . . . 72Table 4.21 Rear-End Conflicts for 1.5s Headway Compared with Default VISSIM Parameter 72Table 4.22 Changes to Travel Times and Rear-End Conflicts for CACC Acceleration Pa-rameters at 50% CACC Penetration . . . . . . . . . . . . . . . . . . . . . . . . 75Table 5.1 Default VISSIM Driver Behaviour Parameters . . . . . . . . . . . . . . . . . . 79Table 5.2 Travel times at varying connected vehicle market penetration levels for the firststep calibrated micro-simulation model after implementing the CTT algorithm . 82Table 5.3 Travel times at varying connected vehicle market penetration levels for the sec-ond step calibrated micro-simulation model after implementing the CTT algorithm 82Table 5.4 Travel time improvements at varying connected vehicle market penetration lev-els for the first step calibrated micro-simulation model compared with the no-CTT micro-simulation after implementing the CTT algorithm . . . . . . . . . . 82Table 5.5 Travel time improvements at varying connected vehicle market penetration lev-els for the second step calibrated micro-simulation model compared with theno-CTT micro-simulation after implementing the CTT algorithm . . . . . . . . 84Table 5.6 Time-to-Collision Conflicts at varying connected vehicle market penetrationlevels for the first step calibrated micro-simulation model after implementingthe CTT algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Table 5.7 Time-to-Collision Conflicts at varying connected vehicle market penetrationlevels for the second step calibrated micro-simulation model after implementingthe CTT algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85xTable 5.8 Time-to-Collision Conflicts at varying connected vehicle market penetrationlevels for the first step calibrated micro-simulation model compared with theno-CTT micro-simulation after implementing the CTT algorithm . . . . . . . . 85Table 5.9 Time-to-Collision Conflicts at varying connected vehicle market penetrationlevels for the second step calibrated micro-simulation model compared withthe no-CTT micro-simulation after implementing the CTT algorithm . . . . . . 88Table 5.10 Travel times at varying connected vehicle market penetration levels for the sec-ond step calibrated micro-simulation model after implementing the CTT algo-rithm at a lower intersection volume . . . . . . . . . . . . . . . . . . . . . . . . 88Table 5.11 Travel time improvements at varying connected vehicle market penetration lev-els for the second step calibrated micro-simulation model compared with theno-CTT micro-simulation after implementing the CTT algorithm at lower inter-section volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Table 5.12 Time-to-Collision Conflicts at varying connected vehicle market penetrationlevels for the second step calibrated micro-simulation model after implementingthe CTT algorithm at a lower intersection volume . . . . . . . . . . . . . . . . 90Table 5.13 Time-to-Collision Conflicts at varying connected vehicle market penetrationlevels for the second step calibrated micro-simulation model compared withthe no-CTT micro-simulation after implementing the CTT algorithm at a lowerintersection volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90xiList of FiguresFigure 2.1 FHWA Causes of Road Crashes . . . . . . . . . . . . . . . . . . . . . . . . . 11Figure 2.2 Engineering Effect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Figure 3.1 Intersection and Associated Cameras at 128th and 72nd (Tageldin et al., 2014) 42Figure 4.1 Nema phase numbering scheme for a four approach intersection (Lee et al.,2013a) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Figure 4.2 CTT Demonstration for instance of Signal Change, with circles identifyingthe times at which the signals change due to combination of cumulative traveltimes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Figure 4.3 Travel time improvements at varying connected vehicle market penetration lev-els for the uncalibrated micro-simulation model compared with the no-CTTmicro-simulation after implementing the CTT algorithm . . . . . . . . . . . . 52Figure 4.4 Rear-end Conflicts for the uncalibrated micro-simulation model at varying con-nected vehicle penetration levels . . . . . . . . . . . . . . . . . . . . . . . . . 52Figure 4.5 Rear-end Conflicts for the uncalibrated micro-simulation model at varying con-nected vehicle penetration levels compared with no-CTT algorithm applied(negative percent change indicates improvement) . . . . . . . . . . . . . . . . 54Figure 4.6 Example of vehicle platooning micro-simulation including vehicle colours . . 58Figure 4.7 Average Travel Times Per CACC Market Penetration Level and Vehicle Type . 63Figure 4.8 Percent Change in Travel Times Per CACC Market Penetration Level Com-pared with The Average Travel Time for No CACC . . . . . . . . . . . . . . . 64Figure 4.9 Rear-End conflicts by time-to-collision threshold . . . . . . . . . . . . . . . . 64xiiFigure 4.10 Percent Change in Rear-End Conflicts by TTC Threshold for varying CACCMarket Penetration Level Compared with No CACC (negative percentage in-dicates improvement) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Figure 4.11 Percent Change in Rear-End Conflicts by TTC Threshold for varying CACCMarket Penetration Level at a 0.7s Headway Compared with Default VISSIMHeadway Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Figure 4.12 Percent Change in Rear-End Conflicts by TTC Threshold for varying CACCMarket Penetration Level at a 1.1s Headway Compared with Default VISSIMHeadway Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Figure 4.13 Percent Change in Rear-End Conflicts by TTC Threshold for varying CACCMarket Penetration Level at a 1.3s Headway Compared with Default VISSIMHeadway Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Figure 4.14 Percent Change in Rear-End Conflicts by TTC Threshold for varying CACCMarket Penetration Level at a 1.5s Headway Compared with Default VISSIMHeadway Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Figure 5.1 Process outlining computer vision methodology for automated video analysis(Tageldin et al., 2014) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Figure 5.2 Heat maps of calibration data set using Computer Vision and simulated con-flicts used for calibration (Essa and Sayed, 2015a) . . . . . . . . . . . . . . . 81Figure 5.3 Travel time improvements at varying connected vehicle market penetration lev-els for the first step calibrated micro-simulation model compared with the no-CTT micro-simulation after implementing the CTT algorithm . . . . . . . . . 83Figure 5.4 Travel time improvements at varying connected vehicle market penetration lev-els for the second step calibrated micro-simulation model compared with theno-CTT micro-simulation after implementing the CTT algorithm . . . . . . . . 83Figure 5.5 Rear-end Conflicts for the first step calibrated micro-simulation model at vary-ing connected vehicle penetration levels . . . . . . . . . . . . . . . . . . . . . 86Figure 5.6 Rear-end Conflicts for the second step calibrated micro-simulation model atvarying connected vehicle penetration levels . . . . . . . . . . . . . . . . . . 86Figure 5.7 Rear-end conflicts improvements for the first step calibrated micro-simulationmodel at varying connected vehicle penetration levels compared with no-CTTalgorithm applied . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87xiiiFigure 5.8 Rear-end conflicts improvements for the second step calibrated micro-simulationmodel at varying connected vehicle penetration levels compared with no-CTTalgorithm applied . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Figure 5.9 Travel time improvements at varying connected vehicle market penetration lev-els for the second step calibrated micro-simulation model compared with theno-CTT micro-simulation after implementing the CTT algorithm at lower in-tersection volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Figure 5.10 Rear-end Conflicts for the second step calibrated micro-simulation model atvarying connected vehicle penetration levels at a lower intersection volume . . 89Figure 5.11 Rear-end Conflicts for the second step calibrated micro-simulation model atvarying connected vehicle penetration levels compared with no-CTT algorithmapplied at a lower intersection volume . . . . . . . . . . . . . . . . . . . . . . 91xivGlossaryABS Anti-lock Brake SystemACC Adaptive Cruise ControlATMS Advanced Traffic Management SystemBSM Basic Safety MessageCACC Cooperative Adaptive Cruise ControlCOM Component Object ModelCTT Cumulative Travel TimesDLL Dynamic Linked LibraryDMS Dynamic Message SignDR Deceleration RateDSRC Dedicated Short-Range CommunicationsESC Electronic Stability ControlFHWA Federal Highways AdministrationGPS Global Positioning SystemIEEE Institute for Electrical and Electronics EngineersITS Intelligent Transportation SystemsLOS Level-of-ServiceMAPE Mean Absolute Percent ErrorORCI Overall Risk Change IndexPET Post-Encroachment TimeSAE Society of Automotive EngineersSSAM Surrogate Safety Assessment ModelTTC Time to CollisionUSDOT United States Department of TransportationVANET Vehicular Ad-Hoc NetworksVPH Vehicles per HourV2V Vehicle to VehicleV2I Vehicle to InfrastructureV2X Vehicle to XxvAcknowledgmentsI would like to thank my advisor and academic mentor, Dr. Tarek Sayed, for his encouragement,support and trust in my abilities to complete this thesis. Also, thank you to my fellow graduatestudents who provided valuable conversation and discussion about research and other interestingwork being conducted at UBC. I would like to thank the Transportation Investment Corporation forsupporting me in my interests and endeavours to further my education. I would also like to thankmy parents for their encouragement in my education and career in transportation. And last but notleast I would like to thank my wife and son for their love, encouragement, support, dedication andsacrifice while I completed this work.xviChapter 1IntroductionWithin transportation engineering, the primary focus in the design of any transportation facility orsystem is the impact to the safety of the travelling public and other road users while improvingthe mobility for these same users. Given the high number of vehicle crashes each year, safetyremains at the forefront of critical research items for transportation engineering. The World HealthOrganization (2013) has stated that road collisions are the eighth leading cause of death worldwideand has reported there are approximately 1.24 million deaths and another 20-50 million non-fatalinjuries on roads around the world annually.Connected vehicles have a potential to improve transportation systems with respect to safety, mo-bility and sustainability; however, significant research and review of these new facilities needs tooccur before there can be confidence that these systems will in fact demonstrate improvements inthese areas.Before new road designs or technologies, and applications of those technologies are implementedit is difficult to know how the transportation network will react. Traffic simulation assists bysimulating what will occur on a roadway given different variables and factors. The primary types ofsimulations used in traffic modelling are macro-simulation, meso-simulation and micro-simulation.1Microscopic simulation (micro-simulation) involves modelling each individual vehicle, includingdriver behaviour, and is the type of simulation to be used for this thesis. Of the different micro-simulation software packages available, the package being used for this research is PTV VISSIM.This chapter includes three sections. The first section provides background information on trafficsafety, connected vehicles, the traffic conflict technique, micro-simulation and the Surrogate SafetyAssessment Model (SSAM). The second section describes the research objectives of this thesis.The third section defines the thesis structure.1.1 BackgroundTransportation safety carries a significant consideration when designing or implementing changesto existing or new transportation facilities. Within transportation engineering, there are three mainfactors when understanding the cause of a collision on a roadway: 1) the driver, 2) the vehicle, and3) the road environment. The primary cause of collisions include driver fault (Lum and Reagan,1995).Within transportation infrastructure, there are limitations to what can be built due to right-of-way and allowable road space, as well as consideration for the joining roadways. Building morelanes to increase capacity is not always a possibility considering it may take years to build newinfrastructure. Alternative methods of improving the capacity of roadways are needed.To make the transportation system safer, transportation practitioners should be able to estimate theimpacts of a change in design to an existing facility or the creation of a new facility within anexisting network. Some components of traffic safety analysis are the identification of hazardouslocations (through black spot programs), analyzing and verifying countermeasures, and, the focusof this thesis, improving road user behaviour.21.1.1 Traffic SafetyThe terms incident, accident, collision and crash are often used interchangeably when referring totraffic safety. Years of research have shown that crashes can be predicted to an extent and that theycan be modelled through the use of statistical analysis (Sayed and De Leur, 2008). For this thesisthe terms collision and crash will be used, and the term accident will be avoided as it suggests thatthe instance was random and unforeseen.1.1.1.1 Importance of Road Safety ResearchRoads are a critical part of a transportation network and they are essential to the development ofa country. Roads allow for the movement of people and goods by supporting automobiles, trucks,buses, bicycles and pedestrians. Without roads there would be no ability to transport resources tobuild infrastructure for the development of regional or economic growth.Road safety research is important because it helps to enhance the knowledge of road safety. Toimprove the safety on roads, transportation engineers and designers should have the ability tounderstand and evaluate the impacts of different design and operational options on a roadway.Road traffic safety research is a prime component of transportation engineering. Traffic safetyis often looked at in terms of traffic “unsafety”, or the negative of safety, namely the number ofinjuries or fatalities resulting from traffic accidents. Traffic safety has three dimensions: exposure,risk and consequence. Road traffic safety engineering is the practice of reducing the risk of usersof the road being killed or seriously injured as part of a traffic collision.1.1.2 Connected VehiclesConnected vehicles can be considered a new transportation facility. They involve communica-tion between vehicles through Vehicle to Vehicle (V2V) interaction and communication between3vehicles and the infrastructure through Vehicle to Infrastructure (V2I) interaction in order to haveenhanced driving applications on the roadway. The applications are intended to improve the overallmobility, safety and driving experience for individual drivers and for the road network in general.Connected vehicles are a subset of Intelligent Transportation Systems (ITS) and are a method beingreviewed, currently on a limited basis, to evaluate the ability to improve the function on existingtransportation facilities.1.1.3 Micro-simulation and VISSIMPTV VISSIM (VISSIM) is a micro-simulation model created by the German company PTV Vi-sion. VISSIM enables modelling of various types of traffic facilities that exist on a road network,including junction geometry, motorway traffic, public transport, multimodal systems, active traf-fic management and emissions modelling. For motorway traffic, VISSIM allows for modelingon two levels: the driver level, and the tactical level. On the driver level, vehicles abide by thepsycho-physical car following model developed by Professor Rainer Weidemann from the Karl-sruhe Institute of Technology in 1974 and 1999, governing how drivers in the micro-simulationrespond based on distance and difference of speed to the vehicles ahead. The car following modeldeveloped by Wiedemann (the “Wiedemann Mode”) uses random numbers and several stochasticvariations to simulate behaviour of different drivers resulting in virtually no two drivers with ex-actly the same driving behaviour. Additionally lane changing is facilitated through a rule-basedmodel. Both models have parameters that can be adjusted. On a tactical level, where decisionsmust be made far enough in advance in order to take action, VISSIM considers the geometry ofthe roadway and the surrounding vehicles in order to choose the appropriate lane to be travellingin. VISSIM allows for changes to properties such as the willingness to cooperate in order to real-istically map the region specific to actual characteristics. Car2X, or Vehicle to X (V2X) systemscan theoretically be modelled in VISSIM as they have an impact to individual vehicles.41.1.3.1 Calibration of VISSIMWhen developing a simulation, the simulation model needs to incorporate data from the real-worldto ensure it properly represents reality. This process is known as calibration.The calibration of VISSIM is considered one of the most important aspects in preparing a trans-portation network for simulation. Due to minimal literature and processes on calibration, manyresearchers and practitioners are required to use a manual trial-and-error approach for calibrationto re-create situations seen in the real world as opposed to automated computer optimization of themodels (Ge and Menendez, 2012).Research has been conducted recently to demonstrate that it is important to calibrate VISSIM notonly to match existing traffic conditions (e.g., arrival pattern and platoon ratio) but also with respectto safety through calibrating the driver behaviour parameters (Essa and Sayed, 2015a). Safetycalibration of VISSIM can be performed using the SSAM as will be discussed in Section 1.1.4.1.1.4 The Surrogate Safety Assessment ModelThe Surrogate Safety Assessment Model (SSAM) is a software package that analyzes trajecto-ries output from certain micro-simulation packages, namely VISSIM, PARAMICS, AIMSUM andTEXAS, in order to evaluate the road traffic conflicts observed in the simulation. SSAM acts asa post-processor as the micro-simulation models will output a trajectory file (.trj) and SSAM ana-lyzes the vehicle-to-vehicle interactions within the trajectory file to identify conflict situations andto provide a database of all instances found within the model output. Along with conflict detection,SSAM provides surrogate safety measures as an output, as well as the classification of conflict typeas either lane change, rear-end, or path crossing event and the vehicle velocity change if the eventhad proceeded to an incident to provide indication of the severity of the incident.51.1.5 Traffic Conflict TechniqueObserving and analyzing traffic conflicts has been regarded as an alternative method for evaluatingtraffic safety through using the Traffic Conflict Technique (TCT). The TCT is described by Archer(2001) as the most developed indirect method of evaluating traffic safety through registering near-collisions in real-time traffic. Some of the inhibiting factors to widespread use of the TCT are thehigh costs of training observers and the variability or reliability in manual collection of conflict data(Essa, 2015). Traffic conflicts have been used in safety diagnosis as a surrogate for collision dataanalysis as they provide insight into failure mechanisms that lead to road collisions (Amundsenand Hyden, 1977; Sayed and Zein, 1999; Tarko et al., 2009). Traffic conflicts address some of theshortcomings of collision data such as shorter collection time, more frequent occurrences and lesscost to society.1.2 Research ObjectivesSimulating conflicts for road traffic safety evaluation in micro-simulation has been more commonin the recent past (Essa and Sayed, 2015a,b, 2016; Shahdah et al., 2014; Wang and Stamatiadis,2014), specifically using the SSAM. However, concerns have been raised over using simulatedconflicts, primarily for two main reason (Essa, 2015; Saunier and Sayed, 2007). Firstly, because ofthe rules embedded within the micro-simulation models to cause vehicles to avoid collisions, mak-ing it difficult to represent unsafe conditions in the real-world. Secondly, micro-simulation modelshave a multitude of simulation parameters which impact the observed simulated conflicts withinthe model. Through calibration to real-world conditions it has been shown that these concerns canbe addressed (Essa and Sayed, 2015a).While it may be becoming more common to use the SSAM to evaluate safety through micro-simulation models, these evaluations typically involve existing transportation facilities and in-frastructure. Evaluating the safety of a facility that does not exist in the real-world brings new6challenges to the use of surrogate safety measures for safety evaluations.Connected vehicle applications are considered new transportation facilities in that there is not abun-dant information about the reaction of these systems to varying traffic conditions. Research hasbeen conducted into evaluating the mobility and sustainability impacts of connected vehicle appli-cations (Lee et al., 2013a,b; Zhao and Sun, 2013); however, the safety impacts of these facilitiesare rarely evaluated or quantified.Connected vehicle applications can be separated into two categories, 1) where partial vehicle con-trol is assumed by a computer, or 2) where driver behaviour is modified due to changes in theinfrastructure, such as through navigation systems or signalized intersection control. Making useof both of these types of connected vehicle applications, the first objective of this thesis is to assessthe ability for micro-simulation to be used in evaluating the change to safety of connected vehi-cle applications using surrogate safety measures. This will be assessed through comparison to anon-connected vehicle micro-simulation and conformance to expected results.While connected vehicle applications can be modelled using micro-simulations, there are no wide-spread real-world implementations of connected vehicle applications, and therefore there are noreal-world conditions to use to calibrate the micro-simulation model. Calibration is typically per-formed by modifying VISSIM and other parameters in the micro-simulation to emulate real-worldobservations. Given the two types of connected vehicle applications being investigated, modifi-cation of these parameters can be performed to represent calibration and test the sensitivity andsignificance of model behaviour subsequent to the changes being made. Following this, the secondobjective of this thesis is to demonstrate that calibration of a non-connected vehicle environmentthrough modification of VISSIM and other parameters has a significant impact to the simulated ef-fects of connected vehicle applications, for both safety and mobility. This will be assessed throughcomparison of the results after calibration to the non-connected vehicle calibrated micro-simulationand to the overall results of the uncalibrated micro-simulation.71.3 Thesis StructureThis thesis is comprised of six chapters. This chapter presents an introduction and background tothe thesis, the objectives of this research and an outline to the structure of the thesis. Chapter 2provides a comprehensive literature review of the research areas supporting the main objectivesof this thesis. The review is broad in the focus on road traffic safety research, the traffic con-flict technique, Intelligent Transportation Systems, micro-simulation models of connected vehicletechnologies and applications, and the work that has been done using SSAM for evaluating safetywithin a micro-simulation model. Chapter 3 discusses the methodology of modelling connectedvehicle technologies using the VISSIM micro-simulation model and assessing the objectives underthis thesis. Chapter 4 and Chapter 5 implement case studies of connected vehicle applications forthe purpose of evaluating the objectives of this thesis, firstly for the uncalibrated simulations andthen for a more focused view of the calibrated simulation of one of the micro-simulation models.Finally, Chapter 6 contains the summary, conclusion and areas for future research.8Chapter 2Literature ReviewThis chapter outlines previous research in five main areas to provide the state of the art on whichthis research is based. The first area of research is about traditional road traffic safety analysis andthe framework upon which advancements in traffic safety research are based. The second area ofresearch is specific to the traffic conflict technique, outlining advancements in understanding safetyand risk associated with traffic conflicts on roadways, as well as methods used for conducting stud-ies using the traffic conflict technique. The third area of research is on Intelligent TransportationSystems (ITS) and in greater detail, Connected Vehicles and Autonomous Vehicles. The fourtharea of research is specific to micro-simulation models and use of the Surrogate Safety AssessmentModel (SSAM). The fifth area of research is specific to connected vehicles and the research intoevaluation of connected vehicle applications using micro-simulation. Numerous studies have beenfound relating to the traffic conflict technique and traffic micro-simulation; therefore a reduced listof studies is presented specific to key studies that have been highly cited previously.92.1 Traditional Road Traffic Safety ResearchTraditional road traffic safety research analysis focuses on identifying hazardous areas on road-ways, diagnosing safety problems, recommending safety improvement options and evaluating theeconomic feasibility of the safety improvement options. Traditional road traffic safety analysis istypically performed by collecting traffic safety information after collisions have occurred, primar-ily from historical collision reports, police reports and insurance claims (de Leur and Sayed, 2001,2003). Studies have shown there to be shortcomings with traditional road traffic safety researchmethods and the data used for this research.The Federal Highways Administration (FHWA) Venn diagram in Figure 2.1 for safety on a road,or cause of crashes, shows that 93% of crashes are caused in part by human error (Driver). Bymodifying the way that vehicles are driven - removing the driver and replacing it with a computer- it can cause a shift to where the majority of crashes are caused while reducing the total numberof crashes.The other key considerations for transportation facilities are mobility and sustainability (includingthe environment). Transport Canada (2006) undertook a study to identify the costs of congestionin major urban cities across Canada, identifying the cost annually to be between $2.3b - $3.7b in2002 dollars. This value will have changed in more recent years. In the Metro Vancouver region,a report by HDR for the mayors council responsible for regional transportation indicates the costof congestion in Vancouver alone equates roughly to $1.4m per year in 2015 dollars, includingdelay, vehicle operating and related costs, as well as business inefficiency costs and reduction ineconomic activity (HDR, 2015). A joint study conducted by the Texas Transportation Institute andINRIX identified the cost of congestion in the USA to be in the magnitude of $160 billion for theyear 2014 (Schrank et al., 2015). Based on this information it is evident that improvements totransportation facilities and technology are required in order to reduce the cost of congestion andthe impacts to society.10Figure 2.1: FHWA Causes of Road Crashes (Lum and Reagan, 1995)2.1.1 Traditional Road Traffic Safety AnalysisTraditional road traffic safety analysis typically involves collecting years of collision data to beable to evaluate conditions on a road. The level of safety of a location on a roadway is measuredby the frequency of collisions by collision type: property damage, injury and fatality. A location isconsidered unsafe if the number of observed collisions exceeds what should be expected derivedfrom a collision prediction model, a regression model that estimates the collision frequency for asite based on the characteristics specific to that site (Sayed and De Leur, 2008).This is a reactive approach that has several shortcomings including poor quality collision data dueto the subjective nature of collecting information, long collection periods since collisions do notoccur frequently enough to produce a sufficient data set in a short period of time, and the ethicalissues that arise since in order to prevent collisions, many collisions first need to occur. Alternative11methods of evaluating safety on roadways should be considered to address these shortcomings.Hauer (2006) outlines the issues with using reported collisions as a measure for road traffic safetyresearch, specifically that less severe collisions may not be reported and there may be bias to-wards a specific demographic or vehicle type more inclined to report collisions. Nicholson (1985)demonstrates through observed collision information that assumptions that are used within tradi-tional road traffic safety research, namely the “Poisson assumption” are not always valid, showingconsiderable variability within the observed collision information. Hirst et al. (2004) identifiesthat accident risk declines over time and therefore the collision prediction models used tend tobecome outdated, with subsequent proposal of a correction procedure to account for errors withoutdated models. de Leur and Sayed (2001) discuss the issues with using collision data and pro-poses the use of insurance claim reports to obtain better detail of contributing factors leading to acollision. de Leur and Sayed (2003) identify the individual obstacles with traditional road trafficsafety research and attempt to provide potential solutions for each of the obstacles.One of the key shortcomings to traditional road traffic safety research is the length of time requiredfor collecting collision data. It is well known that collisions in traffic occur as rare and randomevents (Davis, 2004; Hauer, 2006; Hirst et al., 2004; Nicholson, 1985; Saunier and Sayed, 2007).Because of this it is difficult to properly evaluate the instances of collisions without taking lengthyevaluation periods. Alternative methods of collecting information are required to enable quickerresponse to unsafe transportation facilities.2.2 Traffic Conflict TechniqueDue to limitations with traditional road traffic safety analysis, alternative traffic safety researchmethods have been developed to address some of the shortcomings of traditional road traffic safetyresearch. Surrogate safety measures have been used as safety measures that do not rely on reportedcollisions. Traffic conflicts, or near misses, address some of the shortcomings of collision data12such as shorter collection time, more frequent occurrences and less cost to society.The traffic conflict technique involves recording the frequency and severity of conflicts betweenvehicles on a roadway, allowing for the immediate evaluation of unsafe driving maneuvers withouthaving to wait for collisions to occur (Amundsen and Hyden, 1977). Traffic conflicts were origi-nally proposed by Perkins and Harris (1968) with an objective to identify other traffic events thathave a higher frequency of occurrence than collisions and can be related to collisions. The researchperformed by Perkins and Harris (1968) involved identifying instances where drivers take evasivemaneuvers to avoid collisions, such as hard braking or the sudden changing of lanes, indicatingthe presence of areas with higher risk of collisions. The methodology was later named the “trafficconflict technique” (Chin and Quek, 1997; Perkins and Harris, 1968). Through the use of recordedvideo and standardized measures, researchers have been able to evaluate road traffic safety throughtraffic conflicts from a laboratory or office (Shinar, 1985).The traffic conflict technique has many benefits as a safety surrogate in road traffic safety research.Specifically, traffic conflicts occur more frequently, they provide insights into the failure mecha-nism leading to road collisions, the collection period is much shorter than traditional traffic safetydata collection, and the ethical dilemma of waiting for collisions to occur is no longer a factor(Chin and Quek, 1997).2.2.1 Traffic Conflict IndicatorsTraffic conflict indicators are the measures used to represent a conflict between road users (Essa,2015). Traffic conflict indicators have been well documented in previous studies (Autey et al.,2012; Cunto, 2008; Ismail, 2010). The SSAM software package can be used to evaluate surrogatesafety measures in conjunction with the output from the VISSIM micro-simulation model. Thefollowing sections describe some common traffic conflict indicators used in the SSAM.132.2.1.1 Time-To-Collision (TTC)Hayward (1972) originally defined the Time to Collision (TTC) indicator as “the time required fortwo vehicles to collide if they continue at their present speeds on the same path.” Amundsen andHyden (1977) later described the TTC indicator as “an observable situation in which two or moreroad users approach each other in space and time to such an extent that there is a risk of collision iftheir movements remain unchanged.” The TTC is considered the most widely used traffic conflictindicator.To be a useful measure, the TTC requires projection of vehicle trajectories into the future, based oninformation prior to the evasive maneuver taking place. This has been done using a probabilisticapproach based on common motion patterns for prediction using computer vision techniques forextracting trajectory information (Saunier and Sayed, 2008; Saunier et al., 2010).Some shortcomings of the TTC indicator are that several combinations of speeds and distancecan produce the same TTC value, showing that TTC may not be a good method for determiningseverity of an incident, continuous measurements of TTC can require large amounts of informationto be gathered about vehicle trajectories making it difficult and still time consuming, and finallythe variations of the definition of the TTC may make it complicated for traffic safety practitionersto know which variation is the right one to use.2.2.1.2 Post Encroachment Time (PET)The Post Encroachment Time (PET) indicator is the moment in time between when the “offending”vehicle leaves the zone where a potential collision has occurred and the moment in time that theother “non-offending” vehicle arrives at that same potential collision zone (Cooper, 1984). ThePost-Encroachment Time (PET) can be measured through observation of vehicle trajectories anddoes not require any projection of trajectories into the future.14Conflict severity is not attainable through the PET indicator as it does not require speed and dis-tance measurements to be determined (Archer, 2004; Ismail, 2010). Another issue with the PETis that it is calculated at times even when no risk exists of a collision, typically in rear-end andmerging conflict situations depending on the speed of the following vehicle in relation to the leadvehicle (Archer, 2004). Another shortcoming of the PET indicator is that it can have false readingswhen a vehicle takes an evasive maneuver to avoid a collision and the following vehicle never ac-tually encroaches on into the trajectory of the lead vehicle, for example with the lead vehicle beingin a queue of stationary vehicles (Shelby, 2011).2.2.1.3 Maximum Speed (MaxS) and Difference in Speed (DeltaS)The MaxS indicator is the maximum speed of either vehicle throughout the instance of the conflictand DeltaS is the difference in vehicle speeds observed at the minimum time to collision. TheMaxS and DeltaS indicators are related to the severity of an incident should one occur (Gettmanet al., 2008).A shortcoming of the MaxS indicator is that speed is a scalar value and does not allow for theinclusion of direction, resulting in MaxS not being able to distinguish the severity of a head-oncollision versus the minor severity of a rear-end collsion (Shelby, 2011). The DeltaS indicator hasthe same shortcoming in that it does not represent the direction but rather only the magnitude ofspeeds (Shelby, 2011).2.2.1.4 Change in Velocity (DeltaV)The DeltaV indicator is the change between the conflict velocity and the postcollision velocity.It is the surrogate for the severity of the conflict and is calculated using the hypothetical colli-sions between the two vehicles involved in the conflict (Gettman et al., 2008). Within SSAM,DeltaV is provided for both of the vehicles (FirstDeltaV, SecondDeltaV) as well as the maximum15DeltaV observed in the conflict (MaxDeltaV). Shelby (2011) describes the DeltaV indicator as thebest indicator for severity. Gettman et al. (2008) describes FirstDeltaV and SecondDeltaV as thesurrogates for the severity of the conflict.The DeltaV conflict indicator is not widely used. However it has demonstrated robustness whereother indicators have shown issue (Shelby, 2011).2.2.2 Challenges to the Traffic Conflict TechniqueThe traffic conflict technique is not without its challenges, despite the benefits discussed previously.The main challenges with respect to the traffic conflict technique are with respect to consistency,validity and reliability.When categorizing evasive maneuvers by drivers, there are inconsistencies between field observersand the recorded conflicts are prone to errors. Additionally, a collision or conflict may occurbecause of the lack of an evasive maneuver, thus making it difficult to categorize the situation as aconflict or properly specify the value of the indicator being measured.The validity of the traffic conflict technique has been criticized as there have been many studiesthat have failed to find an acceptable statistical correlation between the measured conflicts andmeasured collisions. Glennon et al. (1977) has claimed also that for every study where goodcorrelation is shown, there is another study where poor correlations have been found. There havebeen studies however that show statistically significant correlations between the conflicts and thecollisions (Brow, 1994; Sayed and Zein, 1999).The reliability of conflict measures is often the main consideration in opposition to the trafficconflict technique. Primarily because of intra-rater variation, or inconsistencies in the recordingsmade by one field observer, as well as inter-rater variation, or the inconsistencies of interpretingand recording conflicts between different observers (Chin and Quek, 1997). Training manuals have16been developed to help avoid intra-rater variation, however observations are still subjective in na-ture and therefore prone to these shortcomings. Automated video analysis has made advancementsin recent years through the field of computer vision and is showing to be a promising method tocounteract the issues identified with manually observed conflicts (Ismail, 2010).2.2.3 Computer Vision Techniques for Conflict AnalysisAutomated computer vision techniques have been used more recently to perform conflict anal-ysis, removing the subjectivity seen when manual evaluation of conflicts takes place from fieldobservers. This technique has been employed for automatic conflict analysis in various safety ap-plications such as before and after studies (Autey et al., 2012; Pin et al., 2015; Sayed et al., 2012,2013).Automated video based analysis overcomes the shortcomings of field observations both from acost and data reliability perspective, and has proven to be more accurate in determining conflictseverity. The installation of cameras is easier and less expensive than installing other detectorsand the cameras can be used for other purposes, especially validating information detected by thesystems.2.2.3.1 Computer Vision at UBCThe Transportation Engineering group at the University of British Columbia in the department ofCivil Engineering is continuously advancing research into the development of computer vision forthe purposes of automated video analysis. Autey et al. (2012) provides a detailed description ofthe automated computer vision process for video analysis.172.3 Intelligent Transportation SystemsIntelligent Transportation Systems (ITS) are, according to ITS Canada (2012), “[t]he applicationof advanced and emerging technologies (computers, sensors, control, communications, and elec-tronic devices) in transportation to save lives, time, money, energy and the environment.” ITS areused in applications such as highway traffic monitoring, signalized intersections, on-board vehiclenavigation systems, personal smartphone applications, tracking of dangerous goods and connectedvehicle technologies. The key concept behind ITS is using technology to collect and disseminateinformation to improve the knowledge about a transportation network, improve traffic conditions,and to improve user experience.ITS are a means of managing capacity and demand through the use of electronic systems thatcommunicate typically with the driver through on-road infrastructure such as a Dynamic MessageSign (DMS) or on-board devices such as navigation systems. ITS is a broad topic with a widerange of applications. The primary application of ITS for the purposes of this thesis is with respectto Connected Vehicle applications and safety.2.3.1 In-Vehicle TechnologiesIn-vehicle technologies involve electronic sensors and processors to collect information from thefield and produce changes to driver or vehicle behaviour. Often different sensors, both activeand passive, are used in detecting and tracking vehicles or other objects such as pedestrians, lanemarkings and traffic signs for use with in-vehicle technologies. The implementations of thesesystems have many applications such as adaptive cruise control, forward collision warning withpre-crash sensing, headway alert, parking sensors, blind spot sensors and brake support. Someof these technologies have benefited transportation safety in that they help to identify dangeroussituations and assist the driver to take evasive action sooner to avoid a collision. Additionally,the technologies such as Anti-lock Brake System (ABS) and Electronic Stability Control (ESC)18assist by helping the driver to stay in control of the vehicle when the vehicle is skidding or brakingsuddenly (Transport Canada, 2011). Other technologies, such as on-board navigation systemsprovide a communication method to drivers to provide advance warning of traffic or incidents onthe roadway and attempt to remove driver uncertainty in unfamiliar areas.While the intended benefits of in-vehicle technologies may be safety related, driver behaviouraladaptation may counteract these safety benefits, negating any improvement created by the system.Systems that are intended to make driving easier, such as adaptive cruise control, can cause driversto focus more on secondary tasks resulting in increases to response times to hazards on the roadwaycreating a danger or a reduction in safety on the roadway (Rudin-Brown and Parker, 2004).2.3.2 Safety and Behavioural AdaptationSome safety applications of ITS in relation to in-vehicle technologies are brake assist, adaptivecruise control, pedestrian detection, blind spot detection, lane assist and collision warning system.When safety measures are implemented within a transportation system, the primary focus is onone or multiple of exposure, crash risk and consequence. These are the typical factors beingmeasured for any change to improve safety on the roadway; however, there are unexpected factorsoutside of what was intended by the engineering effect which could have adverse impacts on otherfactors and counteract the positive benefit of the original safety measure. The engineering effectis the anticipated change in safety level due to the factor implemented. These adverse effects aretypically caused by behavioural adaptation or risk compensation which is when road users changebehaviour to compensate for the safety measure. Kulmala (2010) provides an assessment of safetyeffects resulting from ITS, finding that measures that are more easily detected by road users, orhave a greater engineering effect, generally lead more to behavioural adaptation than those that arenot easily detected.Smiley (2000) discusses the behavioural adaptation to driver condition such as age or time sensitive19driving (e.g., running late for a meeting), and on the impacts that ITS have on driving conditions.With the onset of power braking systems and improved car handling and adaptive cruise controlsystems, average headways are reduced while average driving speeds increase (Smiley, 2000).In relation to behavioural adaptation, Bjørnskau (1995) proposed five hypotheses to explain be-havioural adaptation to the implementation of any safety measures and Elvik (2004) organizesthese in the following ways: 1) how easily a measure is detected, 2) antecedent behavioural adap-tation to target factors, 3) size of the engineering effect on target factors, 4) whether or not ameasure primarily reduces injury severity, and 5) whether or not additional utility can be gained.Kulmala (2010) further expands on these factors and proposes the following nine-point list of ITSsafety mechanisms as a framework for assessing the road safety impacts of ITS.1. Direct in-vehicle modification of the driving task2. Direct influence by roadside systems3. Indirect modification of user behaviour4. Indirect modification of non-user behaviour5. Modification of interaction between road users6. Modification of exposure7. Modification of modal choice8. Modification of route choice9. Modification of accident consequences onlyOf the nine-point list, the research as part of this thesis would be able to coordinate efforts withroadside systems to directly influence driver behaviour (e.g., through roadside messaging of inci-dent risk). Additional points that are secondary areas that this thesis touches on are the indirectmodification of user behaviour, the indirect modification of non-user behaviour, the modificationof interaction between road users, modification of road user exposure and modification of routechoice.20Both Kulmala (2010) and Elvik (2004) provide a general model of the causal chain as to how roadsafety measures influence the road safety. This model is presented in Figure 2.2.Figure 2.2: General Model of the causal chain for the influence of road safety measures onroad safety (Elvik, 2004; Kulmala, 2010).2.3.3 Connected and Autonomous VehiclesThe major disruptive technology at the time of writing this thesis are related to connected and au-tonomous vehicles. They are components of ITS however require much greater discussion. Beinga primary focus of this thesis, connected vehicles are those that include some form of communi-cation to something other than itself. The communication can be in the form of connection with apiece of infrastructure on the side of the road, another vehicle, a combination of the two or multipleother objects. Three terms are used to describe connected vehicles: V2V, V2I, and V2X whichis a more general term now used where “X” can be another vehicle, a piece of infrastructure, anon-board device or a cloud technology, or other such as the Internet.Autonomous vehicles are those that can drive autonomously and do not require human interaction.Autonomous vehicles rely on sensors installed on the vehicle itself to detect where they are (boththrough Global Positioning System (GPS) and other sensors) and what is going on around them(Gibbs, 2014). When combined with software, autonomous vehicles are capable of identifyingobstacles on the road, lane lines, traffic signals, pedestrians and cyclists, and other vehicles on theroad. In essence, autonomous vehicles remove the need for a human driver and replace it with a21computer that is capable of doing nearly all of the same things but with a much higher frequencyand faster decision and response times.While autonomous vehicles have been touted as the future (Luettel et al., 2012), there is an in-herent need for vehicles to communicate with each other as well. As an example, at the time ofwriting this thesis the Google Car had driven over 1.3 million miles and had been involved in lessthan 20 crashes. Even with the Google Self-Driving Car 1 having the majority of accidents causedby other drivers due to human error, the first instance of a collision that is the fault of the GoogleSelf-Driving Car could have been avoided if a form of communication between the vehicles waspresent .2 Another collision, more critical than the one reported by Google, involved Tesla’s au-topilot which resulted in a fatality due to the inability for the autopilot function to see a tractortrailer, resulting in the Tesla travelling underneath the trailer while the roof of the tesla collidedwith the underside of the trailer. This collision could have also been avoided if there had been acommunication protocol between the vehicles on the road to have prompted emergency braking inadvance of the collision.3Connected vehicle technologies are the methods that vehicles can be connected whereas the appli-cations are how those technologies are put into practice. In the following sections I will discusssome of the existing technologies and applications of connected vehicles at the time of writing thisthesis.2.3.3.1 Connected Vehicle Technologies and ApplicationsThis thesis will distinguish between connected vehicle technologies and connected vehicle appli-cations as follows: connected vehicle technologies are the specific pieces of hardware that enablevehicles to speak with one-another or with the surrounding infrastructure or other devices; con-1The Google Self-Driving Car is an autonomous vehicle that has been developed by Google and at the time of thisthesis being written has driven over 1.3-million miles autonomously.2http://www.businessinsider.com/video-google-self-driving-car-slowly-hits-city-bus-2016-33https://www.theguardian.com/technology/2016/jun/30/tesla-autopilot-death-self-driving-car-elon-musk22nected vehicle applications are the practice of putting to use connected vehicle technologies forreal-world applications that make a change to safety, mobility or sustainability.Connected vehicle technologies have typically been decided by the automaker with support fromstandards organizations such as the Institute for Electrical and Electronics Engineers (IEEE) andthe Society of Automotive Engineers (SAE).The word “connected” is often used to interpret when people or things are on and available, in con-stant communication with someone or something. While widespread use of the term “connected”implies it relates to the Internet, in terms of connected vehicles, there is a component that mayrefer to the “Internet of Things” 4, although this is primarily for the infotainment component anddoes not relate much to transportation or traffic engineering purposes being discussed in this thesis.There are two types of connected vehicle applications under consideration in this thesis: 1) thosethat communicate information to the driver in order to encourage driver action, and 2) those thatcommunicate information to the vehicle in order to enact action. With respect to this thesis theapplications to be discussed are those that intend to improve the safety or mobility of a vehicle ora road or network.When evaluating the applications of connected vehicle and autonomous vehicle technologies theyare being applied to the current vehicle network, based on existing driver behaviours. What needsto also be reviewed are the behaviours that should be anticipated to change due to the increasedtechnologies.With new disruptive technologies, user behaviour is often altered. An example of where technol-ogy has become disruptive is with the onset of cellular phones and the unexpected outcome thatmore time would be spent typing (through email and messaging applications) than speaking. Thesame can be expected from connected vehicle and autonomous vehicle technologies, although the4The Internet of Things is a combination of computers, systems, machines and other unique identifiers with theability to communicate, transfer data, and perform tasks without requiring human-to-human or human-to-computerinteraction.23outcome of behavioural changes will not fully be known until there is a widespread distribution ofthese vehicles on the roadways.2.3.3.2 Social Impacts of Connected and Autonomous VehiclesWhile connected and autonomous vehicles may have many practical impacts, there are indirectsocial impacts which should be considered.When considering driverless vehicles, all humans travelling within these vehicles can now be clas-sified as passengers. This creates problems of a new sort that need to be considered by automanufacturers. A recent article published in IEEE Spectrum 5 explains how nausea will be moreof a common occurrence because of the lack of coordination between the eye and inner ear for the(former) drivers as they will be preoccupied performing other tasks such as reading, working, orsocializing.2.4 The VISSIM Micro-Simulation Model and SSAMTraffic simulations are very useful to evaluate components of a road or vehicle design that have notyet been built or deployed in the real-world. Within micro-simulation models traffic conflicts canbe observed. The software package called surrogate safety assessment model, referred to as SSAM,has been developed to automate the output of a simulation from four different micro-simulators:VISSIM, AIMSUN, PARAMICS and TEXAS.Gettman et al. (2008) conducted 11 theoretical validation tests to compare the results of pairs ofsimulated design alternatives, and field validation on 83 intersections in order to assess the use ofSSAM. The underlying principle to this study was to evaluate the ability of SSAM to distinguishbetween two design alternatives in a simulation. The results showed there were statistically signif-icant differences in the total number of conflict events, number of conflicts of a certain type, and5http://spectrum.ieee.org/cars-that-think/transportation/self-driving/will-robocars-make-you-puke24the mean and variance of surrogate safety measures (time to collision, post-encroachment time andothers). A field verification was done comparing five of the simulated intersections to those thatwere actually monitored in the field and the results showed a statistically significant correlationbetween the conflicts found in SSAM and those found in the field. It was noted in the study thatvolume based crash prediction correlated better with the actual crash data than the surrogate safetymeasures did in all cases. While the study demonstrated that SSAM would very much benefit thestudy of safety for facilities not yet built, the validation results were ultimately considered incon-clusive and there were some recommendations for future research, such as develop a compositesafety index, improve driver behaviour modelling in simulations, and investigate conflict classifi-cation criteria (Gettman et al., 2008). Essa and Sayed (2015a) demonstrated the need to calibrateVISSIM through comparison before and after the two-step calibration process, using SSAM as thesecond step for calibration.Dijkstra et al. (2010) performed a study simulating conflicts at many junctions in the Netherlands(a total of 569) using the PARAMICS microscopic simulation software. Additionally, actual crashdata was collected at these same junctions in the real world. The relationship between simulatedconflicts and observed crashes was assessed using generalized linear models in the GENMODprocedure of the SAS software. Different log-linear models were developed by using either 1)negative binomial distribution or 2) poisson distribution. Different TTC thresholds were usedin calculating the conflicts. Regression analysis was performed and both the negative binomialdistribution and the poisson distribution led to similar results for goodness of fit of the modelsused and the significance of the variables. It was found that the number of conflicts observed atjunctions and the number of passing vehicles are statistically related to the number of observedcrashes for all of the junctions (Dijkstra et al., 2010).Fan et al. (2013) developed a procedure for using SSAM and VISSIM for safety assessment atfreeway merge areas. The tasks of this study were to develop VISSIM simulation models account-ing for driver behaviour, and to improve consistency of simulated conflicts with manually collected25field observations through calibration of VISSIM and SSAM. The first stage of calibration con-sisted of reproducing volume, speed and travel time in VISSIM to that what was observed in thefield. During the second stage of calibration, crucial parameters, specifically the TTC parameteras defined in SSAM, were modified to replicate what was observed in the field. The optimal TTCvalue was where the mean absolute percent error Mean Absolute Percent Error (MAPE) was foundto be a minimum, and TTC was found to be 2.1 seconds. The two-stage calibration procedurewas found to reduce the MAPE for rear-end and lane-change conflicts at freeway merge areas andshowed reasonable consistency with field observations (Fan et al., 2013).Huang et al. (2013) evaluated whether or not the combination of VISSIM and SSAM providesreasonable estimates for traffic conflicts at ten signalized intersections. Field data was collectedand conflict analysis was performed manually at the observed locations. A two-stage calibrationprocess was implemented to calibrate and validate the VISSIM simulation models and to adjustthe threshold values in SSAM. The minimum TTC threshold in SSAM was calibrated to givea minimum MAPE of simulated rear-end conflicts and the minimum gap time in VISSIM wascalibrated to give a minimum MAPE of simulated crossing conflicts. The results were an optimumTTC of 1.6 seconds and an optimum minimum gap of 2 seconds. Transferability of the simulationmodel was tested by comparing the results of simulation at two other sites using the calibratedparameters and without re-calibrating (Huang et al., 2013).Huang et al. (2013) investigated whether performing a two-stage calibration procedure to adjustthe threshold values in SSAM would benefit the simulation within VISSIM when comparing withobserved conflicts. The findings showed that the two-stage approach improved the goodness-of-fitbetween simulated and observed conflicts and that the calibration of the SSAM thresholds weretransferable when simulating other situations and comparing with observations.Gettman et al. (2008) summarizes the research for the SSAM which was developed to combinemicro-simulation and automated conflict analysis to assess the safety of traffic facilities withoutwaiting for crashes and injuries to occur.26Evaluation of traffic micro-simulation models has shown that real world calibration is necessary.An example of the need for calibration is provided in Gomes et al. (2004) where VISSIM wascalibrated for congested freeways. For the most part the default values within VISSIM provideda good fit for traffic flow on the freeway. However, Gomes et al. (2004) found there were threeproblem areas identified as bottlenecks in real conditions that were not being found in the model.The problem areas needed to be identified and the model needed to be calibrated to replicate theseproblem areas.The conflict types included for evaluation within SSAM are as follows (Gettman et al., 2008):TTC Expected time for two vehicles to collide if they remain at their present speed and on thesame path.PET Time lapse between end of encroachment of turning vehicle and the time that the throughvehicle actually arrives at the potential point of collision.MaxS The maximum speed of either vehicle throughout the conflict.DeltaS The difference in speeds of the two vehicles at the minimum time to collision.Deceleration Rate (DR) The initial deceleration rate of the second vehicle, the crossing or fol-lowing vehicle.MaxD The maximum deceleration of the second vehicle, the crossing or following vehicle.Conflict Type The type of conflict: rear end, lane change or crossing.MaxDeltaV The maximum change between conflict velocity and the post collision velocity foreither vehicle involved in the conflict.FirstDeltaV / SecondDeltaV The change between conflict velocity and the post collision veloc-ity.272.5 Evaluation of Connected Vehicle Applications UsingMicro-SimulationConnected vehicles have a set of basic technology which is being implemented as a standard, ledby the Society of Automotive Engineers International (J2735 Surface Vehicle Standard: DedicatedShort-Range Communications (DSRC) Message Set Dictionary. 2009). Typically this technologyinvolves dedicated short range communications (DSRC) and transmission of types of messagesfrom V2V and V2I. The United States Department of Transportation (USDOT) has developedan ITS Standards program to work towards the harmonization of communications standards forprogramming and development amongst automotive and equipment manufacturers, governmentsand standards organizations.Tideman and van Noort (2013) discuss the requirements put onto automotive OEMs when devel-oping new connected vehicle technologies to ensure feasibility, robustness and effectiveness of thenew technologies on the individual vehicle, small-scale scenario and traffic network levels. Theauthors are introducing software created by the independent research organization called TNOwhich provide tools to test connected vehicle systems in a simulation environment by introducingcommunications into the simulation of Advanced Driver Assistance Systems (ADAS). The soft-ware packages introduced are PreScan, a software for the design and testing of intelligent vehiclesystems, and ITS Modeller, a microscopic traffic simulator used for evaluating the design outputsfrom PreScan and integration of these designs into the traffic network level. Importance is placedon the need for automotive OEMs to develop systems that meet government needs as well as toimprove safety and/or mobility on roadways. A test case was performed looking at cooperativeadaptive cruise control (CACC). Throughout the test case it was found that the CACC system sat-isfied all the local requirements and was very safe, although it created large traffic jams becausethe CACC system didnt take traffic efficiency into account, demonstrating that calibration is nec-essary when testing systems and a global view is required. An update to the design of the CACCsystem was implemented and overall results showed that travel time, delays and the standard devi-28ation of speed in traffic jams are reduced while the average speed in traffic jams are increased fordifferent penetration levels (Tideman and van Noort, 2013). The study did not evaluate the safetycomponent of the CACC system other than stating that safety was improved.The impacts of deploying connected vehicles on the road network has been studied through micro-simulation models. Connected vehicles can communicate with each other or with the infrastructuresurrounding them. Paikari et al. (2014) perform research into combining the V2V and V2I tech-nologies to complement connected vehicle technologies, improve connected vehicle efficiency andto lead to higher safety and mobility enhancements on freeways. The authors discuss a simulation-based benefit analysis of deploying connected vehicles using DSRC. Each connected vehicle cancommunicate with other connected vehicles within their immediate proximity, providing recom-mended speed and route information while also communicating to connected roadside units whichcan subsequently post advisory information on highway signs to communicate with non-connectedvehicles. Using PARAMICS as a micro-simulator, 15 different scenarios for varying penetrationand demand loading are simulated. The evaluation of the scenarios is through safety and mobility.Mobility is measured by the average estimated point-to-point travel time. With respect to safety,a safety index is developed based on the Overall Risk Change Index (ORCI). The findings of thisstudy are such that this specific connected vehicle technology implementation shows safety im-provements and that as connected vehicle penetration increases on the roadways, so too does theefficiency on the roadways; however, the improvement in safety and mobility reaches a limit whenthe penetration rate gets to 40%, after which there are adverse effects (Paikari et al., 2014).Focusing on more specific facilities, intersection management has been a topic of interest fordecades. More recently the environmental factors such as pollution caused by congestion andidling associated with intersections have been considered an issue as traffic grows in a region.Jin et al. (2012) focuses on intersection management and the applications of connected vehiclesfor this purpose. In an advanced traffic management system specific to connected vehicles, bothconnected vehicles and the intersection infrastructure can take advantage of real time traffic infor-29mation through the use of wireless communications. The objective of this study was to demonstratethe concept of reserving a slot in space and time for travelling through an intersection, allowinga vehicle to avoid collisions and minimize wait time. Using connected vehicle technology in aV2I communications platform it is expected that vehicles will reserve a place to travel through theintersection and the infrastructure can plan the trajectory of the vehicle in advance of it entering theintersection and in coordination with other vehicles around it. This study uses the software calledSUMO (Simulation of Urban Mobility) due to its nature of handling both traffic simulation andwireless communication. Limitations to this study are the assumptions that were made, such as theassumption that all vehicles must have V2I communications. Results show that an Advanced Traf-fic Management System (ATMS) approach to intersection management using a reservation systemfor time/space within an intersection can considerably alleviate traffic congestion and reduce pol-lutant emissions and fuel consumption (Paikari et al., 2014). Safety was not a consideration ofthis study however it would be beneficial to find if collisions or conflicts are reduced by using thistechnology.Chen et al. (2014) discusses the concept of connected vehicles and the transportation system usingITS as a network as opposed to for individual vehicles. This paper does not discuss simulation butdoes discuss the safety factors associated with connected vehicles. Some discussion was providedaround driver behaviour learning (Chen et al., 2014).Miller and Horowitz (2007) describe the simulation tool that can be used for ITS applicationsas it allows for vehicles to communicate with eachother and with the infrastructure around thevehicles. While FreeSim allows for simulation of freeway applications including using ITS, thispaper does not discuss any actual simulation or safety benefits of ITS or connected vehicles (Millerand Horowitz, 2007).V2V communications is considered one of the key components to connected vehicles as it allowsfor vehicles to know and understand what other vehicles are currently doing or are about to do on aroadway. In order to enable V2V communications, a communications network must be established.30Eichler et al. (2005) discuss and demonstrate the benefits and drawbacks of Vehicular Ad-HocNetworks (VANET) using a comprehensive simulation environment. As a means to demonstratethe benefits of a VANET, Eichler, Ostermaier, Schroth, and Kosch (2005) looks at an example ofV2V traffic obstacle messaging applications for real-time traffic and safety information systems.In this example, a broken down vehicle equipped with V2V communications sends out alerts toother V2V equipped vehicles within a 250m radius whose routes are subsequently changed. Thetravel times and delays are measured for the V2V equipped vehicles and the non-equipped vehiclesto demonstrate the benefit of a VANET (Eichler et al., 2005). The output of the simulation doesnot discuss safety.Schroth et al. (2005) expand further on the importance of V2V communications on the above ex-ample using V2I communications, describing the work to quantify the possible benefits of V2Vcommunication in connected vehicles using a combined traffic and network simulation environ-ment where communications between vehicles affects route decisions. The concept of this workuses three logical components for the simulation: 1) traffic simulator which computes new po-sitions periodically, 2) network simulator dedicated to imitating the full functionality of a realwireless network with complex effects of mobile communications (only a portion of the vehiclesfrom 1 participate in 2), and 3) an application which accounts for controlling the whole simulationenvironment, evaluating received messages and deciding what action to be taken by the traffic sim-ulator. The simulation run used in this paper describes an instance where there are 900 vehicleson a road network and 400 of these vehicles are equipped with vehicle-to-vehicle communicationability. A car breaks down and broadcasts the information, which is registered within the 400connected vehicles and route choice can be made accordingly to avoid the area with the brokendown vehicle. The study used CARISMA but is expected that this would be replaced by VISSIM(Schroth et al., 2005).Highway applications for connected vehicles are equally important as highway capacity is expectedto increase with improvements in this field. Looking specifically at a V2V environment, Zhao and31Sun (2013) focus on Cooperative Adaptive Cruise Control (CACC) in a micro-simulation setting toexamine the benefits of platooning. CACC is the V2V communication method by communicatingwith the vehicle at the front of a platoon to allow for vehicles to follow each other with a closerdistance, improving traffic flow capacity. The study does a comparison with different penetrationpercentages and different platoon sizes to demonstrate the changes in capacity on a roadway. Theresults show that the higher the penetration is of CACC equipped vehicles, the higher the capacity,while the capacity does not appear to change significantly based on platoon size (Zhao and Sun,2013). It should be noted in this study that driver comfort is not considered and issues with whatwould need to change within a vehicle environment to ensure the comfort of drivers and passengerswithin the platoon are not compromised.Ben Othmane et al. (2013) do not discuss simulation but rather presents information on the safetyconsiderations needed for connected vehicles with respect to external malicious attacks (Ben Oth-mane et al., 2013).Smith and Razo (2014) discuss the importance of V2V but put an emphasis on the V2I component.Looking to deploy a pilot project in Ann Arbor, MI, micro-simulation is used to determine the levelof interaction amongst vehicles in order to best choose candidates for the pilot project. The micro-simulation was used to estimate the number of spatial and temporal locations of V2V interactionsunder various deployment strategies. Ultimately the micro-simulation model was able to showwhere and when a significant number of interactions would occur (Smith and Razo, 2014). Beforea connected vehicle application is implemented as a pilot project in the field it is important to becertain that the technologies deployed will have ample opportunities to interact the way they areintended in order to allow for proper exposure and testing prior to full implementation.32Chapter 3MethodologyTo perform micro-simulation and safety evaluation of the chosen connected vehicle applications,a number of tools were utilized. This chapter outlines the tools used and a generic methodol-ogy to create the micro-simulation model for the evaluation and subsequent assessment methods.Additionally, the procedure is outlined for the two specific connected vehicle applications beingreviewed as part of this thesis with underlying methodology to test the hypotheses of this thesis.3.1 BackgroundVISSIM is one of the most commonly used traffic micro-simulation models. VISSIM is capableof simulating all modes of transportation and has the capabilities of defining motion characteristicsof vehicles and interactions with other vehicles, allowing for evaluation on a per-vehicle basis aswell as an entire transportation network.While VISSIM allows users to customize inputs, parameters and characteristics specific to the sim-ulation, a significant programming knowledge is required to fully make use of these capabilities.There are three methods found as part of the research for this thesis to modify the behaviour of theroad traffic network in VISSIM, including both the vehicles and the infrastructure. These ways are331) through built in simulation parameter modification, 2) through the VISSIM COM interface, and3) through a Dynamic Linked Library (DLL) controlling the driver behaviour. All three of thesemethods were reviewed and best determined which were to be employed for different connectedvehicle applications. These three methods are further described below.3.1.1 VISSIM Simulation Parameter ModificationModifying the simulation parameters in VISSIM allows for varying control of driver and vehiclecharacteristics such as the headway time, following thresholds (in metres), and acceleration. Thereare over 190 distinct parameters that can be varied to the user’s preference (Essa and Sayed, 2015a).While the modification of VISSIM parameters changes the way the micro-simulation model be-haves, the changes only apply to pre-defined algorithms and vehicle behaviour based on the Wiede-mann 74 and 99 driver behaviour models and the lane change models defined within VISSIM. Tobetter evaluate connected vehicle applications, consideration should be put more on the ComponentObject Model (COM) interface and the DLL.3.1.2 The VISSIM COM InterfaceMicrosoft developed a Component Object Model (COM) technology to allow communication be-tween software, compatible with COM (Box, 1998). VISSIM is enabled with the ability to commu-nicate through COM using multiple programming languages, including Visual Basic, MATLAB,Python, Java and C++. COM allows the control of many elements of the simulation, includingsome, but not all, of the simulation parameters discussed in Section 3.1.1. Other elements con-trollable through COM include signal heads (RED, AMBER, GREEN, etc), barrier placement, theposition of a vehicle and the desired speed of a vehicle or a group of vehicles. Using COM withVISSIM also allows for enhanced reporting of information while the simulation is in progress,allowing for better insights into current vehicle operating states.34In version 5 of VISSIM there was a Car2X module which allowed for the passing of informationfrom vehicles with the appropriate equipment flag and defines when vehicles receive informationand the reaction to that information. This Car2X module was removed in subsequent versionsof VISSIM and in version 7 the suggested method to use is GetByLocation. Unfortunately thismethod was not found to be sufficient for the implementation of connected vehicle applicationswithin VISSIM for the purposes of this thesis. However, through additional programming allneeds for evaluation of the connected vehicle applications were met.Tettamanti and Horva´th (2015) outlines the use of the COM interface for VISSIM, specificallyusing MATLAB as the controller which is the same programming language used with the COMinterface for this thesis.3.1.3 The Driver Behaviour DLLDynamic Linked Libraries are shared libraries for use in the Microsoft Windows operating sys-tem environment. They contain code that can be used by multiple programs at the same time.VISSIM uses DLLs to supplement existing models. Specific to this thesis, the pre-existing Driver-Model.DLL within the VISSIM distribution was used to supplement the driver behaviour of vehi-cles labelled as connected vehicles. Other DLLs include the SignalControl.DLL, SignalGUI.DLLand EmissionsModel.DLL, allowing for user defined signal controllers and emissions models.The DriverModel.DLL allows modifications to or replacements of the car-following and lanechange models. This includes defining acceleration parameters of individual vehicles, controllingthe blinker and lane changes, and controlling the colour of a vehicle.Throughout the remainder of this section, the methods defined above in Sections 3.1.1, 3.1.2and 3.1.3 will be the referred to tools for the purpose of developing a connected vehicle envi-ronment within VISSIM.35Depending on which version of VISSIM is used there may be different needs when developing theenvironment. The following section outlines the framework for developing a connected vehicleenvironment within VISSIM version 7.3.2 Framework for Developing Connected VehicleEnvironments within VISSIMThere are a number of considerations in developing a connected vehicle environment in VISSIM.The primary considerations are the information being transmitted, the reactions to that informationand the impacts to the road traffic network. The below generic procedure is defined to supportthe development and evaluation of connected vehicle environments within VISSIM. Detailed de-scription of evaluation methodology to assess the research objectives of this thesis are provided inSections 3.3 and 3.4.1. Identify connected vehicle application2. Identify connected vehicle technology3. Determine changes within VISSIM4. Identify tool to perform the changes within VISSIM5. Apply changes through appropriate tool6. Evaluation configuration7. Run simulation8. Evaluate simulationBelow are further definitions and explanations of each step.3.2.1 Identify Connected Vehicle ApplicationConnected vehicle applications can vary by location, complexity with interactions between vehi-cles and with infrastructure (both V2V and V2I), and purpose (e.g., reduce emissions, improve36mobility, improve safety). The connected vehicle application is the specific way that vehicles willinteract with other vehicles and surrounding infrastructure. In this thesis, the two connected vehi-cle applications being evaluated through micro-simulation and SSAM are Cumulative Travel TimeIntersection Control and Cooperative Adaptive Cruise Control.3.2.2 Identify Connected Vehicle TechnologyThe connected vehicle technology is the specific pieces of hardware and base technology usedto support the connected vehicle application. The technologies deployed are typically DSRC forcommunications while sending information through the Basic Safety Message (BSM). The tech-nologies used need to be understood in order to identify where in VISSIM the modification needsto take place.3.2.3 Determine Changes Within VISSIMAfter the connected vehicle application and technology have been identified and understood, anevaluation needs to be undertaken as to where the changes will occur within VISSIM. This willinclude changes to vehicle control, infrastructure control, or driver behaviour. For example, if thedriver behaviour changes due to the connected vehicle application or technology, it is possible thatthe reaction time will change, or if the vehicle is assuming some of the driving control, it is possiblethat the acceleration and deceleration driving behaviour may change.3.2.4 Identify Tool to Perform the Changes Within VISSIMThe tools available for implementing connected vehicle applications in VISSIM are referenced inSection 3.1 as internal VISSIM parameters, the COM interface, and the driver behaviour modelDLL. To best implement the connected vehicle application, the proper tool(s) need to be identifiedand used.37The VISSIM parameters should be modified if the predefined algorithms within VISSIM do notneed modification but only the sensitivity of the micro-simulation itself. The VISSIM parameterswill typically not be changed in isolation of the use of another tool for connected vehicle applica-tions.The COM interface should be used if dynamic manipulation of the internal object attributes isrequired. For any infrastructure control, the COM interface is most likely the tool to be used.COM can control the signal timing of a signalized intersection and the placement of barriers. Withrespect to vehicle control, some components can be modified such as the desired speed and someof the VISSIM parameters discussed previously; others cannot, such as the specific acceleration ofa vehicle. Additionally, to implement a change to the micro-simulation model during a simulation,a break needs to be applied which has an impact on the time needed to perform the simulation,especially when multiple simulation breaks need to occur over a short period of time.The DLL should be used to implement a connected vehicle application where control of vehiclesis required. By manipulating parts of the DriverModel.DLL, the car following and lane changingdriver behaviour can be modified based on user defined algorithms. Some of the specific compo-nents associated with driver behaviour that can be modified under the DLL are the desired velocity,desired acceleration, target lane / lane change initiation, and vehicle colour. Specific algorithmscan be developed defining the driver behaviour. The DLL can be defined for different vehicle typesmaking it useful for an evaluation of an incomplete market penetration of connected vehicles. Itis applied for every simulation step and replaces the base driver behaviour model included withinVISSIM.Once the appropriate tool is identified, specific changes need to be introduced.383.2.5 Apply Changes Through Appropriate ToolAfter the tool is identified, there most likely will require programming to implement the connectedvehicle environment. For modification of the internal VISSIM parameters only, the VISSIM GUIcan be used. For the COM interface and the DLL tools, external software packages need to be usedto perform the programming.The DLL needs to be written and built as a C++ program. The base DriverModel.DLL is providedas part of the VISSIM distribution. The work done for this thesis used the Microsofit Visual Studioto develop the DLL.Applying changes through the COM interface can be done through a selection of programminglanguages, including Visual Basic, C++, Python and MATLAB. COM is implemented more as ascript that follows a specific series of instructions. Examples are provided as part of the VISSIMdistribution.3.2.6 Evaluation ConfigurationVISSIM has options for configuring the simulation to record and output specific metrics that aredetermined before the simulation is run. To ensure that traffic conflicts can be evaluated usingthe SSAM subsequent to the evaluation, the SSAM output needs to be selected, resulting in thecreation of a .trj file.3.2.7 Run the SimulationGiven the stochastic nature of traffic, extended to micro-simulations, multiple simulation runs ofthe same parameters and defined algorithms need to be applied to remove any unforeseen biascaused by the random initial seed. If the COM interface is being used, VISSIM can be launchedand terminated from within the script, allowing multiple simulation runs to occur while varying39the initial random seed.3.2.8 Evaluate the SimulationEvaluation of the connected vehicle application should be done for the purpose the application isintended, such as improvement in mobility, emissions or safety. Identifying how the evaluationwill be performed needs to occur prior to running the simulation so that appropriate measurementtools can be input into the model and configured. This includes inputting travel time measurementpoints and data collection points, as well as ensuring that the appropriate selections are made underthe evaluation configuration and database configuration.Both simulations conducted under this thesis had an objective of evaluating safety using surrogatesafety measures, while also evaluating mobility in the form of travel times. The two objectives ofthis thesis are defined in Section 1.2. To evaluate the first objective of this thesis, expectations ofimplementing the connected vehicle applications are defined and simulations were performed fornon-connected vehicle environments as well as connected vehicle environments. The results of theconnected vehicle environment are compared with the expected results and the non-connected ve-hicle environment results. To evaluate the second objective of this thesis, the VISSIM parametersare modified for both the non-connected vehicle environment and the connected vehicle environ-ment. Comparisons are made between the results to demonstrate the impact of calibration throughmodification of VISSIM and other parameters.The following sections describe the methodology for evaluating these connected vehicle applica-tions through the VISSIM micro-simulation model. Evaluation can be performed using a varietyof tools. This thesis uses Microsoft Access and Excel to perform the evaluation.403.3 CTT Intersection Control MethodologyThis section describes the methodology of implementing the Cumulative Travel Times (CTT) con-nected vehicle environment for the purposes of intersection control in VISSIM. The CTT con-nected vehicle application involves changes in signal timings based on the cumulative travel timesof connected vehicles approaching an intersection to reduce delays at the intersection and improveoverall throughput. This application involved only the control of infrastructure, specifically a traf-fic signal at a signalized intersection, and does not require the modification of driver behaviour ofany vehicle type (connected or not).The simulation network is based on an urban signalized intersection located in Surrey, BC, Canadaat 128th Street and 72nd Avenue, commonly used in other research at the University of BritishColumbia (Essa and Sayed, 2015a,b, 2016; Tageldin et al., 2014). There are 4 protected-permissiveleft turns. To prepare the current conditions, traffic data was used from research conducted by Essaand Sayed (2015a), recorded by using 8 cameras positioned to cover areas of the 4 approaches.The intersection and associated camera locations are provided in Figure 3.1 (Tageldin et al., 2014).Essa and Sayed (2015a) describes the process taken to extract information from the intersectionsuch as signal timing, traffic volumes, vehicles arriving during green time, traffic composition andthe number of public transit buses, average travel times, and average delay times.To enable the connected vehicle application, the technology required was identified as the BSM.The infrastructure needs to collect the positions of all connected vehicles within the network inorder to know how many connected vehicles are in each intersection approach and in turn use thisinformation to decide which signal phase to make green while keeping other phases red.Changes within VISSIM were identified as the signal timing of the signalized intersection. Inorder to implement these changes the COM interface was used, creating algorithms to identify thecumulative travel time and decide on signal phases.41Figure 3.1: Intersection and Associated Cameras at 128th and 72nd (Tageldin et al., 2014)The simulation was run using the COM interface in MATLAB, allowing for variation of randomseed numbers to create consistency when comparing different input parameters. Evaluation wasperformed both for safety, using the SSAM software package, and mobility through travel timemeasurements.To evaluate the first objective of this thesis for the CTT Intersection Control simulation, a non-connected vehicle environment was simulated where the intersection control is based on real-worldparameters and signal timing. Expected results are that with increasing connected vehicle marketpenetration, rear-end conflicts will be reduced as queuing is anticipated to be reduced and the needfor vehicles to change their speed (either through acceleration or deceleration) as they approachthe intersection will also be reduced. To evaluate the second objective of this thesis for the CTTIntersection Control simulation, the simulation was performed through the two steps of calibra-tion, modifying the VISSIM driver behaviour parameters and the results are evaluated throughcomparison with the non-connected vehicle environment.42The CTT Intersection Control simulations are discussed further in Chapter 4 and Chapter 5.3.4 CACC MethodologyThis section will describe the methodology of implementing the cooperative adaptive cruise control(CACC) connected vehicle environment in VISSIM. The CACC connected vehicle applicationinvolves vehicles cooperatively platooning through V2V communication to reduce the headwaywithin platoons and increase overall capacity of a roadway. This application involves controlof vehicles through the on-board computers, in essence modifying the driver behaviour of thespecified vehicles.The simulation environment involved creating a 4km straight section of a two-lane freeway withoutentrance or exit ramps.To enable the application, the connected vehicle technology required was identified as the BSM,allowing transmission of basic vehicle information for all connected vehicles to other connectedvehicles, such as the position, size, speed, heading and acceleration. Vehicle control is assumed tobe through mechanical and electrical equipment installed within the vehicle.Changes within VISSIM were identified as the acceleration determination and the overall control ofthe vehicle. In order to implement these changes, the DriverModel.DLL was modified to enable theconnected vehicles to behave according to predefined algorithms related to acceleration and lanechange. The changes made within the DriverModel.DLL were only implemented in the situationwhen a cooperative platoon was in place, forming or disbanding. The acceleration and lane changeswere modified accordingly.The simulation was run using the COM interface in MATLAB, allowing for variation of the randomseed numbers to create consistency when comparing different connected vehicle market penetra-tion levels. Evaluation was performed both for safety, using the SSAM software package, and43mobility through travel time measurements.The configuration set up for the micro-simulation involved setting output of Result Attributes,specifically Delays, Nodes, Vehicle Network Performance, Vehicle travel times, and of DirectOutput, specifically the Nodes (raw data), SSAM (to obtain the .trj file), and Vehicle travel times(raw data).To evaluate the first objective of this thesis for the CACC simulation, simulation was conducted fora non-connected vehicle environment where the vehicles on the road are either manually driven orenabled with adaptive cruise control and no vehicles were equipped with the cooperative adaptivecruise control connected vehicle technology. Multiple iterations of the simulation were conductedwith varying levels of connected vehicle technology. The conflicts and travel times are measuredover the period of time and area around a simulated delay. Expected results are that with increasingconnected vehicle market penetration, rear-end conflicts will be reduced as traffic flow will bemore stable with the cooperative adaptive cruise control algorithm applied. To evaluate the secondobjective of this thesis for the CACC simulation, the VISSIM driver behaviour parameters andacceleration coefficients within the CACC algorithm are modified and the results are comparedwith the non-connected vehicle environment using the default VISSIM driver behaviour parametersand the originally chosen acceleration coefficients.The CACC simulations are discussed further in Chapter 4.44Chapter 4Connected Vehicle Simulations WithoutCalibrationThis chapter describes the micro-simulations of the connected vehicle environments performedwithout applying calibration to the simulations. It consists of two sections, one for each of theconnected vehicle applications being evaluated: Cumulative Travel Time Intersection Control andCooperative Adaptive Cruise Control.These applications have been modelled in previous research using VISSIM and the methods usedin those previous research were applied here.4.1 Cumulative Travel Time Intersection ControlWhile adaptive signal control looks to improve the throughput of vehicles through intersections,there remain limitations due to technology and infrastructure constraints, namely vehicle detectionmethods in the field. Typical adaptive signal controllers use inductive loop detection of vehiclesas they approach an intersection to make a decision of signal timing changes. However, this re-45lies still on pre-programmed signal timing, causing unnecessary delays and queuing of vehicles.If connected vehicle technologies are used in an adaptive intersection control or adaptive signalcontrol application through Vehicle to Infrastructure (V2I) and Vehicle to Vehicle (V2V) commu-nications, it can allow for better adaptive signal control due to the higher resolution of informationavailable in the field. The V2I technology offers the capability of knowing with high accuracy thelocation of a vehicle at given time intervals. For example, Lee et al. (2013a) proposes an intersec-tion control that is based on cumulative travel times of connected vehicles along each approach ofthe intersection.The conventional way to capture travel times is by measuring the time it takes for a vehicle to travelfrom one point to another. Travel times are often an object of Advanced Traveller InformationSystems (ATIS) for freeway applications. A literature review has revealed the difficulty of usingtravel times for adaptive signal control. The likely reason for this is firstly because traditionalmethods are unable to capture the time that a vehicle has been waiting in a queue until after thatvehicle has passed the stop bar (which would be a meaningless measure in a real-time system) andsecondly, because the typical time interval for averaging travel times are for longer periods of time(e.g., 5 minutes or 10 minutes) it would not be conducive to controlling a traffic signal where thetotal cycle length may only be between 60 to 120 seconds.Connected vehicles are a possible solution to the inability to use travel times for adaptive intersec-tion control. Through the use of Global Positioning Systems (GPS) and the Basic Safety Message(BSM), a standard message as part of the Dedicated Short Range Communications (DSRC) mes-sage set dictionary (SAE International, 2016) transmitted at an approximate rate of 10 times persecond, the positions of all connected vehicles can be known through V2I communications to acentral controller stationed at an intersection.Cumulative travel time control has previously been proposed for intersections for the purposes ofevaluating mobility through the use of connected vehicle technology (Lee et al., 2013a), accountingfor the time that vehicles are approaching an intersection and the time they are waiting in a queue46at a red light. In addition to evaluating the mobility benefits of this type of a system, sustainabilityin terms of emissions is also evaluated, however safety is not a consideration through that review(Lee et al., 2013a). This section proposes to evaluate the changes to the level of safety for anintersection before and after implementing a cumulative travel time control algorithm based on theTCT and using SSAM.Lee et al. (2013a) performs a review of the applicability of intersection control for a connected ve-hicle environment implemented within VISSIM, looking at varying penetration levels of connectedvehicles and evaluating the performance of the intersection through mobility measures.This study evaluates a similar application of a CTT algorithm for adaptive intersection control,however the focus is on evaluating safety improvements using SSAM for adaptive intersectioncontrol in a connected vehicle environment. The evaluation is performed using varying connectedvehicle penetration levels. Using a micro-simulation model of an intersection developed throughresearch at the University of British Columbia (Essa and Sayed, 2015a,b, 2016; Tageldin et al.,2014), the CTT algorithm is put in place for varying connected vehicle market penetration levelsand a comparison is conducted against the non-CTT implementation.4.1.1 CTT MATLAB ImplementationTo introduce the CTT algorithm for a connected vehicle environment within VISSIM, the COMinterface is used through MATLAB.The intersection being considered contains 8 approaches in total, an equivalent of one per throughmovement and one per left-turn movement, including a signal phase for each of the approaches.Figure 4.1 (Lee et al., 2013a) illustrates the intersection layout and the signal phase numbering.When calculating cumulative travel times there were four phases used, combining two approachesof the intersection for each phase (Phase 1: Approaches 2 and 6; Phase 2: Approaches 4 and 8;Phase 3: Approaches 1 and 5; Phase 4: Approaches 3 and 7).47Figure 4.1: Nema phase numbering scheme for a four approach intersection (Lee et al.,2013a)There was no found mechanism within VISSIM and the MATLAB COM interface to prompt thechange of a traffic signal to cycle through all pre-programmed phases, such as when a signalis changing to red there would be a yellow phase and an all-red phase prior to the next greenphase being activated. The capability found was that it only allows the manual change of a signalgroup to another phase upon the next break in the simulation. Therefore, manual intervention wasrequired. Signal phases were manually coded into the MATLAB script and were chosen basedon the cumulative travel times calculated. When a change in signal phases was required throughthe algorithm, it prompted the appropriate yellow and all-red phases to execute the signal change.Tettamanti and Horva´th (2015) provides a reference to the different numeric values to set thesignalization state.The signal times used for both the non-CTT signal control and the CTT signal control are presentedin Table 4.1. For reference, where All Red Time is “N/A” it is because the signal timing is set upin the real world to have a protected/permissive left turn phase, while the CTT All Red Time hasa value as there could be a phase in the CTT simulation where the left turn phase does not flowinto the corresponding through phase green time and therefore there needs to be sufficient time for48clearing of the intersection before the next phase turns green. The CTT Min Green Time is setat the update interval used for calculation of the cumulative travel times (in Lee et al. (2013a) theupdate interval was 5s).Table 4.1: Signal Timing ValuesAppr.#GreenTimeYellowTimeAll RedTimeCTT Min GreenTimeCTT YellowTimeCTT All RedTime1 7s 4s N/A Update Int. 4s 2s2 33s 4s 2s Update Int. 4s 2s3 7s 4s N/A Update Int. 4s 2s4 23s 4s 2s Update Int. 4s 2s5 7s 4s N/A Update Int. 4s 2s6 33s 4s 2s Update Int. 4s 2s7 7s 4s N/A Update Int. 4s 2s8 23s 4s 2s Update Int. 4s 2s4.1.2 CTT AlgorithmsThe algorithm controlling the traffic signal works through collecting vehicle information for allconnected vehicles within the specific region around the intersection. For the purposes of thisthesis, the region where connected vehicle information is collected is between the stop bar and140m up the approach at each approach of the intersection. For the left turn movements the entireturning bay is less than 140m in length and therefore the whole turning bay is used for a collectionregion.At the predefined time interval, the VISSIM COM GetAll command is used to collect informationof all vehicles within the network. On a vehicle-by-vehicle basis, the information similar to whatwould be received in a BSM is reviewed to determine the precise location of each vehicle. Whenthe vehicle’s position is determined to be on the approach within 140m of the intersection, thespecific time interval is added to the cumulative travel time for that intersection approach.An example is presented in Figure 4.2 and Table 4.2. Where if the time-step is 5s, following theNEMA phase numbering scheme presented in Figure 4.1, for each time step the CTT is provided49and a graphical indication through red circles is shown where the signal phase would change.Table 4.2: CTTs to Demonstrate Signal Timing ChangeTimeStepAppr.2Appr.6Appr.4Appr.8Appr.1Appr.5Appr.3Appr.7SignalPhase1 15 0 5 0 20 0 0 0 32 30 25 25 5 25 0 0 5 13 45 60 45 10 0 5 0 15 14 20 70 65 20 0 10 0 25 15 0 45 85 30 0 0 0 35 26 0 30 110 45 0 5 0 45 27 5 50 70 15 0 15 0 25 28 10 80 5 20 0 35 10 0 19 20 130 15 15 0 50 0 0 110 10 115 25 30 0 40 0 0 111 5 100 35 45 0 55 0 0 112 15 55 45 65 0 50 0 5 213 55 0 55 90 25 30 0 10 2Figure 4.2: CTT Demonstration for instance of Signal Change, with circles identifying thetimes at which the signals change due to combination of cumulative travel times504.1.3 CTT Data Collection and AnalysisThe micro-simulation model was run 5 times with varying initial seeds each for the non-connectedvehicle environment as well as for each connected vehicle market penetration level in the connectedvehicle environment, applying the CTT algorithm. As will be discussed further in Chapter 5,evaluations are conducted where calibration has taken place. Data is collected for the East andWest movements of the intersection as these are the movements that the micro-simulation modelwas calibrated with (Essa and Sayed, 2015a). The mobility data was collected by measuring traveltimes at each approach to the intersection until the vehicle has completed its travel through thestop bar at the intersection. Conflict information is collected through the .trj file saved from theVISSIM micro-simulation for analyzing using SSAM.Table 4.3: Travel times at varying connected vehicle market penetration levels for the uncal-ibrated micro-simulation model after implementing the CTT algorithmVehicle Type NoCTT10%CTT30%CTT50%CTT70%CTT90%CTT100%CTTAvg. CV (s) N/A 17.4 16.9 16.0 15.7 15.1 15.0Avg. Non-CV (s) 24.3 22.7 19.0 17.3 16.5 15.7 N/AAvg. All Vehicles(s)24.3 20.0 18.0 16.6 16.1 15.4 15.0Table 4.4: Travel time improvements at varying connected vehicle market penetration lev-els for the uncalibrated micro-simulation model compared with the no-CTT micro-simulation after implementing the CTT algorithmVehicle Type 10% CTT 30% CTT 50% CTT 70% CTT 90% CTT 100% CTTAvg. CV -28% -30% -34% -35% -38% -38%Avg. Non-CV -7% -22% -29% -32% -35% N/AAvg. All Vehicles -18% -26% -31% -34% -37% -38%51Figure 4.3: Travel time improvements at varying connected vehicle market penetration lev-els for the uncalibrated micro-simulation model compared with the no-CTT micro-simulation after implementing the CTT algorithmFigure 4.4: Rear-end Conflicts for the uncalibrated micro-simulation model at varying con-nected vehicle penetration levels52Table 4.5: Time-to-Collision Conflicts at varying connected vehicle market penetration levelsfor the uncalibrated micro-simulation model after implementing the CTT algorithmTTC Threshold 0% CTT 10% CTT 30% CTT 50% CTT 70% CTT 90% CTT 100% CTT≤ 0.5 2 1 2 1 3 2 2≤ 0.6 3 2 2 2 4 2 2≤ 0.7 4 4 2 3 4 3 3≤ 0.8 4 5 2 3 5 4 4≤ 0.9 5 6 2 4 6 5 6≤ 1.0 7 7 4 4 8 8 7≤ 1.1 8 9 5 6 9 9 9≤ 1.2 10 12 8 11 16 14 14≤ 1.3 12 16 12 16 21 21 20≤ 1.4 14 22 20 24 28 30 26≤ 1.5 18 29 27 33 35 36 33≤ 1.6 24 38 40 41 46 45 42≤ 1.7 29 49 56 53 61 55 56≤ 1.8 59 85 90 84 92 83 85≤ 1.9 87 123 136 127 134 120 125≤ 2.0 107 143 159 147 156 143 146≤ 2.1 122 163 180 168 177 159 164≤ 2.2 139 181 193 183 192 169 177≤ 2.3 153 196 208 199 205 183 190≤ 2.4 165 209 224 214 221 196 202≤ 2.5 187 230 243 235 241 211 221≤ 2.6 205 252 265 257 264 229 245≤ 2.7 228 281 299 290 295 260 274≤ 2.8 260 318 335 326 335 294 308≤ 2.9 305 364 384 372 378 334 348≤ 3.0 353 416 432 420 420 371 394Table 4.6: Time-to-Collision Conflicts at varying connected vehicle market penetration lev-els for the uncalibrated micro-simulation model compared with the no-CTT micro-simulation after implementing the CTT algorithm (negative percent change indicatesimprovement)TTC Threshold 10% CTT 30% CTT 50% CTT 70% CTT 90% CTT 100% CTT≤ 0.5 -50% 0% -50% 50% 0% 0%≤ 1.0 8% -48% -40% 13% 20% 5%≤ 1.5 62% 48% 81% 95% 100% 80%≤ 2.0 35% 49% 38% 46% 34% 37%≤ 2.5 23% 30% 25% 29% 13% 18%≤ 3.0 18% 22% 19% 19% 5% 11%53Figure 4.5: Rear-end Conflicts for the uncalibrated micro-simulation model at varying con-nected vehicle penetration levels compared with no-CTT algorithm applied (negativepercent change indicates improvement)4.1.4 Evaluation of ResultsWhen considering the cumulative travel time intersection control application for a connected vehi-cle environment, it is expected that both mobility and safety will be improved. The intention of theapplication is to reduce wait times at the intersection and thus reduce queuing and the opportunityfor rear-end conflicts to occur. As the connected vehicle market penetration increases, travel timesare expected to further improve and rear-end conflicts are expected to further be reduced.The results for the travel times and safety evaluation are discussed in the following sections.4.1.4.1 Mobility EvaluationDue to the adaptive nature of the cumulative travel time algorithm, travel time improvements areobserved at all connected vehicle market penetration levels for both connected vehicles and non-54connected vehicles. The connected vehicles see a consistent travel time improvement of 28% to38% with greater travel time improvements at higher connected vehicle market penetration levels.The non-connected vehicles see improvements with a greater range of between 7% and 35%, withhigher connected vehicle market penetration levels showing greater travel time improvements.The travel time improvements for the combined connected vehicles and non-connected vehiclesrange between 18% and 38% improvement with higher connected vehicle market penetration levelsshowing the greater travel time improvements.Lower connected vehicle market penetration levels will result in non-connected vehicles waitingfor longer periods of time until the traffic signal is activated for their respective signal phase.Lee et al. (2013a) demonstrated travel time savings of 34% at 100% connected vehicle marketpenetration when the CTT algorithm is applied compared with the instance when the CTT algo-rithm is not applied. The intersection volume used by Lee et al. (2013a) to achieve these resultsis approximately 3,000 Vehicles per Hour (VPH). Comparing the results of this study with atravel time improvement of approximately 38% for a 5s time-step and 100% connected vehiclemarket penetration and an uncalibrated micro-simulation model, it shows that the algorithms per-form fairly similarly with the currently applied algorithm showing a greater improvement in traveltimes. At varying connected vehicle market penetration levels, travel time improvements presentedin this study show less variability and overall higher improvement than the results seen in Lee et al.(2013a). The algorithms used at lower connected vehicle market penetration levels are differentin that Lee et al. (2013a) uses a Kalman filter to account for non-connected vehicle cumulativetravel time estimates while this study focuses only on connected vehicles when determining thecumulative travel times and does not account for non-connected vehicles.The results when evaluating mobility follow what is expected when the connected vehicle technol-ogy is applied, specifically that travel times are improved.554.1.4.2 Traffic Conflicts EvaluationTable 4.6 and Figure 4.5 show that at no calibration the simulated level of safety based on themodeled surrogate safety measures is typically worse when the CTT algorithm is applied, withconflicts acting as surrogates for a higher probability of incidents occurring (TTC ≤1.5s) havingover a 90% increase in the number of simulated rear-end conflicts. At lower connected vehiclemarket penetration levels (e.g., 10% CTT or 30% CTT), there is higher variability with respect tonumber of conflicts observed at lower TTC thresholds, however at greater than 50% CTT connectedvehicle market penetration, there are no observed reduction in the number of simulated conflictscompared with the non-connected vehicle environment. The total intersection volume of the micro-simulation model used is approximately 3,000 VPH.These results do not align with what is expected, specifically that conflicts will be reduced athigher connected vehicle market penetration levels. This is likely due to the combination of theaggressive nature of the drivers within the VISSIM micro-simulation due to the default driverbehaviour parameters and more frequent signal changes at higher connected vehicle market pene-trations resulting in more changes to speed and acceleration as vehicles approach the intersections,and overall more conflicts identified.4.2 Cooperative Adaptive Cruise ControlCooperative Adaptive Cruise Control (CACC) is an application of V2V communication for thepurpose of controlling vehicles to improve capacity on the roadway. It works like Adaptive CruiseControl (ACC) in that it allows a vehicle to follow the vehicle in front of it and adjust speed basedon that lead vehicle’s behaviour. However, it expands on ACC by relying on the lead vehicle to“tell” the following vehicle what it is doing rather than having the following vehicle “sense” whatthe lead vehicle is doing. CACC allows for platoons of vehicles to form with short headways inorder to increase capacity on the roadway. A challenge with reducing headways is that shorter56headways typically result in a higher risk of rear-end collisions.The objective of this study is to investigate the ability to evaluate the safety of a connected vehicleapplication of a CACC algorithm applied to a freeway segment by using surrogate safety measuresas described currently in the SSAM and conflict analysis through a combination of the micro-simulation model VISSIM and the SSAM software packages.4.2.1 Simulation DevelopmentA micro-simulation model was developed to perform a safety evaluation of a CACC application.Within this micro-simulation, three vehicle types are included: Manually driven vehicles (ManualVehicles), ACC equipped and enabled vehicles, and CACC equipped and enabled vehicles. Allvehicles present in the micro-simulation are single occupant vehicles.Research has shown that the objective of CACC vehicles is to increase capacity through reducingthe headway between vehicles. The headways used in this thesis for ACC and CACC vehicles arebased on recommendations from research by Zhao and Sun (2013) and Van Arem et al. (2006).The headway time initially used for manual vehicles is the default value within VISSIM of 0.9s.To distinguish the different vehicle types within the simulation, colours have been applied basedon the vehicle type. Manual vehicles are blue, ACC vehicles are green and CACC vehicles are red.As will be discussed further, two additional colours (black and white) are used to distinguish whena CACC vehicle is in a platoon and whether it is following or leading the platoon. An example ofthe colours associated with the vehicles in the micro-simulation is provided in Figure 4.6. The laneconfiguration in the simulation is a 4-km long two lane freeway section with no access or egress.This configuration was used to provide a simplified simulation and for consistency in comparisonwith previous research conducted by Zhao and Sun (2013).To simulate V2V communications and to change the way the vehicles react, the VISSIM driver be-57Figure 4.6: Example of vehicle platooning micro-simulation including vehicle colourshaviour model was modified. A DLL was created both for the CACC and the ACC vehicle types tosimulate the computer controlling the vehicles rather than having a human driver in control. WithinVISSIM, the DLL assumes control of certain parameters and allows for user defined or user pro-grammed values for specific parameters such as following distance, acceleration/deceleration, andlane change behaviour to be applied to each VISSIM time step. Within this micro-simulation,the CACC vehicles are required to behave in conjunction with the leading vehicle and with ea-chother, therefore the DLL identifies a vehicle to lead a platoon and causes other surroundingCACC equipped vehicles to accelerate or decelerate and change lanes at an appropriate time inorder to join and continue in a platoon of CACC vehicles.This simulation assumes that all CACC platoons will form and stay in the left lane, considered thefast lane. The vehicle inputs into the simulation have a speed distribution around 100 km/h, definedwithin VISSIM, and the vehicles that form a platoon will conform to the desired speed of the leadvehicle. The CACC algorithm used to calculate acceleration of a following vehicle in order to forma platoon is based on Zhao and Sun (2013) and Van Arem et al. (2006). The acceleration modelused for this simulation is as shown in Equations 4.2.1 and 4.2.2:ac = ka ∗ap+ kv ∗ (vp− v f )+ ks ∗ (s− v∗ td) (4.2.1)a = max[amin,min(ac,amax)] (4.2.2)Where:58ac is the control acceleration with the linear function;a is the acceleration in the next step of the objective vehicle;ap is the acceleration of the preceding vehicle;vp is the speed of the preceding vehicle;v f is the speed of the following vehicle;s is the current space between the objective vehicle and its preceding vehicle;amax is the maximum allowed acceleration;amin is the maximum allowed deceleration;ka, kv and ks are constant gains, all greater than zero.Equations 4.2.1 and 4.2.2 are used for simulating ACC vehicles as well through removing the kaand ap terms.In order to design the micro-simulation of the CACC technology, algorithms were developed toguide changes to driver behaviour based on vehicle type and position with respect to lane andsurrounding vehicles. These algorithms are categorized into three states: 1) normal driving state,2) lead platoon state, and 3) join platoon state.4.2.2 Driving StatesNormal Driving StateThe Normal Driving State is when the vehicle is not controlled by adaptive cruise control or coop-erative adaptive cruise control. No additional control is applied and all vehicles in this state behaveas manually driven vehicles.59Lead Platoon StateThe Lead Platoon State is when the CACC vehicle has been designated as a leader of the platoon.In this state, the lead vehicle will drive using adaptive cruise control towards the vehicle in frontof it, using ka = 0 and td = 1.4 from Equation 4.2.1. If there is no vehicle immediately in front, itwill drive as a manually driven vehicle. The lead platoon state initiates a vehicle colour change toblack to visually distinguish in the micro-simulation that the vehicle is leading the platoon.Join Platoon StateThe Join Platoon State is when the CACC vehicle is in the process of joining a platoon or iscurrently in a platoon, but is not leading the platoon. The CACC vehicle when it is in the JoinPlatoon state uses the values of ka = 1 and td = 0.5 from Equation 4.2.1. The join platoon stateinitiates a vehicle colour change to white to visually distinguish that the vehicle is joining or hasjoined a platoon.4.2.3 CACC Driver Behaviour AlgorithmsThere are a few scenarios that would account for a vehicle forming or entering into a CACCplatoon. There are also specific requirements that must be met in order for this to occur. Thesescenarios and requirements form the logic of when vehicle platoons are formed and when theydisband. The logic is described below:• If a CACC vehicle is in the left lane, it checks the vehicle type in front of it and behind it.– if the vehicle in front of it is not a CACC vehicle, it flags itself as being able to be alead vehicle.– if the vehicle behind it is a CACC vehicle, it initiates a platoon and becomes a leadvehicle.60– if the vehicle in front of it is a CACC vehicle, it requests to join a platoon with thatvehicle. VISSIM is limited within the DLL to find information about near vehicles forup to two upstream and two downstream, on up to two lanes on both sides of the currentlane. This limits the ability within the DLL to model driver behaviour up to the leadvehicle rather than simply the vehicle in front of the vehicle in question.• If a CACC vehicle is in the right lane, it checks the vehicle type to the left of it and in frontand behind it.– if the vehicle to the left and in front of it is not a CACC vehicle, it continues to drivewith the system defined driver behaviour model.– if the vehicle to the left and in front of it is a CACC vehicle, it would like to join aplatoon:∗ If the vehicle type to the left and behind it is not a CACC vehicle, it changes lanesand joins the platoon behind the CACC platoon vehicle.∗ If the vehicle type to the left and behind it is a CACC vehicle, it waits until the endof the CACC platoon to change lanes and join the CACC platoon. Within the DLL,ideally we would like to limit platoon size to 6 vehicles, with 5 gaps; however, thelimitations with finding information about nearby vehicles limits the ability to dothis.• If a platoon is already formed and a vehicle would like to exit the platoon, that vehiclenotifies the lead vehicle and then initiates the exit manoeuver.For each vehicle, the DLL collects information for each time step in order to change the driverbehaviour based on surrounding vehicles.4.2.4 CACC Data Collection and AnalysisA total of ten penetration levels for CACC equipped vehicles were simulated with five simulationruns of identical vehicle volumes with varying initial seeds to randomize the simulation, generating61fifty (50) simulation runs in total. For each CACC penetration level, the ACC vehicle penetrationremains at 10%. The penetration of the three vehicle types in these simulations are presented inTable 4.7.Table 4.7: CACC Simulation Input Connected Vehicle PenetrationsVehicleTypeNoCV10%CV20%CV30%CV40%CV50%CV60%CV70%CV80%CV90%CVManual 90% 80% 70% 60% 50% 40% 30% 20% 10% 0%ACC 10% 10% 10% 10% 10% 10% 10% 10% 10% 10%CACC 0% 10% 20% 30% 40% 50% 60% 70% 80% 90%For the simulated freeway, a basic freeway segment was used as defined in the Highway CapacityManual (Highway Capacity Manual, 2000) with a total vehicle volume of 3,300 per hour for a onehour period, simulating an uninterrupted level of service of between B and C. In these conditions,at the default simulation parameters, VISSIM shows no rear-end conflicts when evaluated throughSSAM. To provide a meaningful evaluation, a traffic delay was simulated by inserting a very slowmoving vehicle into the right hand lane.The simulation was run for each CACC connected vehicle penetration level. For each CACCconnected vehicle penetration level, 5 simulations were run with different initial seeds, beginningat 1 and being incremented by 20 for each subsequent simulation. The length of the simulationswere 4,600 seconds, with 1,000 seconds seed time for the simulation to become in a steady state.The slow moving vehicle was inserted in the right hand lane at the 2,600 second mark, inside of a750m section where data was collected for evaluation purposes.The travel time of each vehicle was captured through the 750m section where the traffic delaywas simulated. Additionally, a trajectory file (.trj) was produced for each simulation run whichwas evaluated through conflict analysis using SSAM. The mobility and safety evaluations are per-formed based on the period of time when the traffic delay was prominent, between 2,600 secondsand 3,000 seconds. The simulation was evaluated for travel time and safety measures of improve-ment for each CACC penetration level where CACC vehicles were included in the simulation.62Results are presented in Table 4.8 and Table 4.9 for mobility and in Table 4.10 and Table 4.11 withrespect to traffic conflicts. Improvements for travel times are measured against the total travel timeobserved with no CACC equipped vehicles present, and for traffic conflicts it is compared withthe total rear-end conflicts observed during where there are no CACC equipped vehicles present.Improvements are measured only over the period of time when the traffic delay was simulated.Table 4.8: Travel times per connected vehicle market penetration levelVehicleTypeNoCV10%CV20%CV30%CV40%CV50%CV60%CV70%CV80%CV90%CVTotal TT 73.5 66.8 68.3 72.2 68.3 68.0 61.7 47.0 45.2 37.9Man. TT 72.3 70.7 72.7 74.7 74.9 73.4 65.7 49.4 47.1 N/AACC TT 74.8 69.3 69.2 76.7 68.3 69.8 64.3 50.2 48.7 40.6CACC TT N/A 60.5 63.0 65.4 61.8 60.7 55.0 41.3 39.8 35.1Total SD 11.8 10.5 13.3 12.2 10.4 13.1 8.9 6.8 7.1 4.1Man. SD 11.2 11.0 13.2 10.4 9.8 15.3 9.6 5.7 7.8 N/AACC SD 13.6 8.8 14.9 14.2 8.1 11.0 6.1 7.0 4.7 3.4CACC SD N/A 10.6 12.9 11.0 10.4 11.9 7.8 4.3 5.9 2.6Figure 4.7: Average Travel Times Per CACC Market Penetration Level and Vehicle Type63Figure 4.8: Percent Change in Travel Times Per CACC Market Penetration Level Comparedwith The Average Travel Time for No CACCFigure 4.9: Rear-End conflicts by time-to-collision threshold64Table 4.9: Percent change in travel times per connected vehicle market penetration level com-pared with No CACC micro-simulationVehicleType10%CV20%CV30%CV40%CV50%CV60%CV70%CV80%CV90%CVTotal 9% 7% 2% 7% 8% 16% 36% 40% 49%Man. 4% 1% -2% -2% 0% 11% 33% 38% N/AACC 6% 6% -4% 7% 5% 13% 32% 35% 45%CACC 18% 14% 11% 16% 17% 25% 44% 47% 52%Table 4.10: Rear-end TTC conflicts at varying connected vehicle (CV) penetration levelsTTCThresholdNOCV10%CV20%CV30%CV40%CV50%CV60%CV70%CV80%CV90%CV≤ 0.5 8 12 12 20 16 12 8 18 12 6≤ 0.6 12 12 16 24 20 20 12 22 19 10≤ 0.7 17 20 28 28 24 27 16 26 23 10≤ 0.8 26 29 38 32 32 32 22 31 29 14≤ 0.9 32 42 46 40 38 42 26 35 33 20≤ 1.0 50 59 56 45 44 52 34 44 38 24≤ 1.1 73 74 71 55 51 66 46 52 42 28≤ 1.2 96 108 103 67 62 76 51 58 46 28≤ 1.3 129 149 131 85 71 87 58 66 55 32≤ 1.4 184 190 167 102 86 100 67 70 59 44≤ 1.5 248 226 210 124 115 114 79 80 69 48≤ 1.6 308 276 263 173 144 135 88 90 76 54≤ 1.7 387 339 315 211 176 162 99 101 84 66≤ 1.8 467 412 377 260 221 195 116 109 98 71≤ 1.9 560 494 443 319 268 224 137 118 108 78≤ 2.0 675 582 529 387 327 272 162 129 118 96≤ 2.1 795 676 624 462 408 331 189 148 134 106≤ 2.2 910 781 725 563 487 383 232 174 155 122≤ 2.3 1,045 891 847 680 579 458 275 199 176 135≤ 2.4 1,207 1,014 987 822 696 552 326 219 204 147≤ 2.5 1,395 1,191 1,130 986 841 663 390 250 224 176≤ 2.6 1,595 1,383 1,318 1,169 1,020 811 495 291 250 194≤ 2.7 1,855 1,620 1,547 1,408 1,234 976 586 349 293 217≤ 2.8 2,178 1,919 1,804 1,759 1,444 1,168 722 415 352 250≤ 2.9 2,483 2,266 2,167 2,112 1,719 1,390 881 494 409 303≤ 3.0 2,856 2,690 2,631 2,521 2,129 1,692 1,107 655 512 36965Table 4.11: Percent Change to Rear-end TTC conflicts at varying connected vehicle (CV)penetration levels Compared With No CACCTTCThreshold10%CV20%CV30%CV40%CV50%CV60%CV70%CV80%CV90%CVTTC ≤ 0.5 50% 50% 150% 100% 50% 0% 125% 50% -25%TTC ≤ 1.0 18% 13% -10% -12% 4% -32% -11% -24% -52%TTC ≤ 1.5 -9% -16% -50% -54% -54% -68% -68% -72% -81%TTC ≤ 2.0 -14% -22% -43% -51% -60% -76% -81% -83% -86%TTC ≤ 2.5 -15% -19% -29% -40% -52% -72% -82% -84% -87%TTC ≤ 3.0 -6% -8% -12% -25% -41% -61% -77% -82% -87%Figure 4.10: Percent Change in Rear-End Conflicts by TTC Threshold for varying CACCMarket Penetration Level Compared with No CACC (negative percentage indicatesimprovement)4.2.5 Evaluation of ResultsThe results of the micro-simulation model are evaluated based on two measures of improvement: 1)Improvement to mobility, and 2) Reduction in simulated traffic conflicts as a surrogate for safety.Expected results are that at higher connected vehicle market penetrations both travel times andsimulated rear-end conflicts will be reduced.664.2.5.1 Mobility EvaluationThe mobility of the different penetration levels are evaluated based on the network travel times.Figure 4.7 displays a visual representation of the travel times for varying CACC connected vehiclemarket penetration levels for the different vehicle types and the average travel times between allvehicles. Figure 4.8 displays a visual representation of travel time improvements compared withthe total average travel time with no CACC vehicles present at varying CACC penetration levelsfor Manual Vehicles, ACC vehicles, CACC vehicles and the average for all vehicles. The resultsshow that as the penetration level of CACC vehicles increases the average travel time reduces,thus improving mobility. Additionally, Table 4.8 outlines the travel times for each vehicle type ateach CACC connected vehicle market penetration level, as well as the standard deviations for thesetravel times. The standard deviations are shown to be reduced at higher CACC connected vehiclemarket penetration levels, indicating more reliable travel time through the area of congestion.Comparison of mobility results show that the improvements vary by vehicle type and CACC pene-tration rate. Travel times for the total network (including all vehicle types) as well as for individualvehicles types are compared with the No CACC penetration rate travel time for the network. At allCACC penetration rates there are savings for the CACC equipped vehicles. Consistent travel timesavings are seen for all vehicle types after the CACC penetration rate reaches 60% indicating thatthis is the point at which mobility improvements become essentially saturated. At a 90% CACCpenetration rate, the total network sees improvements to travel times by nearly 50%.4.2.5.2 Traffic Conflicts EvaluationRear-end conflicts were the measure used to identify safety improvements under the connectedvehicle environment for a CACC application when a delay in traffic is observed. Rear-end conflictsare evaluated at TTC thresholds of 0.5s to 3.0s, in 0.5s increments, with lower TTC thresholdsrepresenting a higher conflict severity (higher probability of a collision occurring).67Table 4.11 provides the change in traffic conflicts based on the percent change in rear-end conflictsfor different TTC thresholds compared to the No-CACC micro-simulation.Figure 4.10 provides a visual summary of the improvement in the total number of conflicts foreach CACC penetration level. As the CACC penetration level increases, there is an increase in theimprovement to the total number of conflicts observed compared to the scenario with no CACCequipped vehicles. After a 60% CACC penetration level is reached, the improvements over thescenario where no CACC equipped vehicles are present appear to level off for higher TTC thresh-olds (2.0s and above), demonstrating that the safety improvements do not follow a linear trendat higher CACC penetration levels. At lower TTC thresholds, there is volatility throughout thedifferent CACC market penetration levels, likely due to the lower absolute number of simulatedconflicts resulting in larger percentage changes.Because of the nature of the CACC vehicles, headways of 0.5s are being used which increasesthe likelihood of measuring rear-end conflicts at very low TTC thresholds while they may not beactual rear-end conflicts as they are instances accounted for in the acceleration model described inEquation 4.2.1.4.2.6 Micro-Simulation Sensitivity AnalysisSensitivity analysis was performed on the driver behaviour parameters and the acceleration co-efficients to evaluate the variability of the micro-simulation model when these components aremodified.4.2.6.1 Driver Behaviour ParametersVISSIM contains many driver behaviour parameters (about 190). There are 30 specific parametersrelated to driver behaviour. In a study conducted by Essa and Sayed (2015a), sensitivity analysiswas performed in order to determine the most important driver behaviour parameters related to68safety. While Essa and Sayed (2015a) looked specifically at intersections, some of the parametersare still relevant to the CACC simulations and therefore additional modeling is conducted in orderto evaluate the differences and sensitivities based on changing these parameters.Sensitivity analysis has been performed in previous research on the VISSIM driver behaviour pa-rameters, specifically those that affect the aggressiveness and defensiveness on the roadway forfreeway applications (Gomes et al., 2004; Habtemichael and Picado-Santos, 2013; Hadi et al.,2007). The VISSIM driver behaviour parameters are important for calibration purposes to en-sure that the micro-simulation model adequately represents conditions in the real world. Mod-ifying these parameters can have a significant effect on the outcome of the micro-simulation.Habtemichael and Picado-Santos (2013) demonstrates that there is significant impact to safetywhen VISSIM parameter CC1 is modified. The VISSIM parameter CC1 is the headway parameterand is said to have the most influence over freeway capacity (Gomes et al., 2004). The defaultVISSIM CC1 value is 0.9s. Hadi et al. (2007) analyses the the change in capacity of a roadwayin VISSIM when modifying the CC1 parameter and reviews the capabilities of different micro-simulators to simulate an incident.The two driver behaviour parameters that affect the safety distance in VISSIM are CC0 and CC1.The safety distance is given by Equation 4.2.3.dx sa f e =CC0+CC1∗ speed (4.2.3)CC0 is the parameter that determines the stopped distance, or the distance that a vehicle maintainsbehind a stopped vehicle on a freeway, with a default value in VISSIM of 1.5m. CC1 is theparameter that specifies headway, with a default value in VISSIM of 0.9s. At higher speeds theCC1 parameter is the dominant component of Equation 4.2.3 and is the parameter that is beingmodified to demonstrate the changes to the outcomes of the micro-simulation model as part of theinput parameter sensitivity analysis.69Gomes et al. (2004) suggests that with reasonable values of dx sa f e, the freeflow speed and thedefault value for CC0, CC1 is calculated to be 1.5s. Habtemichael and Picado-Santos (2013)demonstrates the changes in the safety through rear-end conflicts at CC1 values ranging between0.5s and 1.3s. Hadi et al. (2007) demonstrates the changes in capacity at CC1 values ranging from0.5s to 1.5s.Within this study sensitivity analysis is performed on the simulated conflicts when changing theCC1 value to identify whether the improvements found with the default CC1 value in VISSIM of0.9s hold when CC1 is changed. The CC1 parameter is varied between 0.7s and 1.5s and results arepresented as a comparison to the default VISSIM Parameter of 0.9s for CACC market penetrationrates ranging from 0% to 90% for the TTC≤1.5s. Comparison results for travel times and rear-endconflicts are presented in Tables 4.12 and 4.13, and Tables 4.14 through 4.21 respectively.Table 4.12: Travel Time Variations Based on Varying CC1 ParameterCC1 Parameter NO CACC 10% CACC 30% CACC 50% CACC 70% CACC 90% CACCCC1 = 0.7 65 61 63 54 47 38CC1 = 1.1 81 75 78 70 57 36CC1 = 1.3 83 84 86 75 54 37CC1 = 1.5 92 89 89 79 63 38Table 4.13: Travel Time Variations Based on Varying CC1 Parameter Value Compared withDefault VISSIM Parameter (Reductions are Improvements)CC1 Parameter No CACC 10% CACC 30% CACC 50% CACC 70% CACC 90% CACCCC1 = 0.7 12% 9% 13% 20% 1% 0%CC1 = 1.1 -11% -12% -7% -3% -22% 4%CC1 = 1.3 -13% -25% -20% -10% -15% 2%CC1 = 1.5 -25% -33% -23% -16% -34% -1%Table 4.14: Rear-End Conflicts for 0.7s Headway at Varying CACC Penetration LevelsTTC Threshold No CACC 10% CACC 30% CACC 50% CACC 70% CACC 90% CACC≤ 0.5 29 24 14 12 17 8≤ 1.0 110 96 87 49 43 34≤ 1.5 415 321 276 127 84 60≤ 2.0 1023 755 667 336 148 90≤ 2.5 1869 1493 1338 713 350 168≤ 3.0 2233 2010 1496 646 483 33170Table 4.15: Rear-End Conflicts for 0.7s Headway Compared with Default VISSIM ParameterTTC Threshold No CACC 10% CACC 30% CACC 50% CACC 70% CACC 90% CACC≤ 0.5 267% 100% -30% 0% -4% 33%≤ 1.0 121% 64% 93% -6% -4% 42%≤ 1.5 67% 42% 122% 11% 6% 25%≤ 2.0 52% 30% 73% 24% 15% -6%≤ 2.5 34% 25% 36% 8% 40% -4%≤ 3.0 -22% -25% -41% -62% -26% -10%Table 4.16: Rear-End Conflicts for 1.1s Headway at Varying CACC Penetration LevelsTTC Threshold No CACC 10% CACC 30% CACC 50% CACC 70% CACC 90% CACC≤ 0.5 4 8 24 20 8 8≤ 1.0 62 37 42 36 37 28≤ 1.5 249 153 100 71 66 52≤ 2.0 565 381 260 150 112 79≤ 2.5 1150 894 686 353 195 125≤ 3.0 2333 2194 1805 916 543 281Table 4.17: Rear-End Conflicts for 1.1s Headway Compared with Default VISSIM ParameterTTC Threshold No CACC 10% CACC 30% CACC 50% CACC 70% CACC 90% CACC≤ 0.5 -50% -33% 20% 67% -56% 33%≤ 1.0 24% -37% -6% -31% -17% 17%≤ 1.5 0% -32% -20% -38% -17% 8%≤ 2.0 -16% -35% -33% -45% -13% -17%≤ 2.5 -18% -25% -30% -47% -22% -29%≤ 3.0 -18% -18% -28% -46% -17% -24%Table 4.18: Rear-End Conflicts for 1.3s Headway at Varying CACC Penetration LevelsTTC Threshold No CACC 10% CACC 30% CACC 50% CACC 70% CACC 90% CACC≤ 0.5 12 8 4 8 12 11≤ 1.0 60 41 35 24 40 25≤ 1.5 265 153 88 54 68 55≤ 2.0 613 398 232 115 111 84≤ 2.5 1158 871 596 248 201 143≤ 3.0 2233 2010 1496 646 483 331Table 4.19: Rear-End Conflicts for 1.3s Headway Compared with Default VISSIM ParameterTTC Threshold No CACC 10% CACC 30% CACC 50% CACC 70% CACC 90% CACC≤ 0.5 50% -33% -80% -33% -33% 89%≤ 1.0 20% -30% -21% -54% -10% 3%≤ 1.5 7% -32% -29% -53% -15% 14%≤ 2.0 -9% -32% -40% -58% -13% -12%≤ 2.5 -17% -27% -40% -63% -20% -19%≤ 3.0 -22% -25% -41% -62% -26% -10%71Table 4.20: Rear-End Conflicts for 1.5s Headway at Varying CACC Penetration LevelsTTC Threshold No CACC 10% CACC 30% CACC 50% CACC 70% CACC 90% CACC≤ 0.5 4 4 8 8 4 16≤ 1.0 52 44 28 24 24 32≤ 1.5 215 152 77 45 50 55≤ 2.0 576 418 210 105 92 84≤ 2.5 1043 833 450 226 159 134≤ 3.0 2077 1734 1032 477 366 317Table 4.21: Rear-End Conflicts for 1.5s Headway Compared with Default VISSIM ParameterTTC Threshold No CACC 10% CACC 30% CACC 50% CACC 70% CACC 90% CACC≤ 0.5 -50% -67% -60% -33% -78% 167%≤ 1.0 5% -25% -38% -54% -46% 33%≤ 1.5 -13% -33% -38% -60% -38% 14%≤ 2.0 -15% -28% -46% -61% -29% -13%≤ 2.5 -25% -30% -54% -66% -36% -24%≤ 3.0 -27% -36% -59% -72% -44% -14%Figure 4.11: Percent Change in Rear-End Conflicts by TTC Threshold for varying CACCMarket Penetration Level at a 0.7s Headway Compared with Default VISSIM Head-way Parameter72Figure 4.12: Percent Change in Rear-End Conflicts by TTC Threshold for varying CACCMarket Penetration Level at a 1.1s Headway Compared with Default VISSIM Head-way ParameterFigure 4.13: Percent Change in Rear-End Conflicts by TTC Threshold for varying CACCMarket Penetration Level at a 1.3s Headway Compared with Default VISSIM Head-way Parameter73Figure 4.14: Percent Change in Rear-End Conflicts by TTC Threshold for varying CACCMarket Penetration Level at a 1.5s Headway Compared with Default VISSIM Head-way Parameter4.2.6.2 Acceleration CoefficientsThe second task for sensitivity analysis was to modify the acceleration coefficients provided inEquation 4.2.1, namely ka, kv, and ks. For this sensitivity analysis the hardcoded values within theDLL are modified for each set of simulation runs. The values used within the base simulationsare as were used by Zhao and Sun (2013) as ka = 1.0, kv = 0.58, and ks = 0.1. Four additionalcomparisons are conducted as described below, keeping ka constant at 1.0. These differences inacceleration coefficients were chosen based on the sensitivity analysis performed in Van Aremet al. (2006). The additional four different combinations of acceleration coefficients used are asfollows:Comparison 1: ka=1.0, kv=1.00, and ks=0.1Comparison 2: ka=1.0, kv=2.00, and ks=0.1Comparison 3: ka=1.0, kv=0.58, and ks=0.2Comparison 4: ka=1.0, kv=0.58, and ks=0.374Comparisons were performed at a 50% CACC penetration level to demonstrate the sensitivity ofthe acceleration parameters on safety through rear-end conflicts, and travel times. The differencein travel times and rear-end conflicts results are presented in Table 4.22, comparing the modifiedacceleration comparisons with the initial values used.Table 4.22: Changes to Travel Times and Rear-End Conflicts for CACC Acceleration Param-eters at 50% CACC PenetrationMeasure Comparison 1 Comparison 2 Comparison 3 Comparison 4Total TT 2% 7% 1% 0%Man. Vehicle TT 2% 8% 0% 2%ACC Vehicle TT 1% 7% 1% -2%CACC Vehicle TT 1% 6% 3% 2%Rear-end≤3.0s -21% -11% -22% -43%Rear-end≤2.0s -11% -8% -25% -54%Rear-end ≤1.5s -11% -10% -21% -56%4.2.7 Sensitivity Analysis EvaluationResults of the travel time and safety improvements are presented in Tables 4.8 through 4.22 and inFigures 4.7 through 4.14.4.2.7.1 Mobility EvaluationWhen modifying the driver behaviour parameters within VISSIM, system wide travel times areimproved at lower CACC penetration levels for a headway time (CC1) of 0.7, but improvementsdeteriorate at 70% CACC penetration level when compared with the same CACC penetration levelsand using the default VISSIM driver behaviour parameter value. At higher headway times, thetravel time savings show disimprovements as the CC1 value increases, travel times get longer anddisimprovements become greater. The results of this sensitivity analysis are expected as increasingthe CC1 value is in essence causing the driver behaviour to be less aggressive while decreasing theCC1 value causes the driver behaviour to be more aggressive.75When modifying the acceleration coefficients under Equation 4.2.1, only the 50% CACC penetra-tion level was evaluated. It was found that improvements to travel times vary, but not significantly(less than 10% for all scenarios) indicating that the acceleration parameters for the CACC equippedvehicles do not greatly impact the overall travel time of the system.4.2.7.2 Traffic Conflicts EvaluationWhen evaluating the results of the sensitivity analysis, shorter headway times have significantimpacts to the safety evaluation results. Comparisons are made for different headway times anddifferent CACC penetration levels compared with the same CACC penetration level for the defaultVISSIM driver behaviour parameter for headway time. Headway times longer than the defaultVISSIM parameter (i.e., 1.1s, 1.3s and 1.5s) show improvements over the default VISSIM valuefor nearly all CACC penetration levels. At higher CACC penetration levels the improvements aregenerally not as great as with lower CACC penetration levels, primarily due to the reduction inmanually driven vehicles within the simulation that are affected by the changes to the headwayparameters.The acceleration coefficients chosen based on Zhao and Sun (2013) and Van Arem et al. (2006)produce less rear-end conflicts than when compared with modifications of the acceleration coeffi-cients at TTC thresholds of ≤ 1.5s and greater. Varying the acceleration coefficients demonstrateworsening with respect to to rear-end conflicts at all TTC thresholds measured, specifically 1.5s,2.0s and 3.0s, indicating the acceleration coefficients chosen are a good choice when applying theCACC algorithm from a safety perspective.76Chapter 5Calibrated Connected Vehicle SimulationsThis chapter describes the micro-simulation of a connected vehicle environment after calibrationto real-world conditions. Of the two connected vehicle micro-simulations detailed in Chapter 4,the cumulative travel time intersection control connected vehicle environment was developed us-ing a real-world intersection with real traffic information that has been used for calibration. Thecooperative adaptive cruise control connected vehicle environment is a theoretical implementationwithout any readily available real-world conditions that can be used for calibration purposes.To demonstrate that calibration of a non-connected vehicle environment through modification ofVISSIM and other parameters has a significant impact to the simulated effects of connected vehicleapplications, for both safety and mobility, modifications to the parameters were implemented usingresults of a two-step calibration procedure conducted by Essa and Sayed (2015a), firstly applyingcalibration parameters for delay and arrival rates, and secondly applying calibration parameters forobserved conflicts.775.1 Cumulative Travel Time Intersection ControlThe evaluation of the CTT algorithm in relation to connected vehicles was performed in Section 4.1using the default VISSIM parameters with no calibration conducted. This section will serve toperform the micro-simulation after the first step calibration and second step calibration, calibratingfor delays and arrival rates, and for observed conflicts respectively. The objective of this review isto determine if calibrating the micro-simulation model provides a better representation of the realworld than not calibrating the micro-simulation model.Essa and Sayed (2015a) calibrated the VISSIM micro-simulation model using a two step process.Section 4.1 provided the uncalibrated comparison. In this section, the comparisons are performedat two stages: 1) First Step Calibration focusing on delays and arrival rates compared with real-world delays, and 2) Second Step Calibration focusing on VISSIM safety parameters to correlatewith observed conflicts in the field.5.1.1 Intersection First Step CalibrationThe first step calibration aims to ensure that the field measured parameters are represented withinthe simulation. There are many parameters that can be used for this calibration, however it isvery difficult to optimize many parameters at once. The calibration parameters used are basedon research by Essa and Sayed (2015a), in which the average delay per vehicle was selected tobe optimized, primarily as it is the key measure for evaluating the Level-of-Service (LOS) forsignalized intersections (Highway Capacity Manual, 2000). Dummy intersections were introducedto obtain appropriate arrival times to the East and West approaches. The first step calibration isa calibration step commonly performed in micro-simulation as it is required in order to obtainreasonable results from the simulation.785.1.2 Intersection Second Step CalibrationThe second step calibration is intended to enhance the correlation between conflicts seen in thefield and in the simulation. Essa and Sayed (2015a) performed the second step calibration throughsensitivity analysis on VISSIM parameters to understand which have the biggest effect on thesimulated rear-end conflicts with subsequent analysis performed through a genetic algorithm todetermine the best values. Essa and Sayed (2015a) found the most important six parameters tobe CC0 (standstill distance), CC1 (headway time), CC4 & CC5 (negative and positive followingthresholds), the reduction factor for safety distance close to stop line, start upstream of stop line,and desired deceleration. These six parameters will be considered as the safety-related param-eters for signalized intersections as they affect the desired safety distance between each pair ofconsecutive vehicles.Subsequent to the evaluation without calibrating the micro-simulation model, previously discussedin Chapter 4, to evaluate the effects of calibration, evaluation of delays and safety were performedon the intersection in two different scenarios using both the basic (not connected vehicle) scenarioas well as the connected vehicle scenario:1. First Step Calibrated (to account for vehicle arrival times and delays)2. Second Step Calibrated (to account for vehicle conflicts)The default and the calibrated parameter values used for the second calibration step are providedin Table 5.1.Table 5.1: Default VISSIM Driver Behaviour ParametersParameter Units Default Calibrated ValueCC0 metres 1.50 2.50CC1 seconds 0.9 1.3CC4 & CC5 — ± 0.35 ± 0.25Reduction factor for safety distance close to stop line — 0.60 0.75Start upstream of stop line metres 100 110Desired deceleration m/s2 -2.80 -2.80795.1.3 Automated Video-Based Computer Vision AnalysisAutey et al. (2012) and several other researchers (Saunier and Sayed, 2006, 2007, 2008; Saunieret al., 2010) describe the computer vision process for automated analysis through video capture oftraffic. A detailed description of the analysis process using computer vision is shown in Figure 5.1(Tageldin et al., 2014).Figure 5.1: Process outlining computer vision methodology for automated video analysis(Tageldin et al., 2014)Essa and Sayed (2015a) details the evaluation on the intersection under review, explaining how thevolumes, signal timing and calibration was conducted using computer vision. A visual representa-tion of the conflicts observed for the calibration dataset is presented in Figure 5.2.5.1.4 CTT Data Collection and AnalysisData is collected for the East and West movements of the intersection as these are the movementscalibrated by Essa and Sayed [5]. The mobility data was collected by measuring travel times ateach approach to the intersection until the vehicle has completed its travel through the stop barat the intersection. Conflict information is collected through the .trj file saved from the VISSIMmicro-simulation for analyzing using SSAM.During the calibration phase of this micro-simulation, the model was run for two scenarios: 1) firststep calibrated, and 2) second step calibrated, both for the non-CTT algorithm being applied as wellas the CTT algorithm being applied. Subsequent to the second step calibration being performed,80Figure 5.2: Heat maps of calibration data set using Computer Vision and simulated conflictsused for calibration (Essa and Sayed, 2015a)81additional CTT applied micro-simulations were performed at varying time-step intervals in orderto evaluate sensitivities to when the signal controller updates, as well as at varying connectedvehicle penetration levels to evaluate the connected vehicle application without perfect marketpenetration. The resulting rear-end conflicts are presented in Table 5.6 and Table 5.7 and the rear-end conflict improvements are presented in Table 5.8 and Table 5.9. Graphical representationsof the rear-end conflicts and improvements are presented in Figures 5.5 and 5.6, and Figures 5.7and 5.8 respectively.Table 5.2: Travel times at varying connected vehicle market penetration levels for the firststep calibrated micro-simulation model after implementing the CTT algorithmVehicle Type NoCTT10%CTT30%CTT50%CTT70%CTT90%CTT100%CTTAvg. CV (s) N/A 18.0 16.7 15.9 15.2 15.0 14.9Avg. Non-CV (s) 26.0 22.6 18.7 16.6 15.8 15.8 N/AAvg. All Vehicles(s)26.0 20.3 17.7 16.3 15.5 15.4 14.9Table 5.3: Travel times at varying connected vehicle market penetration levels for the secondstep calibrated micro-simulation model after implementing the CTT algorithmVehicle Type NoCTT10%CTT30%CTT50%CTT70%CTT90%CTT100%CTTAvg. CV (s) N/A 18.6 17.4 16.7 15.7 15.2 15.3Avg. Non-CV (s) 25.8 22.8 19.3 18.0 16.7 16.2 N/AAvg. All Vehicles(s)25.8 20.7 18.3 17.4 16.2 15.7 15.3Table 5.4: Travel time improvements at varying connected vehicle market penetration levelsfor the first step calibrated micro-simulation model compared with the no-CTT micro-simulation after implementing the CTT algorithmVehicle Type 10% CTT 30% CTT 50% CTT 70% CTT 90% CTT 100% CTTAvg. CV -31% -36% -39% -41% -42% -43%Avg. Non-CV -13% -28% -36% -39% -39% N/AAvg. All Vehicles -22% -32% -37% -40% -41% -43%82Figure 5.3: Travel time improvements at varying connected vehicle market penetration levelsfor the first step calibrated micro-simulation model compared with the no-CTT micro-simulation after implementing the CTT algorithmFigure 5.4: Travel time improvements at varying connected vehicle market penetration lev-els for the second step calibrated micro-simulation model compared with the no-CTTmicro-simulation after implementing the CTT algorithm83Table 5.5: Travel time improvements at varying connected vehicle market penetration levelsfor the second step calibrated micro-simulation model compared with the no-CTT micro-simulation after implementing the CTT algorithmVehicle Type 10% CTT 30% CTT 50% CTT 70% CTT 90% CTT 100% CTTAvg. CV -28% -33% -35% -39% -41% -41%Avg. Non-CV -12% -25% -30% -35% -37% N/AAvg. All Vehicles -20% -29% -33% -37% -39% -41%Table 5.6: Time-to-Collision Conflicts at varying connected vehicle market penetration levelsfor the first step calibrated micro-simulation model after implementing the CTT algo-rithmTTC Threshold No CTT 10% CTT 30% CTT 50% CTT 70% CTT 90% CTT 100% CTT≤ 0.5 8 3 3 3 1 2 2≤ 0.6 11 4 5 4 3 3 2≤ 0.7 14 5 7 5 5 4 4≤ 0.8 17 9 8 6 6 6 6≤ 0.9 20 10 10 7 8 6 8≤ 1.0 29 13 13 9 11 8 10≤ 1.1 38 19 18 12 13 10 14≤ 1.2 48 26 26 18 19 16 19≤ 1.3 59 34 34 27 27 22 25≤ 1.4 71 43 42 36 35 31 34≤ 1.5 86 57 53 45 43 41 41≤ 1.6 106 72 66 59 53 52 55≤ 1.7 129 89 83 74 74 65 67≤ 1.8 172 124 114 103 106 92 90≤ 1.9 210 155 149 132 138 126 117≤ 2.0 245 181 172 157 164 149 138≤ 2.1 277 206 196 183 185 172 155≤ 2.2 312 230 221 204 205 188 174≤ 2.3 352 255 244 223 224 207 192≤ 2.4 392 283 269 247 244 229 211≤ 2.5 437 321 301 280 278 259 241≤ 2.6 483 358 335 309 305 284 266≤ 2.7 542 396 376 346 336 323 299≤ 2.8 602 449 424 389 380 362 341≤ 2.9 698 516 487 442 432 411 387≤ 3.0 803 593 558 507 496 469 43684Table 5.7: Time-to-Collision Conflicts at varying connected vehicle market penetration lev-els for the second step calibrated micro-simulation model after implementing the CTTalgorithmTTC Threshold No CTT 10% CTT 30% CTT 50% CTT 70% CTT 90% CTT 100% CTT≤ 0.5 5 2 3 2 2 2 2≤ 0.6 6 3 4 3 2 3 3≤ 0.7 7 4 5 3 2 4 3≤ 0.8 10 6 7 6 4 4 4≤ 0.9 13 8 8 7 5 4 5≤ 1.0 17 10 9 8 7 5 6≤ 1.1 22 14 11 10 9 6 7≤ 1.2 27 16 14 13 10 8 10≤ 1.3 33 20 16 15 12 10 12≤ 1.4 43 26 21 20 14 12 13≤ 1.5 54 35 30 29 20 17 17≤ 1.6 65 44 38 36 27 22 23≤ 1.7 85 59 52 47 38 31 32≤ 1.8 102 70 62 56 46 41 42≤ 1.9 121 87 77 68 55 49 51≤ 2.0 148 105 93 80 66 60 61≤ 2.1 182 129 113 96 82 72 75≤ 2.2 218 155 135 121 100 92 92≤ 2.3 256 186 158 146 124 112 113≤ 2.4 316 229 197 186 151 137 139≤ 2.5 395 288 247 231 187 175 172≤ 2.6 481 344 289 269 222 207 204≤ 2.7 581 405 345 322 270 248 243≤ 2.8 686 474 403 384 319 291 293≤ 2.9 772 541 464 434 364 332 342≤ 3.0 863 608 520 485 408 379 390Table 5.8: Time-to-Collision Conflicts at varying connected vehicle market penetration levelsfor the first step calibrated micro-simulation model compared with the no-CTT micro-simulation after implementing the CTT algorithmTTC Threshold 10% CTT 30% CTT 50% CTT 70% CTT 90% CTT 100% CTT≤ 0.5 -56% -88% -50% -71% -88% -88%≤ 1.0 -57% -68% -61% -69% -67% -73%≤ 1.5 -50% -46% -44% -56% -49% -60%≤ 2.0 -40% -30% -33% -38% -38% -44%≤ 2.5 -41% -29% -37% -41% -40% -46%≤ 3.0 -40% -28% -37% -41% -41% -46%85Figure 5.5: Rear-end Conflicts for the first step calibrated micro-simulation model at varyingconnected vehicle penetration levelsFigure 5.6: Rear-end Conflicts for the second step calibrated micro-simulation model at vary-ing connected vehicle penetration levels86Figure 5.7: Rear-end conflicts improvements for the first step calibrated micro-simulationmodel at varying connected vehicle penetration levels compared with no-CTT algo-rithm appliedFigure 5.8: Rear-end conflicts improvements for the second step calibrated micro-simulationmodel at varying connected vehicle penetration levels compared with no-CTT algo-rithm applied87Table 5.9: Time-to-Collision Conflicts at varying connected vehicle market penetration levelsfor the second step calibrated micro-simulation model compared with the no-CTT micro-simulation after implementing the CTT algorithmTTC Threshold 10% CTT 30% CTT 50% CTT 70% CTT 90% CTT 100% CTT≤ 0.5 -60% -20% -80% -40% -40% -40%≤ 1.0 -43% -45% -78% -59% -59% -67%≤ 1.5 -49% -53% -70% -63% -65% -71%≤ 2.0 -45% -42% -60% -58% -63% -62%≤ 2.5 -43% -39% -53% -53% -57% -58%≤ 3.0 -43% -40% -50% -52% -57% -58%5.1.5 CTT Comparison with Lower Intersection VolumeThe evaluation for the CTT algorithm has been conducted thus far at a total hourly intersectionvolume of approximately 3,000 vehicles per hour. A supplementary review was conducted toinvestigate how the algorithm performs under lower intersection volumes. The intersection volumeused for this review was approximately 2,400 vehicles per hour. The results are presented inTables 5.10, 5.5, 5.12, and 5.13 and Figures 5.9, 5.10 and 5.11.Table 5.10: Travel times at varying connected vehicle market penetration levels for the sec-ond step calibrated micro-simulation model after implementing the CTT algorithm at alower intersection volumeVehicle Type NoCTT10%CTT30%CTT50%CTT70%CTT90%CTT100%CTTAvg. CV (s) N/A 16.3 17.2 16.4 15.9 15.4 15.2Avg. Non-CV (s) 24.8 23.4 19.8 18.8 17.5 16.9 N/AAvg. All Vehicles(s)24.8 19.8 18.5 17.6 16.7 16.2 15.2Table 5.11: Travel time improvements at varying connected vehicle market penetration lev-els for the second step calibrated micro-simulation model compared with the no-CTTmicro-simulation after implementing the CTT algorithm at lower intersection volumeVehicle Type 10% CTT 30% CTT 50% CTT 70% CTT 90% CTT 100% CTTAvg. CV -34% -31% -34% -36% -38% -39%Avg. Non-CV -6% -20% -24% -30% -32% N/AAvg. All Vehicles -20% -25% -29% -33% -35% -39%88Figure 5.9: Travel time improvements at varying connected vehicle market penetration lev-els for the second step calibrated micro-simulation model compared with the no-CTTmicro-simulation after implementing the CTT algorithm at lower intersection volumeFigure 5.10: Rear-end Conflicts for the second step calibrated micro-simulation model atvarying connected vehicle penetration levels at a lower intersection volume89Table 5.12: Time-to-Collision Conflicts at varying connected vehicle market penetration lev-els for the second step calibrated micro-simulation model after implementing the CTTalgorithm at a lower intersection volumeTTC Threshold 0% CTT 10% CTT 30% CTT 50% CTT 70% CTT 90% CTT 100% CTT≤ 0.5 2 1 2 1 1 2 2≤ 0.6 4 1 3 2 1 2 3≤ 0.7 5 2 4 2 2 3 3≤ 0.8 8 3 5 4 3 4 4≤ 0.9 11 4 6 4 3 5 4≤ 1.0 12 6 7 5 3 7 4≤ 1.1 16 7 8 6 4 9 5≤ 1.2 19 9 10 8 5 11 7≤ 1.3 23 12 12 9 8 12 8≤ 1.4 27 15 16 12 10 15 10≤ 1.5 33 21 22 16 14 20 15≤ 1.6 41 26 28 21 21 25 22≤ 1.7 54 33 37 29 29 32 28≤ 1.8 64 40 44 36 38 38 34≤ 1.9 75 47 55 43 46 47 43≤ 2.0 91 59 65 54 55 56 52≤ 2.1 110 73 79 64 65 66 61≤ 2.2 131 85 95 82 83 81 77≤ 2.3 157 104 114 102 99 100 94≤ 2.4 192 127 141 129 126 123 117≤ 2.5 246 158 173 164 151 150 148≤ 2.6 298 187 206 194 171 177 171≤ 2.7 362 226 244 233 213 206 203≤ 2.8 424 264 279 271 251 239 239≤ 2.9 473 296 316 307 283 272 266≤ 3.0 527 328 343 342 312 302 296Table 5.13: Time-to-Collision Conflicts at varying connected vehicle market penetration lev-els for the second step calibrated micro-simulation model compared with the no-CTTmicro-simulation after implementing the CTT algorithm at a lower intersection volumeTTC Threshold 10% CTT 30% CTT 50% CTT 70% CTT 90% CTT 100% CTT≤ 0.5 -50% 0% -50% -33% 0% 0%≤ 1.0 -53% -43% -63% -73% -43% -67%≤ 1.5 -36% -33% -51% -56% -41% -54%≤ 2.0 -35% -29% -40% -40% -38% -42%≤ 2.5 -36% -30% -33% -39% -39% -40%≤ 3.0 -38% -35% -35% -41% -43% -44%90Figure 5.11: Rear-end Conflicts for the second step calibrated micro-simulation model atvarying connected vehicle penetration levels compared with no-CTT algorithm ap-plied at a lower intersection volume5.1.6 Evaluation of ResultsThe following sections describe the changes to mobility with respect to travel times and to sur-rogate safety measures through the traffic conflict technique for the first step and second stepcalibrated micro-simulation models at varying connected vehicle market penetrations.5.1.6.1 Mobility EvaluationIn all connected vehicle penetration levels the travel times for both connected vehicles and non-connected vehicles improve. For the first step calibrated micro-simulation model, at a 10% con-nected vehicle market penetration the connected vehicles show a 31% reduction in travel timeswhile the non-connected vehicles show a 13% reduction in travel times. The improvements forconnected vehicles grow to 39% reduction at the 50% connected vehicle market penetration leveland then grow slowly to 43% reduction in travel time at the 100% connected vehicle market pene-tration level. The non-connected vehicle travel time improvements have a significant improvement91between 10% connected vehicle market penetration and 30% connected vehicle market penetra-tion levels, from 13% reduction in travel times to 28% reduction in travel times. The improvementsagain grow to 36% reduction in travel times at the 50% connected vehicle market penetration level,but slow to 39% reduction for 70% and 90% connected vehicle market penetration levels.Reviewing the travel time improvements after the second step calibration is performed, there isagain an improvement for both connected and non-connected vehicles at all connected vehiclemarket penetration levels evaluated when compared with the non-connected vehicle environment.The improvements follow a similar trend to what was seen for the first-step calibrated micro-simulation as well as what was seen in the uncalibrated micro-simulation.At a lower total intersection volume, the results differ from the higher intersection volume forlower connected vehicle market penetration levels; however, the travel time improvements followsa similar trend at higher connected vehicle market penetration levels.While at lower connected vehicle penetration rates there are imperfect conditions for detection,the results demonstrate that even in these conditions (specifically 10% and 30%) there are still sig-nificant travel time improvements through the intersection for both connected and non-connectedvehicles.While the results vary slightly in comparisons with the non-connected environment for both thefirst step and second step calibration micro-simulations, the absolute travel times for the varyingconnected vehicle market penetration rates are relatively unchanged throughout the different levelsof calibration, indicating that calibration does not have a large impact on travel times. Total inter-section volume has a more significant impact on travel times at lower connected vehicle marketpenetration levels with respect to variability in savings, but at higher market penetration levels theresults are relatively consistent regardless of the intersection volumes evaluated. The larger impactwith respect to travel time improvements occurs due to the CTT algorithm itself in conjunctionwith higher connected vehicle market penetration levels.92Reviewing the results presented by Lee et al. (2013a), a comparison of travel time improvementswith exposure shows that as the hourly intersection volume increases the improvements to traveltimes when applying the CTT algorithm increase as well. Comparing the results of this study witha travel time improvement of approximately 43% and 41% for a 5s time-step and 100% connectedvehicle market penetration and at the first step and second step calibrated micro-simulation mod-els, it shows that the algorithm used in conjunction with the calibrated micro-simulation modelsperform better by 7-9% with the currently applied algorithm showing a greater improvement intravel times. Similar to the uncalibrated micro-simulation model evaluations, at varying connectedvehicle market penetration levels, travel time improvements presented in this study show less vari-ability and overall higher improvement than the results seen in Lee et al. (2013a). Evaluating thelower total intersection volume shows similar results to Lee et al. (2013a) in that the travel timeimprovements are less pronounced at lower intersection volumes. Within this study the travel timeimprovements at a lower intersection volume remain more stable than those seen in Lee et al.(2013a).5.1.6.2 Traffic Conflicts EvaluationIn all the connected vehicle environments evaluated, significant improvements to the number ofconflicts observed were seen at all connected vehicle penetration levels, for both the first step andsecond step calibrated micro-simulation models.The TTC conflicts were analyzed at varying thresholds (e.g., ≤ 0.5s up to ≤ 3.0s) to evaluatethe differences in output from each micro-simulation. When the first step calibration was appliedthe improvements in TTC conflicts remain relatively stable for each connected vehicle marketpenetration at the TTC threshold of≤ 2.0s and above, ranging between 28% and 46% improvementwith higher improvements seen with the higher connected vehicle market penetration levels. Atlower TTC thresholds, the improvements are greater, ranging between 44% and 88%, but havesignificantly higher variation within individual connected vehicle market penetration levels.93With the second step calibration applied, results are similar to what was seen after the first step cali-bration but with more improvement over the no-connected vehicle scenario, improvements rangingbetween 39% and 63%. At lower TTC thresholds the improvements have a very large range, be-tween 20% and 80% improvement. Within the individual connected vehicle market penetrationlevels, there are at times significant ranges of improvements, such as at the 30% connected vehiclelevel where the range is between 20% improvement at a TTC threshold of ≤ 0.5s and 53% im-provement at a TTC threshold of ≤ 1.5s. At higher connected vehicle market penetration levels,greater than 70%, the improvements over the non-connected vehicle environment are more consis-tent with each other, indicating that, with respect to TTC rear-end conflicts, at higher connectedvehicle market penetration levels (70% and above) the intersection will behave in a relatively stablemanner whereas there is more volatility at lower connected vehicle market penetration levels.At the lower intersection volume, traffic conflict improvements follow a similar trend to at thehigher intersection volume with a TTC threshold of ≤ 2.0s remaining relatively consistent withhigher TTC thresholds within each connected vehicle market penetration level, ranging between29% and 44% improvement. At lower TTC thresholds (≤ 1.5s and less) the variation is greater,ranging between 0% improvement and 73%. This is due to there being significantly less trafficconflicts at the lower TTC thresholds (≤ 1.5s and below) compared with higher TTC thresholds.Essa and Sayed (2015a) performed a calibration against field measured conflicts and determinedthat after the first step calibration there was already a significant improvement to appropriatelysimulating conflicts due to calibrating the arrival rate and patterns limiting the exposure to vehicleinteractions similar to what are seen in the field. When comparing the results of the second stepcalibrated simulations against the first step calibrated simulations, the observations are consistentwith the trends seen in Essa and Sayed (2015a) although the magnitude of improvements havehigher variation.Overall the results of the traffic conflicts evaluation demonstrate that calibration, through modifi-cation of VISSIM parameters, has a significant impact on the simulated rear-end conflicts.94Chapter 6Summary, Conclusion and Future ResearchThis chapter contains three parts. Firstly, an overall review of the thesis is provided including asummary of the results from Chapters 4 and 5. Following the summary, a conclusion is presented.Finally, future research is recommended.6.1 SummaryThis thesis investigates the ability of using the VISSIM micro-simulation model to evaluate thesafety of connected vehicle applications in conjunction with the SSAM software package and con-flict analysis through a combination of VISSIM and SSAM, as well as to investigate if calibrationof the micro-simulation model provides a better representation of the real world than not calibratingthe micro-simulation model. Two connected vehicle applications were chosen for the investigation,one involving a cooperative adaptive cruise control (CACC) connected vehicle application to sup-port vehicle platooning through V2V communications, the other involving a cumulative travel time(CTT) intersection control connected vehicle application to support more efficient travel throughan intersection using V2I communications. An overall review of the methodology of implement-ing a micro-simulation model of a connected vehicle application was presented with two examples95provided for the two micro-simulation models used in this thesis.Case studies were performed for the individual connected vehicle applications. For the CACCmicro-simulation model, the ability to evaluate the safety of a CACC connected vehicle environ-ment on a freeway using VISSIM micro-simulation and the Surrogate Safety Assessment Model(SSAM) was investigated. Micro-simulations through VISSIM were performed at varying CACCpenetration levels. This study demonstrates that SSAM in combination with VISSIM is an appro-priate tool to evaluate the level of safety of a connected vehicle application for cooperative adaptivecruise control on a freeway segment. Through sensitivity analysis it was demonstrated that the sim-ulated conflicts results vary, sometimes significantly depending on calibration parameter values aswell as acceleration coefficient values from within the CACC algorithm.For the CTT micro-simulation model, the ability to evaluate safety after applying a CTT algorithmto a signalized intersection through the use of connected vehicle technology was investigated.After initial investigation, the micro-simulation model was evaluated through a two-step calibrationprocess, first for vehicle arrival rates and second for observed traffic conflicts. Micro-simulationsthrough VISSIM were performed at three levels: Uncalibrated, first step calibrated, and second stepcalibrated. The different stages of calibration show significant variation in the number of conflictsobserved, as well as throughout the changes in connected vehicle penetration levels. It was foundthat calibrating the micro-simulation model to real-world non-Connected Vehicle conditions had asignificant impact on the modeled safety improvements when the connected vehicle environmentis applied, however it is inconclusive whether the results are realistic or not as the CTT applicationis not in practice in the field to compare to.6.2 ConclusionThe VISSIM micro-simulation model in conjunction with the SSAM software package is usefulfor evaluating simulated traffic conflicts for traffic facilities.96Both micro-simulation models of the connected vehicle applications reviewed demonstrates thepotential to evaluate the changes in safety on a transportation network with the connected vehicleapplications in place through the use of surrogate safety measures. The two applications involveddifferent communication types, 1) V2V communication for the CACC connected vehicle applica-tion, and 2) V2I communication for the CTT connected vehicle application.A general procedure has been outlined to describe the process required for simulating a connectedvehicle application with the VISSIM micro-simulation model. Specific examples are provided forboth applications, focusing on the separate connected vehicle communication types.Results from the specific connected vehicle application simulations demonstrate that, through eval-uation with the combination of the VISSIM micro-simulation model and the SSAM software pack-age, implementing connected vehicle applications result in promising observable changes to sim-ulated traffic conflicts indicating that implementing the connected vehicle applications will resultin a change to the level of safety on a roadway.Throughout the implementation of the connected vehicle applications into a VISSIM micro-simulationmodel, it was found that the VISSIM micro-simulation model would benefit from updated modulesenabling better modelling of connected vehicle applications.6.2.1 CACC ConclusionThe cooperative adaptive cruise control (CACC) application demonstrated that V2V communi-cations and the control of vehicles results in a significant reduction in the number of simulatedconflicts, with varying results depending on the market penetration of connected vehicles with theCACC technology on the roadway. The range of improvements with respect to mobility, throughtravel time measurements, is between 10% (at lower CACC penetration levels) and 50% (at the90% CACC penetration level) when evaluated through an incident causing delays on the roadway.97While the results of the CACC connected vehicle application are promising, the VISSIM driverbehaviour parameters show to have a moderate affect to the travel times, ranging from a decreaseof 20% for a more aggressive headway, to an increase of 34% at less aggressive headways, whencompared with the default VISSIM headway driver behaviour parameter. With respect to conflictanalysis, significant variations are found when the headway parameter is changed, generally im-proving at higher headway values (i.e., 1.1s and above) and disimproving at lower headway values(i.e., 0.7s). This implies that calibration of the micro-simulation model to real-world conditionswill be necessary to be able to have a realistic understanding of the benefits of implementing theCACC connected vehicle application.Ultimately without a real-world implementation of the CACC application it is unknown if theresults of the micro-simulation model are accurate or not.6.2.2 CTT ConclusionThe cumulative travel time intersection control connected vehicle application (CTT) demonstratedthat V2I communications and the integration with the control of a signalized intersection resultsin general in a reduction of the number of simulated conflicts, with varying results depending onthe market penetration of the connected vehicles on the roadway and the level of calibration of themicro-simulation model.The micro-simulation was run for three calibration scenarios: 1) no calibration (default VISSIMparameters), 2) first step calibrated for arrival rates (through the use of dummy signals), and 3) sec-ond step calibrated for SSAM conflicts (through the modification of driver behaviour parameters).The simulated travel times were found not to vary significantly throughout the different levels ofcalibration. The simulated rear-end conflicts had significant variation based on the level of cali-bration at varying connected vehicle market penetration levels. For the uncalibrated simulation,there was a significant increase, at times of 100%, to the number of simulated rear-end conflicts98when the CTT algorithm was implemented compared with the no-CTT scenario. The first and sec-ond step calibrations demonstrate an improvement to the number of simulated rear-end conflictsat all connected vehicle market penetration levels, with higher market penetration levels showingin general more of an improvement to the number of simulated conflicts than the lower marketpenetration levels.Evaluating the simulation at a lower total intersection volume (approximately 2,400 vehicles perhour), after the second step calibration was applied, demonstrates similar results to the higher totalintersection volume (approximately 3,000 vehicles per hour), with the difference being an overallless number of total conflicts at all connected vehicle market penetration levels and a resultinglower level of improvement.In general the CTT algorithm in conjunction with a connected vehicle environment results in animprovement to simulated travel times and conflicts and the improvements to the simulated traf-fic conflicts is greater at higher total intersection volumes. The use of video analysis to analyzereal-world conflicts through computer vision enables for a better representation to the real-worldconditions for calibrating the micro-simulation model and have a direct impact to the simulatedconflicts within the micro-simulation model.While the results of the calibrated micro-simulation model are promising after implementing theCTT connected vehicle environment, without a real-world implementation of the CTT algorithmin conjunction with the connected vehicle environment it is unknown if the results of the micro-simulation are realistic.996.3 Future Research6.3.1 CACC Future ResearchWithin this study the evaluation focused only on one type of conflict (rear-end) with one safetymeasure indicator used (TTC). It would be beneficial to review other safety measures in conjunc-tion with the TTC, such as the maximum and relative speeds of the vehicles involved in order tounderstand severity of the conflicts.Future work with the CACC algorithm should be compared with real-world results of actual de-ployments similar to the experimental evaluation performed by Ploeg et al. (2011) in order to bettercalibrate the micro-simulation for large scale deployment of the connected vehicle application.6.3.2 CTT Future ResearchWithin this study, the evaluation focused only on one type of conflict (rear-end) with one safetymeasure indicator used (TTC). It would be beneficial to review other safety measure indicatorsto understand the severity of the conflicts, such as the maximum and relative speeds of the twovehicles involved in the conflict (MaxS and DeltaS measures respectively).Specific to the connected vehicle application, more work is required to further the advancementof this research by applying the Kalman filtering technique as was done in Lee et al. (2013a)and comparing the level of safety through SSAM at varying connected vehicle penetration levelswith the Kalman filter applied compared with the current methodology not accounting for non-connected vehicles. Additionally, evaluating at multiple intersection volumes will provide a betterindication as to what impacts the volumes have on the level of safety of the CTT algorithm.This specific CTT algorithm was applied to only a single intersection. It would be useful to transferthe algorithm to another intersection, similar to work done by Essa and Sayed (2015b) to investi-100gate the performance at different locations with different traffic patterns.The update interval was kept at a relatively short time frame for the evaluation of the CTT algorithm(5s). It would be useful to evaluate this at longer update intervals (e.g., 10s or 15s) to see at whatpoint do the safety benefits decrease.Finally, the distance of detection should be reviewed and analyzed to determine an optimal distancefrom the intersection. In this study we used 140m; however it may be found that shortening orextending this distance could improve the safety of the CTT application.101BibliographyF. Amundsen and C. Hyden. The swedish traffic conflict technique. In Proceedings of FirstWorkshop on Traffic Conflicts, Institute of Transport Economics, Oslo, pages 1–5, 1977. →page(s) 6, 13, 14J. Archer. Traffic conflict technique. Historical to current State-of-the-Art. Stockholm:Institutionen fo¨r Infrastruktur KTH, Stockholm, pages 2–3, 2001. → page(s) 6J. Archer. Methods for the assessment and prediction of traffic safety at urban intersections andtheir application in micro-simulation modelling. Royal Institute of Technology, 2004. →page(s) 15J. Autey, T. Sayed, and M. H. Zaki. Safety evaluation of right-turn smart channels usingautomated traffic conflict analysis. Accident Analysis & Prevention, 45:120–130, 2012. →page(s) 13, 17, 80L. Ben Othmane, A. Al-Fuqaha, E. Ben Hamida, and M. Van Den Brand. Towards extendedsafety in connected vehicles. In Intelligent Transportation Systems-(ITSC), 2013 16thInternational IEEE Conference on, pages 652–657. IEEE, 2013. → page(s) 32T. Bjørnskau. Hypotheses on risk compensation. Road Safety in Europe and Strategic HighwayResearch Program (SHRP), LILLE, FRANCE, SEPTEMBER 26-28, 1994 (VTI KONFERENS),(2A: 4), 1995. → page(s) 20D. Box. Essential com. Addison-Wesley Professional, 1998. → page(s) 34G. R. Brow. Traffic conflicts for road user safety studies. Canadian Journal of Civil Engineering,21(1):1–15, 1994. → page(s) 16K.-W. Chen, H.-M. Tsai, C.-H. Hsieh, S.-D. Lin, C.-C. Wang, S.-W. Yang, S.-Y. Chien, C.-H.Lee, Y.-C. Su, C.-T. Chou, et al. Connected vehicle safety science, system, and framework. InInternet of Things (WF-IoT), 2014 IEEE World Forum on, pages 235–240. IEEE, 2014. →page(s) 30H.-C. Chin and S.-T. Quek. Measurement of traffic conflicts. Safety Science, 26(3):169–185,1997. → page(s) 13, 16102P. Cooper. Experience with traffic conflicts in canada with emphasis on post encroachment timetechniques. In International calibration study of traffic conflict techniques, pages 75–96.Springer, 1984. → page(s) 14F. Cunto. Assessing safety performance of transportation systems using microscopic simulation.2008. → page(s) 13G. A. Davis. Possible aggregation biases in road safety research and a mechanism approach toaccident modeling. Accident Analysis & Prevention, 36(6):1119–1127, 2004. → page(s) 12P. de Leur and T. Sayed. Using claims prediction model for road safety evaluation. CanadianJournal of Civil Engineering, 28(5):804–812, 2001. → page(s) 10, 12P. de Leur and T. Sayed. A framework to proactively consider road safety within the road planningprocess. Canadian Journal of Civil Engineering, 30(4):711–719, 2003. → page(s) 10, 12A. Dijkstra, P. Marchesini, F. Bijleveld, V. Kars, H. Drolenga, and M. van Maarseveen. Docalculated conflicts in microsimulation model predict number of crashes? TransportationResearch Record: Journal of the Transportation Research Board, (2147):105–112, 2010. →page(s) 25S. Eichler, B. Ostermaier, C. Schroth, and T. Kosch. Simulation of car-to-car messaging:analyzing the impact on road traffic. In null, pages 507–510. IEEE, 2005. → page(s) 31R. Elvik. To what extent can theory account for the findings of road safety evaluation studies?Accident Analysis & Prevention, 36(5):841–849, 2004. → page(s) 20, 21M. Essa. Calibration and validation of traffic microsimulation models for safety evaluation usingautomated video-based conflict analysis. Master’s thesis, University of British Columbia, 2015.→ page(s) 6, 13M. Essa and T. Sayed. Simulated traffic conflicts: do they accurately represent field-measuredconflicts? In Transportation Research Record: Journal of the Transportation Research Board,number 2514, pages 48–57. Transportation Research Board of the National Academies, 2015a.→ page(s) iv, xiii, 5, 6, 25, 34, 41, 47, 51, 68, 69, 77, 78, 79, 80, 81, 94M. Essa and T. Sayed. Transferability of calibrated microsimulation model parameters for safetyassessment using simulated conflicts. Accident Analysis & Prevention, 84:41–53, 2015b. →page(s) 6, 41, 47, 100M. Essa and T. Sayed. A comparison between paramics and vissim in estimating automatedfield-measured traffic conflicts at signalized intersections. Journal of Advanced Transportation,2016. → page(s) 6, 41, 47R. Fan, H. Yu, P. Liu, and W. Wang. Using vissim simulation model and surrogate safetyassessment model for estimating field measured traffic conflicts at freeway merge areas.Intelligent Transport Systems, IET, 7(1):68–77, 2013. → page(s) 25, 26103Q. Ge and M. Menendez. Sensitivity analysis for calibrating vissim in modeling the zurichnetwork. In 12th Swiss Transport Research Conference, Ascona, Switzerland, pages 2–4, 2012.→ page(s) 5D. Gettman, L. Pu, T. Sayed, and S. G. Shelby. Surrogate safety assessment model and validation:Final report. Technical report, 2008. → page(s) 15, 16, 24, 25, 26, 27S. Gibbs. Google’s self-driving car: How does it work and when can we drive one? https://www.theguardian.com/technology/2014/may/28/google-self-driving-car-how-does-it-work,2014. Accessed: June 2016. → page(s) 21J. Glennon, W. Glauz, M. Sharp, and B. Thorson. Critique of the traffic-conflict technique.Transportation research record, 630:32–38, 1977. → page(s) 16G. Gomes, A. May, and R. Horowitz. Calibration of vissim for a congested freeway. CaliforniaPartners for Advanced Transit and Highways (PATH), 2004. → page(s) 27, 69F. Habtemichael and L. Picado-Santos. Sensitivity analysis of vissim driver behavior parameterson safety of simulated vehicles and their interaction with operations of simulated traffic. In92nd annual meeting of Transportation Research Board, 2013. → page(s) 69, 70M. Hadi, P. Sinha, and A. Wang. Modeling reductions in freeway capacity due to incidents inmicroscopic simulation models. Transportation Research Record: Journal of theTransportation Research Board, 2007. → page(s) 69, 70E. Hauer. The frequency–severity indeterminacy. Accident Analysis & Prevention, 38(1):78–83,2006. → page(s) 12J. C. Hayward. Near-miss determination through use of a scale of danger. Highway ResearchRecord, (384), 1972. → page(s) 14HDR. Current and projected costs of congestion in metro vancouver. Technical report, TransLink,2015. → page(s) 10Highway Capacity Manual. Highway capacity manual. Washington, DC, 2000. → page(s) 62, 78W. Hirst, L. Mountain, and M. Maher. Sources of error in road safety scheme evaluation: amethod to deal with outdated accident prediction models. Accident Analysis & Prevention, 36(5):717–727, 2004. → page(s) 12F. Huang, P. Liu, H. Yu, and W. Wang. Identifying if vissim simulation model and ssam providereasonable estimates for field measured traffic conflicts at signalized intersections. AccidentAnalysis & Prevention, 50:1014–1024, 2013. → page(s) 26K. A. Ismail. Application of computer vision techniques for automated road safety analysis andtraffic data collection. PhD thesis, University of British Columbia, 2010. → page(s) 13, 15, 17ITS Canada. Intelligent transportation. https://www.itscanada.ca/it/index.html, 2012. → page(s)18104Q. Jin, G. Wu, K. Boriboonsomsin, and M. Barth. Advanced intersection management forconnected vehicles using a multi-agent systems approach. In Intelligent Vehicles Symposium(IV), 2012 IEEE, pages 932–937. IEEE, 2012. → page(s) 29R. Kulmala. Ex-ante assessment of the safety effects of intelligent transport systems. AccidentAnalysis & Prevention, 42(4):1359–1369, 2010. → page(s) 19, 20, 21J. Lee, B. Park, and I. Yun. Cumulative travel-time responsive real-time intersection controlalgorithm in the connected vehicle environment. Journal of Transportation Engineering, 139(10):1020–1029, 2013a. → page(s) iv, xii, 7, 46, 47, 48, 49, 55, 93, 100J. Lee, B. B. Park, K. Malakorn, and J. J. So. Sustainability assessments of cooperative vehicleintersection control at an urban corridor. Transportation Research Part C: EmergingTechnologies, 32:193–206, 2013b. → page(s) 7T. Luettel, M. Himmelsbach, and H.-J. Wuensche. Autonomous ground vehicles: concepts and apath to the future. Proceedings of the IEEE, 100(Special Centennial Issue):1831–1839, 2012.→ page(s) 22H. Lum and J. A. Reagan. Interactive highway safety design model: accident predictive module.Public Roads, 58(3), 1995. → page(s) 2, 11J. Miller and E. Horowitz. Freesim-a free real-time freeway traffic simulator. In IntelligentTransportation Systems Conference, 2007. ITSC 2007. IEEE, pages 18–23. IEEE, 2007. →page(s) 30A. Nicholson. The variability of accident counts. Accident Analysis & Prevention, 17(1):47–56,1985. → page(s) 12E. Paikari, S. Tahmasseby, and B. Far. A simulation-based benefit analysis of deployingconnected vehicles using dedicated short range communication. In Intelligent VehiclesSymposium Proceedings, 2014 IEEE, pages 980–985. IEEE, 2014. → page(s) 29, 30S. R. Perkins and J. L. Harris. Traffic conflict characteristics-accident potential at intersections.Highway Research Record, (225), 1968. → page(s) 13C. Pin, T. Sayed, and M. H. Zaki. Assessing safety improvements to pedestrian crossings usingautomated conflict analysis. Transportation Research Record: Journal of the TransportationResearch Board, (2514):58–67, 2015. → page(s) 17J. Ploeg, B. T. Scheepers, E. van Nunen, N. van de Wouw, and H. Nijmeijer. Design andexperimental evaluation of cooperative adaptive cruise control. In 2011 14th InternationalIEEE Conference on Intelligent Transportation Systems (ITSC), pages 260–265. IEEE, 2011.→ page(s) 100C. M. Rudin-Brown and H. A. Parker. Behavioural adaptation to adaptive cruise control (acc):implications for preventive strategies. Transportation Research Part F: Traffic Psychology andBehaviour, 7(2):59–76, 2004. → page(s) 19105SAE International. Dedicated short range communications (dsrc) message set dictionary, 2016.→ page(s) 46N. Saunier and T. Sayed. A feature-based tracking algorithm for vehicles in intersections. InComputer and Robot Vision, 2006. The 3rd Canadian Conference on, pages 59–59. IEEE,2006. → page(s) 80N. Saunier and T. Sayed. Automated analysis of road safety with video data. TransportationResearch Record: Journal of the Transportation Research Board, (2019):57–64, 2007. →page(s) 6, 12, 80N. Saunier and T. Sayed. Probabilistic framework for automated analysis of exposure to roadcollisions. Transportation Research Record: Journal of the Transportation Research Board,(2083):96–104, 2008. → page(s) 14, 80N. Saunier, T. Sayed, and K. Ismail. Large-scale automated analysis of vehicle interactions andcollisions. Transportation Research Record: Journal of the Transportation Research Board,(2147):42–50, 2010. → page(s) 14, 80T. Sayed and P. De Leur. Collision prediction models for British Columbia. Ministry ofTransportation and Infrastructure, 2008. → page(s) 3, 11T. Sayed and S. Zein. Traffic conflict standards for intersections. Transportation Planning andTechnology, 22(4):309–323, 1999. → page(s) 6, 16T. Sayed, K. Ismail, M. Zaki, and J. Autey. Feasibility of computer vision-based safetyevaluations: Case study of a signalized right-turn safety treatment. Transportation ResearchRecord: Journal of the Transportation Research Board, (2280):18–27, 2012. → page(s) 17T. Sayed, M. H. Zaki, and J. Autey. Automated safety diagnosis of vehicle–bicycle interactionsusing computer vision analysis. Safety science, 59:163–172, 2013. → page(s) 17D. Schrank, B. Eisele, T. Lomax, and J. Bak. 2015 urban mobility scorecard. 2015. → page(s) 10C. Schroth, F. Do¨tzer, T. Kosch, B. Ostermaier, and M. Strassberger. Simulating the traffic effectsof vehicle-to-vehicle messaging systems. In Proc. of the 5th International Conference on ITSTelecommunications, Brest, France. Citeseer, 2005. → page(s) 31U. Shahdah, F. Saccomanno, and B. Persaud. Integrated traffic conflict model for estimating crashmodification factors. Accident Analysis & Prevention, 71:228–235, 2014. → page(s) 6S. G. Shelby. Delta-v as a measure of traffic conflict severity. In Transportation Research Board90th Annual Meeting, number 11-4199, 2011. → page(s) 15, 16D. Shinar. The traffic conflict technique: A subjective vs. objective approach. Journal of SafetyResearch, 15(4):153–157, 1985. → page(s) 13A. Smiley. Behavioral adaptation, safety, and intelligent transportation systems. TransportationResearch Record: Journal of the Transportation Research Board, (1724):47–51, 2000. →page(s) 19, 20106S. Smith and M. Razo. Using traffic microsimulation to assess deployment strategies for theconnected vehicle safety pilot. Journal of Intelligent Transportation Systems, pages 1–9, 2014.→ page(s) 32A. Tageldin, T. Sayed, M. Zaki, and M. Azab. A safety evaluation of an adaptive traffic signalcontrol system using computer vision. Advances in Transportation Studies, 2014. → page(s)xii, xiii, 41, 42, 47, 80A. Tarko, G. Davis, N. Saunier, T. Sayed, and S. Washington. Surrogate measures of safety.White paper, ANB20 (3) Subcommittee on Surrogate Measures of Safety, 2009. → page(s) 6T. Tettamanti and M. T. Horva´th. A practical manual for vissim com programming in matlab.Technical report, 2015. → page(s) 35, 48M. Tideman and M. van Noort. A simulation tool suite for developing connected vehicle systems.In Intelligent Vehicles Symposium (IV), 2013 IEEE, pages 713–718. IEEE, 2013. → page(s) 28,29Transport Canada. The Cost of Urban Congestion. Transport Canada, Environmental Affairs,2006. → page(s) 10Transport Canada. Road safety in canada.http://www.tc.gc.ca/eng/motorvehiclesafety/tp-tp15145-1201.htm, 2011. → page(s) 19B. Van Arem, C. J. Van Driel, and R. Visser. The impact of cooperative adaptive cruise control ontraffic-flow characteristics. Intelligent Transportation Systems, IEEE Transactions on, 7(4):429–436, 2006. → page(s) 57, 58, 74, 76C. Wang and N. Stamatiadis. Derivation of a new surrogate measure of crash severity.Transportation Research Record: Journal of the Transportation Research Board, (2432):37–45, 2014. → page(s) 6World Health Organization. WHO global status report on road safety 2013: supporting a decadeof action. World Health Organization, 2013. → page(s) 1L. Zhao and J. Sun. Simulation framework for vehicle platooning and car-following behaviorsunder connected-vehicle environment. Procedia-Social and Behavioral Sciences, 96:914–924,2013. → page(s) iv, 7, 31, 32, 57, 58, 74, 76107Appendix ACumulative Travel Time IntersectionControl Background CodeA.1 MATLAB Code for Micro-SimulationThe following is the applicable MATLAB code used for running the simulation and measuringthe cumulative travel time of each approach to the intersection as well as calling the function toevaluate the phase with the highest cumulative travel time and control the intersection as required.%% ========================================================================% Access dur ing s imu la t i on%==========================================================================%Defines the t ime i n t e r v a l f o r checking cumulat ive t r a v e l t ime ( Lee 2013%looks a t 5 seconds )t i m e i n t =5;%Create a mat r i x to keep t rack o f a l l veh i c l e cumulat ive t r a v e l t imes .CVehic le Mat r ix = zeros (8000 ,1) ;NCVehic le Matr ix = zeros (8000 ,1) ;%Create a mat r i x to keep t rack o f a l l veh i c les i n each approach , and%connected veh ic les i n each approachCVehic le Appr Mat r ix = zeros ( 8 ,1 ) ;NCVehic le Appr Matr ix = zeros ( 8 ,1 ) ;%Set Signa l Con t r o l l e rSC number = 1;108S igna lCon t r o l l e r = Vissim . Net . S i gna lCon t r o l l e r s . ItemByKey (SC number ) ;%Set Signa l Phase In tege r Valuesignalphase = 1;s igna lphaseold = signalphase ;% Set Stop Bar Locat ions − based on measurements from VISSIM Network .SB=[340 303 303 283 ] ;%A l l S imula t ions ( minus No−CTT)Vehicle Comp Array3 = [9 10 11 12 13 3 ] ;Vehicle Comp Array1 = [4 5 6 7 8 1 ] ;for Vehicle Comp = 1:6set ( Vissim . Net . Veh ic le Inpu ts . ItemByKey (1 ) , ’ At tVa lue ’ , ’VehComp(1 ) ’ , Vehicle Comp Array3 ( Vehicle Comp ) ) ;set ( Vissim . Net . Veh ic le Inpu ts . ItemByKey (2 ) , ’ At tVa lue ’ , ’VehComp(1 ) ’ , Vehicle Comp Array1 ( Vehicle Comp ) ) ;set ( Vissim . Net . Veh ic le Inpu ts . ItemByKey (3 ) , ’ At tVa lue ’ , ’VehComp(1 ) ’ , Vehicle Comp Array1 ( Vehicle Comp ) ) ;set ( Vissim . Net . Veh ic le Inpu ts . ItemByKey (4 ) , ’ At tVa lue ’ , ’VehComp(1 ) ’ , Vehicle Comp Array1 ( Vehicle Comp ) ) ;set ( Vissim . Net . Veh ic le Inpu ts . ItemByKey (1 ) , ’ At tVa lue ’ , ’VehComp(2 ) ’ , Vehicle Comp Array3 ( Vehicle Comp ) ) ;set ( Vissim . Net . Veh ic le Inpu ts . ItemByKey (2 ) , ’ At tVa lue ’ , ’VehComp(2 ) ’ , Vehicle Comp Array1 ( Vehicle Comp ) ) ;set ( Vissim . Net . Veh ic le Inpu ts . ItemByKey (3 ) , ’ At tVa lue ’ , ’VehComp(2 ) ’ , Vehicle Comp Array1 ( Vehicle Comp ) ) ;set ( Vissim . Net . Veh ic le Inpu ts . ItemByKey (4 ) , ’ At tVa lue ’ , ’VehComp(2 ) ’ , Vehicle Comp Array1 ( Vehicle Comp ) ) ;set ( Vissim . Net . Veh ic le Inpu ts . ItemByKey (1 ) , ’ At tVa lue ’ , ’VehComp(3 ) ’ , Vehicle Comp Array3 ( Vehicle Comp ) ) ;set ( Vissim . Net . Veh ic le Inpu ts . ItemByKey (2 ) , ’ At tVa lue ’ , ’VehComp(3 ) ’ , Vehicle Comp Array1 ( Vehicle Comp ) ) ;set ( Vissim . Net . Veh ic le Inpu ts . ItemByKey (3 ) , ’ At tVa lue ’ , ’VehComp(3 ) ’ , Vehicle Comp Array1 ( Vehicle Comp ) ) ;set ( Vissim . Net . Veh ic le Inpu ts . ItemByKey (4 ) , ’ At tVa lue ’ , ’VehComp(3 ) ’ , Vehicle Comp Array1 ( Vehicle Comp ) ) ;for Random Seed = 1:5Random Seed Array = [1 21 41 61 81 ] ;set ( Vissim . Simulat ion , ’ At tVa lue ’ , ’RandSeed ’ , Random Seed Array (Random Seed ) ) ;t imestep= t ime i n t ;for i =1: ( pe r iod t ime / t ime i n t )i =ce i l ( t imestep / t ime i n t ) ;CTT Array=zeros ( 8 ,1 ) ;CTT Array Old=zeros ( 8 ,1 ) ;S im break at = i ∗ t i m e i n t ; % Simulat ionsecond [ s ]t imestep= i ∗ t i m e i n t ;set ( Vissim . Simulat ion , ’ At tVa lue ’ , ’ SimBreakAt ’ , S im break at ) ;Vissim . S imu la t ion . RunContinuous ; % Sta r t the s imu la t i onA l l Veh i c l e s = Vissim . Net . Vehic les . GetA l l ;i f length ( A l l Veh i c l e s ) > 0for cnt Veh = 1 : length ( A l l Veh i c l e s )veh number = get ( A l l Veh i c l e s{cnt Veh } , ’ A t tVa lue ’ , ’No ’ ) ;veh type = get ( A l l Veh i c l e s{cnt Veh } , ’ A t tVa lue ’ , ’ VehType ’ ) ;veh speed = get ( A l l Veh i c l e s{cnt Veh } , ’ A t tVa lue ’ , ’ Speed ’ ) ;veh pos i t i on = get ( A l l Veh i c l e s{cnt Veh } , ’ A t tVa lue ’ , ’ Pos ’ ) ;veh l i n k l ane = get ( A l l Veh i c l e s{cnt Veh } , ’ A t tVa lue ’ , ’ Lane ’ ) ;i f length ( veh l i n k l ane ) == 3 & str2num ( veh l i n k l ane (1 ) )<5i f ( veh pos i t i on <SB(str2num ( veh l i n k l ane (1 ) ) ) & veh pos i t i on > SB(str2num (↪→ veh l i n k l ane (1 ) ) )−140)i f ( veh type == ’ 100 ’ )CVehic le Appr Mat r ix (str2num ( veh l i n k l ane (1 ) ) ) = CVehic le Appr Mat r ix (str2num (↪→ veh l i n k l ane (1 ) ) ) +1;CVeh ic le Mat r ix ( veh number ) = CVeh ic le Mat r ix ( veh number )+ t ime i n t ;CTT Array (str2num ( veh l i n k l ane (1 ) ) ) = CTT Array (str2num ( veh l i n k l ane (1 ) ) ) +↪→ CVehic le Mat r ix ( veh number ) ;endendelse i f length ( veh l i n k l ane ) == 3 & str2num ( veh l i n k l ane (1 ) )>4 & str2num ( veh l i n k l ane (1 ) )↪→ <9i f ( veh type == ’ 100 ’ )CVehic le Appr Mat r ix (str2num ( veh l i n k l ane (1 ) ) ) = CVehic le Appr Mat r ix (str2num (↪→ veh l i n k l ane (1 ) ) ) +1;109CVehic le Mat r ix ( veh number ) = CVeh ic le Mat r ix ( veh number )+ t ime i n t ;CTT Array (str2num ( veh l i n k l ane (1 ) ) ) = CTT Array (str2num ( veh l i n k l ane (1 ) ) ) +↪→ CVehic le Mat r ix ( veh number ) ;endendendendCTT Array Old = CTT Array ;s ignalphase = Evaluate CTT Signal T iming ( CTT Array , s igna lphaseold ) ;s igna lphaseold = signalphase ;Yellow Time = 4;Red Clearance = 2;swi tch signalphase% Set the Signa l Group according to the phase wi th h ighes t cumulat ive t r a v e l t ime based on↪→ signalphase func t i on .case 1Signal Group = [3 1 6 5 4 2 9 10 ] ;case 2Signal Group = [6 5 3 1 4 2 9 10 ] ;case 3Signal Group = [4 2 3 1 6 5 9 10 ] ;case 4Signal Group = [9 10 3 1 6 5 4 2 ] ;endfor sg=1:8SignalGroup ( sg ) = S i gna lCon t r o l l e r .SGs. ItemByKey ( Signal Group ( sg ) ) ;endCur ren t S ta te = {get ( SignalGroup (1 ) , ’ At tVa lue ’ , ’ State ’ ) , . . .get ( SignalGroup (2 ) , ’ At tVa lue ’ , ’ State ’ ) , . . .get ( SignalGroup (3 ) , ’ At tVa lue ’ , ’ State ’ ) , . . .get ( SignalGroup (4 ) , ’ At tVa lue ’ , ’ State ’ ) , . . .get ( SignalGroup (5 ) , ’ At tVa lue ’ , ’ State ’ ) , . . .get ( SignalGroup (6 ) , ’ At tVa lue ’ , ’ State ’ ) , . . .get ( SignalGroup (7 ) , ’ At tVa lue ’ , ’ State ’ ) , . . .get ( SignalGroup (8 ) , ’ At tVa lue ’ , ’ State ’ ) } ;end% % Set the s ta te o f a s i gna l c o n t r o l l e r :Phase = [3 3 1 1 1 1 1 1 ] ;% Find the index of Cur ren t S ta te where the s i gna l i s greeni f any ( ismember ( Cur rent Sta te , ’GREEN ’ ) ) ˜= 0index = f ind ( ismember ( Cur rent Sta te , ’GREEN ’ ) ) ;end% Set the s i gna l t im ing , checking f i r s t the green phasei f index (1 ) == 1 % DO NOTHING − Signa l i s a l ready as i t should be .else% This w i l l be changed to ye l low f o r the ye l low t ime , then red ,% and the a l l r e d t ime w i l l pass , then the phase des i red w i l l be% set to green using the f o l l ow i ng f o r loop .Phase=ones (8 ,1 ) ;Phase ( index ) =4;Sim break at = ( t imestep ) +1;t imestep=t imestep +1;CurrentPhase = get ( SignalGroup ( index (1 ) ) , ’ A t tVa lue ’ , ’ State ’ ) ;set ( Vissim . Simulat ion , ’ At tVa lue ’ , ’ SimBreakAt ’ , S im break at ) ;Vissim . S imu la t ion . RunContinuous ;set ( SignalGroup ( index (1 ) ) , ’ A t tVa lue ’ , ’ State ’ , Phase ( index (1 ) ) ) ;set ( SignalGroup ( index (2 ) ) , ’ A t tVa lue ’ , ’ State ’ , Phase ( index (2 ) ) ) ;Phase=ones (8 ,1 ) ;S im break at = ( t imestep ) +4;t imestep=t imestep +4;CurrentPhase = get ( SignalGroup ( index (1 ) ) , ’ A t tVa lue ’ , ’ State ’ ) ;110set ( Vissim . Simulat ion , ’ At tVa lue ’ , ’ SimBreakAt ’ , S im break at ) ;Vissim . S imu la t ion . RunContinuous ;set ( SignalGroup ( index (1 ) ) , ’ A t tVa lue ’ , ’ State ’ , Phase ( index (1 ) ) ) ;set ( SignalGroup ( index (2 ) ) , ’ A t tVa lue ’ , ’ State ’ , Phase ( index (2 ) ) ) ;CurrentPhase = get ( SignalGroup ( index (1 ) ) , ’ A t tVa lue ’ , ’ State ’ ) ;Phase = [3 3 1 1 1 1 1 1 ] ;Sim break at = ( t imestep ) +2;t imestep=t imestep +2;set ( Vissim . Simulat ion , ’ At tVa lue ’ , ’ SimBreakAt ’ , S im break at ) ;Vissim . S imu la t ion . RunContinuous ;for sg = 1:8 % Set the appropr ia te s i gna l s to green .SignalGroup ( sg ) = S i gna lCon t r o l l e r .SGs. ItemByKey ( Signal Group ( sg ) ) ;set ( SignalGroup ( sg ) , ’ At tVa lue ’ , ’ State ’ , Phase ( sg ) ) ;endendSim break at =( t imestep ) +1; % Simulat ionsecond [ s ]t imestep=t imestep +1;set ( Vissim . Simulat ion , ’ At tVa lue ’ , ’ SimBreakAt ’ , S im break at ) ;Vissim . S imu la t ion . RunContinuous ;i f i>(pe r iod t ime / t ime i n t )breakendendVissim . S imu la t ion . RunContinuous ;endendA.2 MATLAB Code for Cumulative Travel Time CalculationThe following is MATLAB code to evaluate the cumulative travel times of each of the approachcombinations for the four signal phases and output the phase with the highest cumulative traveltime.function [ s ignalphase ] = Evaluate CTT Signal T iming ( x , y )sp1 = x (1 ) + x (2 ) ;sp2 = x (3 ) + x (4 ) ;sp3 = x (5 ) + x (7 ) ;sp4 = x (6 ) + x (8 ) ;s igna lphasear ray =[ sp1 sp2 sp3 sp4 ] ;[ signalphasesum , Index ] = max( s igna lphasear ray ) ;i f Index == ysignalphase = Index ;returnendi f Index == 1Non Index Array = [2 3 4 ] ;endi f Index == 2Non Index Array = [1 3 4 ] ;111endi f Index == 3Non Index Array = [1 2 4 ] ;endi f Index == 4Non Index Array = [1 2 3 ] ;endIndex Array = [ Index 0 0 0 ] ;Dup l i ca t i on = 0;for i =1:3i f s igna lphasear ray ( Index ) == s igna lphasear ray ( Non Index Array ( i ) )Dup l i ca t i on = Dup l i ca t i on + 1;Index Array ( i +1) = Non Index Array ( i ) ;endendi f Dup l i ca t i on == 0signalphase = Index ;returnelseF ina l I ndex Ar ray = zeros ( Dup l i ca t i on +1 ,1) ;F i na l I ndex Ar ray (1 ) = Index ;Dup l i ca t i on Index = 0;for i = 1:4i f Index Array ( i ) ˜= 0Dup l i ca t i on Index = Dup l i ca t i on Index + 1;F ina l I ndex Ar ray ( Dup l i ca t i on Index )= Index Array ( i ) ;endendmsize = numel ( F ina l I ndex Ar ray ) ;i dx = randperm ( msize ) ;s ignalphase = F ina l I ndex Ar ray ( idx ( 1 ) ) ;returnend112Appendix BCooperative Adaptive Cruise ControlBackground CodeB.1 C++ DLL CACC Driver Behaviour ModelThe following is the C++ code for the Dynamic Linked Library to replace the driver behaviourmodel for the CACC vehicles./∗==========================================================================∗ //∗ CACCPlatooningModel . cpp DLL Module f o r VISSIM ∗ //∗ ∗ //∗ I n t e r f a ce module f o r ex te rna l d r i v e r models . ∗ //∗ Example vers ion wi th a very simple d r i v e r model . ∗ //∗ ∗ //∗ Version o f 2015−08−29 Mar t in Fyfe ∗ //∗ Based on 2012−08−28 vers ion by Lukas Kautzsch ∗ //∗==========================================================================∗ /#include ” CACCPlatooningModel . h ”/∗==========================================================================∗ /double cur rent speed = 0 .0 ;double des i r ed acce l e ra t i on = 0 . 0 ;double des i red lane ang le = 0 . 0 ;long ac t ive lane change = 0;long o r i g i na l a c t i v e l ane change = 0;long r e l t a r g e t l a n e = 0;double des i r e d ve l o c i t y = 0 . 0 ;double o r i g i n a l d e s i r e d v e l o c i t y = 0 . 0 ;long t u r n i n g i n d i c a t o r = 0 ;113long veh i c l e co l o r = CMYK(255 , 255 , 255 , 255) ;double l e ad veh i c l e d i s t ance = 999.0 ;double t a i l v e h i c l e d i s t a n c e = 999.0 ;double l e f t l e a d v e h i c l e d i s t a n c e = 999.0 ;double l e f t t a i l v e h i c l e d i s t a n c e = 999.0 ;double r i g h t l e a d veh i c l e d i s t a n c e = 999.0 ;double r i g h t t a i l v e h i c l e d i s t a n c e = 999.0 ;double l ead veh i c l e d i s t ance2 = 999.0 ;double t a i l v e h i c l e d i s t a n c e 2 = 999.0 ;double l e f t l e a d v eh i c l e d i s t a n c e2 = 999.0 ;double l e f t t a i l v e h i c l e d i s t a n c e 2 = 999.0 ;double r i g h t l e ad veh i c l e d i s t a n ce2 = 999.0 ;double r i g h t t a i l v e h i c l e d i s t a n c e 2 = 999.0 ;double l ead veh i c l e speed d i f f e r ence = −99.0;double l e ad veh i c l e l eng t h = 0 . 0 ;double ka = 1 . 0 ;double kv = 0 .58 ;/ / double kv = 1 . 0 ;/ / double kv = 2 . 0 ;double ks = 0 . 1 ;/ / double ks = 0 . 2 ;/ / double ks = 0 . 3 ;double ac = 0 . 0 ;double ap = 0 .0 ;double vp = 0 . 0 ;double v f = 0 . 0 ;double s = 0 . 0 ;double v = 0 . 0 ;double td = 0 . 5 ; / / 0.5 s gap .double amin = −3.0;double amax = 2 .0 ;long l ead p la toon = 0;long j o i n p l a t o on = 0;long veh i c l e ca tego ry = 0;long l ead veh i c l e ca tego ry = 0;long t a i l v e h i c l e c a t e g o r y = 0;long r i g h t l e ad veh i c l e c a t e go r y = 0;long r i g h t t a i l v e h i c l e c a t e g o r y = 0;long l e f t l e a d v eh i c l e c a t e g o r y = 0;long l e f t t a i l v e h i c l e c a t e g o r y = 0;long l ead veh i c l e ca tego ry2 = 0;long t a i l v e h i c l e c a t e g o r y 2 = 0;long r i g h t l e ad veh i c l e ca t ego r y2 = 0;long r i g h t t a i l v e h i c l e c a t e g o r y 2 = 0;long l e f t l e a d veh i c l e c a t e go r y 2 = 0;long l e f t t a i l v e h i c l e c a t e g o r y 2 = 0;long veh i c l e l ane = 0;/∗==========================================================================∗ /BOOL APIENTRY Dl lMain (HANDLE hModule ,DWORD u l r e a s on f o r c a l l ,LPVOID lpReserved ){switch ( u l r e a s o n f o r c a l l ) {case DLL PROCESS ATTACH:case DLL THREAD ATTACH:case DLL THREAD DETACH:case DLL PROCESS DETACH:break ;}return TRUE;}/∗==========================================================================∗ /DRIVERMODEL API i n t DriverModelSetValue ( long type ,114long index1 ,long index2 ,long long va lue ,double double value ,char ∗ s t r i n g va l u e ){/∗ Sets the value o f a data ob jec t o f type <type>, se lec ted by <index1> ∗ //∗ and poss ib l y <index2>, to <long va lue>, <double value> or ∗ //∗ <∗s t r i ng va l ue> ( ob jec t and value se l e c t i on depending on <type>) . ∗ //∗ Return value i s 1 on success , otherwise 0 . ∗ /switch ( type ) {case DRIVER DATA PATH :case DRIVER DATA TIMESTEP :case DRIVER DATA TIME :return 1;case DRIVER DATA VEH ID :/∗ rese t lead ing veh i c l e ’ s data f o r t h i s new veh i c l e ∗ /l e ad veh i c l e d i s t ance = 999.0 ;l ead veh i c l e speed d i f f e r ence = −99.0;l ead veh i c l e l eng t h = 0 . 0 ;return 1;case DRIVER DATA VEH LANE :veh i c l e l ane = long va lue ;return 1;case DRIVER DATA VEH ODOMETER:case DRIVER DATA VEH LANE ANGLE :case DRIVER DATA VEH LATERAL POSITION :return 1;case DRIVER DATA VEH VELOCITY :cur rent speed = double va lue ;v f = cur rent speed ;return 1;case DRIVER DATA VEH ACCELERATION:case DRIVER DATA VEH LENGTH:case DRIVER DATA VEH WIDTH :case DRIVER DATA VEH WEIGHT :case DRIVER DATA VEH MAX ACCELERATION:return 1;case DRIVER DATA VEH TURNING INDICATOR :t u r n i n g i n d i c a t o r = long va lue ;return 1;case DRIVER DATA VEH CATEGORY:veh i c l e ca tego ry = long va lue ;return 1;case DRIVER DATA VEH PREFERRED REL LANE :case DRIVER DATA VEH USE PREFERRED LANE:return 1;case DRIVER DATA VEH DESIRED VELOCITY :o r i g i n a l d e s i r e d v e l o c i t y = double va lue ;return 1;case DRIVER DATA VEH X COORDINATE :case DRIVER DATA VEH Y COORDINATE :case DRIVER DATA VEH TYPE :return 1;case DRIVER DATA VEH COLOR:/∗ veh i c l e co l o r = long va lue ; ∗ /veh i c l e co l o r = CMYK(255 , 255 , 0 , 0) ;return 1;case DRIVER DATA VEH CURRENT LINK :return 0; /∗ ( To avoid ge t t i n g sent l o t s o f DRIVER DATA VEH NEXT LINKS messages ) ∗ //∗ Must re t u rn 1 i f these messages are to be sent from VISSIM !↪→ ∗ /case DRIVER DATA VEH NEXT LINKS :case DRIVER DATA VEH ACTIVE LANE CHANGE :case DRIVER DATA VEH REL TARGET LANE :case DRIVER DATA NVEH ID :case DRIVER DATA NVEH LANE ANGLE :115case DRIVER DATA NVEH LATERAL POSITION :return 1;case DRIVER DATA NVEH DISTANCE :i f ( index1 == 0 && index2 == 1) { /∗ l ead ing veh i c l e on own lane ∗ /l e ad veh i c l e d i s t ance = double va lue ;}else i f ( index1 == 0 && index2 == −1) {t a i l v e h i c l e d i s t a n c e = double va lue ;}else i f ( index1 == 0 && index2 == 2) {l ead veh i c l e d i s t ance2 = double va lue ;}else i f ( index1 == 0 && index2 == −2) {t a i l v e h i c l e d i s t a n c e 2 = double va lue ;}i f ( veh i c l e l ane == 1) {i f ( index1 == 1 && index2 == 1) {l e f t l e a d v e h i c l e d i s t a n c e = double va lue ;}else i f ( index1 == 1 && index2 == −1) {l e f t t a i l v e h i c l e d i s t a n c e = double va lue ;}else i f ( index1 == 1 && index2 == 2) {l e f t l e a d v eh i c l e d i s t a n c e2 = double va lue ;}else i f ( index1 == 1 && index2 == −2) {l e f t t a i l v e h i c l e d i s t a n c e 2 = double va lue ;}}else i f ( veh i c l e l ane == 2) {i f ( index1 == 1 && index2 == 1) {r i g h t l e a d veh i c l e d i s t a n c e = double va lue ;}else i f ( index1 == 1 && index2 == −1) {r i g h t t a i l v e h i c l e d i s t a n c e = double va lue ;}else i f ( index1 == 1 && index2 == 2) {r i g h t l e ad veh i c l e d i s t a n ce2 = double va lue ;}else i f ( index1 == 1 && index2 == −2) {r i g h t t a i l v e h i c l e d i s t a n c e 2 = double va lue ;}}return 1;case DRIVER DATA NVEH REL VELOCITY :i f ( index1 == 0 && index2 == 1) { /∗ l ead ing veh i c l e on own lane ∗ /l ead veh i c l e speed d i f f e rence = double va lue ;vp = current speed − l ead veh i c l e speed d i f f e rence ;}return 1;case DRIVER DATA NVEH ACCELERATION:i f ( index1 == 0 && index2 == 1) {ap = double va lue ;}return 1;case DRIVER DATA NVEH LENGTH:i f ( index1 == 0 && index2 == 1) { /∗ l ead ing veh i c l e on own lane ∗ /l e ad veh i c l e l eng t h = double va lue ;s = l ead veh i c l e d i s t ance − l e ad veh i c l e l eng t h ;}return 1;case DRIVER DATA NVEH WIDTH :case DRIVER DATA NVEH WEIGHT :case DRIVER DATA NVEH TURNING INDICATOR :case DRIVER DATA NVEH CATEGORY:i f ( index1 == 0 && index2 == 1) {l ead veh i c l e ca tego ry = long va lue ;116}i f ( index1 == 0 && index2 == −1) {t a i l v e h i c l e c a t e g o r y = long va lue ;}i f ( index1 == 0 && index2 == 2) {l ead veh i c l e ca tego ry2 = long va lue ;}i f ( index1 == 0 && index2 == −2) {t a i l v e h i c l e c a t e g o r y 2 = long va lue ;}i f ( veh i c l e l ane == 2) {l ead p la toon = 0;j o i n p l a t o on = 0;i f ( index1 == −1 && index2 == 1) {r i g h t l e ad veh i c l e c a t e go r y = long va lue ;}i f ( index1 == −1 && index2 == −1) {r i g h t t a i l v e h i c l e c a t e g o r y = long va lue ;}i f ( index1 == −1 && index2 == 2) {r i g h t l e ad veh i c l e ca t ego r y2 = long va lue ;}i f ( index1 == −1 && index2 == −2) {r i g h t t a i l v e h i c l e c a t e g o r y 2 = long va lue ;}i f ( l ead veh i c l e ca tego ry != veh i c l e ca tego ry && t a i l v e h i c l e c a t e g o r y ==↪→ veh i c l e ca tego ry && t a i l v e h i c l e d i s t a n c e >= −50) {l ead p la toon = 1;j o i n p l a t o on = 0;}else i f ( l ead veh i c l e ca tego ry == veh i c l e ca tego ry && t a i l v e h i c l e c a t e g o r y ==↪→ veh i c l e ca tego ry && t a i l v e h i c l e d i s t a n c e >= −50 && lead veh i c l e d i s t ance↪→ >= 50) {l ead p la toon = 1;j o i n p l a t o on = 0;}i f ( l ead veh i c l e ca tego ry == veh i c l e ca tego ry && lead veh i c l e d i s t ance <= 50) {i f ( l ead p la toon == 0) {l ead p la toon = 0;j o i n p l a t o on = 1;} else i f ( l ead p la toon == 1) {l ead p la toon = 1;j o i n p l a t o on = 0;}}i f ( l ead veh i c l e ca tego ry != veh i c l e ca tego ry && t a i l v e h i c l e c a t e g o r y !=↪→ veh i c l e ca tego ry ) {j o i n p l a t o on = 0;lead p la toon = 0;}}else i f ( veh i c l e l ane == 1) {l ead p la toon = 0;j o i n p l a t o on = 0;i f ( index1 == 1 && index2 == 1) {l e f t l e a d v eh i c l e c a t e g o r y = long va lue ;}i f ( index1 == 1 && index2 == −1) {l e f t t a i l v e h i c l e c a t e g o r y = long va lue ;}i f ( index1 == 1 && index2 == 2) {l e f t l e a d veh i c l e c a t e go r y 2 = long va lue ;}i f ( index1 == 1 && index2 == −2) {l e f t t a i l v e h i c l e c a t e g o r y 2 = long va lue ;}117}return 1;case DRIVER DATA NVEH LANE CHANGE:case DRIVER DATA NO OF LANES :case DRIVER DATA LANE WIDTH :case DRIVER DATA LANE END DISTANCE :case DRIVER DATA RADIUS :case DRIVER DATA MIN RADIUS :case DRIVER DATA DIST TO MIN RADIUS :case DRIVER DATA SLOPE :case DRIVER DATA SLOPE AHEAD:case DRIVER DATA SIGNAL DISTANCE :case DRIVER DATA SIGNAL STATE :case DRIVER DATA SIGNAL STATE START :case DRIVER DATA SPEED LIMIT DISTANCE :case DRIVER DATA SPEED LIMIT VALUE :return 1;case DRIVER DATA DESIRED ACCELERATION :des i r ed acce l e ra t i on = double va lue ;return 1;case DRIVER DATA DESIRED LANE ANGLE :/ / des i red lane ang le = double va lue ;return 1;case DRIVER DATA ACTIVE LANE CHANGE :o r i g i na l a c t i v e l ane change = long va lue ;return 1;case DRIVER DATA REL TARGET LANE :r e l t a r g e t l a n e = long va lue ;return 1;defaul t :return 0;}}/∗−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−∗ /DRIVERMODEL API i n t DriverModelGetValue ( long type ,long index1 ,long index2 ,long ∗ long va lue ,double ∗double value ,char ∗∗ s t r i n g va l u e ){/∗ Gets the value o f a data ob jec t o f type <type>, se lec ted by <index1> ∗ //∗ and poss ib l y <index2>, and wr i t e s t ha t value to <∗double value>, ∗ //∗ <∗f l o a t v a l ue> or <∗∗s t r i ng va l ue> ( ob jec t and value se l e c t i on ∗ //∗ depending on <type>) . ∗ //∗ Return value i s 1 on success , otherwise 0 . ∗ /switch ( type ) {case DRIVER DATA STATUS :∗ l ong va lue = 0;return 1;case DRIVER DATA VEH TURNING INDICATOR :∗ l ong va lue = t u r n i n g i n d i c a t o r ;return 1;case DRIVER DATA VEH DESIRED VELOCITY :i f ( l ead p la toon == 1) {/ / d e s i r e d ve l o c i t y = 22.2223; / / 80km/ h/ / d e s i r e d ve l o c i t y = 100 / 3 . 6 ; / / 100km/ hi f ( l ead veh i c l e d i s t ance <= 50) {des i r e d ve l o c i t y = vp ;}else {/ / d e s i r e d ve l o c i t y = 100 / 3 . 6 ; / / changing a l l speeds to be 100km/ h .des i r e d ve l o c i t y = o r i g i n a l d e s i r e d v e l o c i t y ; / / w i l l be w i t h i n the↪→ o r i g i n a l speed d i s t r i b u t i o n .}118}else i f ( j o i n p l a t o on == 1) {des i r e d ve l o c i t y = vp ;}else { des i r e d ve l o c i t y = o r i g i n a l d e s i r e d v e l o c i t y ; }∗double va lue = des i r e d ve l o c i t y ;return 1;case DRIVER DATA VEH COLOR:i f ( j o i n p l a t o on == 1) {veh i c l e co l o r = CMYK(255 , 255 , 255 , 255) ;}else i f ( l ead p la toon == 1) {veh i c l e co l o r = CMYK(255 , 0 , 0 , 0) ;}∗ l ong va lue = veh i c l e co l o r ;return 1;case DRIVER DATA WANTS SUGGESTION:∗ l ong va lue = 1;return 1;case DRIVER DATA DESIRED ACCELERATION : {/ / Acce le ra t i on i s based on :/ / ac = ( ka∗ap ) + ( kv∗( vp − v f ) ) + ( ks∗( s − v f∗ t ) ) ;/ / a = max [ amin , min ( ac , amax) ]i f ( j o i n p l a t o on == 1) {ac = ( ka∗ap ) + ( kv∗( vp − v f ) ) + ( ks∗( s − v f∗ td ) ) ;des i r ed acce l e ra t i on = max( amin , min ( ac , amax) ) ;}else i f ( l ead p la toon == 1) { / / need to ensure t ha t t h i s takes i n t o cons ide ra t i on the↪→ des i red v e l o c i t y as we l l − i f the lead veh i c l e i s f a s t e r than the des i red v e l o c i t y↪→ then t h i s needs to not speed up to the lead veh i c l e f o r a lead p la toon veh i c l e .i f ( l ead veh i c l e d i s t ance <= 50) {ac = ( kv∗( vp − v f ) ) + ( ks∗( s − v f ∗1.4) ) ;des i r ed acce l e ra t i on = max( amin , min ( ac , amax) ) ;}}/ / Added a sec t ion to cause the CACC veh ic les to act l i k e ACC veh ic les regard less o f i f they are lead ing a↪→ pla toon or not .else {i f ( l ead veh i c l e d i s t ance <= 50) {ac = ( ka∗ap ) + ( kv∗( vp − v f ) ) + ( ks∗( s − v f ∗1.4) ) ;des i r ed acce l e ra t i on = max( amin , min ( ac , amax) ) ;}}∗double va lue = des i r ed acce l e ra t i on ;return 1;}case DRIVER DATA DESIRED LANE ANGLE :/ / ∗double va lue = des i red lane ang le ;return 0;case DRIVER DATA ACTIVE LANE CHANGE :/ / Veh ic le i s i n the r i g h t lane , and a veh i c l e immediate ly to the l e f t and i n f r o n t o f i t↪→ i s e i t h e r lead ing a p la toon or i n a platoon , and the veh i c l e immediate ly to the↪→ l e f t and behind i t i s not i n the p la toon .i f ( veh i c l e l ane == 1 && l e f t l e a d v eh i c l e c a t e g o r y == veh i c l e ca tego ry && (↪→ l e f t t a i l v e h i c l e c a t e g o r y != veh i c l e ca tego ry | | ( l e f t t a i l v e h i c l e c a t e g o r y ==↪→ veh i c l e ca tego ry && ( l e f t t a i l v e h i c l e d i s t a n c e < −50 | | (↪→ l e f t l e a d v e h i c l e d i s t a n c e − l e f t t a i l v e h i c l e d i s t a n c e )>50) ) ) ) {i f ( l e f t t a i l v e h i c l e d i s t a n c e <= −15 && l e f t l e a d v e h i c l e d i s t a n c e >= 5 &&↪→ l e f t l e a d v e h i c l e d i s t a n c e < 50) { / / Make sure the d is tances are↪→ s u f f i c i e n t to change lanes . NEED TO CONFIRM THESE NUMBERS. . .ac t ive lane change = 1;}else {ac t ive lane change = o r i g i na l a c t i v e l ane change ;}119}else i f ( veh i c l e l ane == 1 && l e f t l e a d v eh i c l e c a t e g o r y != veh i c l e ca tego ry &&↪→ l e f t t a i l v e h i c l e c a t e g o r y == veh i c l e ca tego ry && ( l e f t t a i l v e h i c l e c a t e g o r y 2 !=↪→ veh i c l e ca tego ry | | ( l e f t t a i l v e h i c l e c a t e g o r y 2 == veh i c l e ca tego ry && (↪→ l e f t t a i l v e h i c l e d i s t a n c e − l e f t t a i l v e h i c l e d i s t a n c e 2 )< −50) ) ) { / / VEHICLE IS↪→ IN THE RIGHT LANE AND CAN CHANGE LANES INTO THE LEFT LANE IN ORDER TO BEGIN↪→ LEADING A PLATOON.i f ( l e f t t a i l v e h i c l e d i s t a n c e <= −5 && l e f t t a i l v e h i c l e d i s t a n c e > −50 &&↪→ l e f t l e a d v e h i c l e d i s t a n c e >= 15) {ac t ive lane change = 1;}else {ac t ive lane change = o r i g i na l a c t i v e l ane change ;}}else {ac t ive lane change = o r i g i na l a c t i v e l ane change ;}∗ l ong va lue = ac t ive lane change ;return 1;case DRIVER DATA REL TARGET LANE :∗ l ong va lue = r e l t a r g e t l a n e ;return 1;case DRIVER DATA SIMPLE LANECHANGE:∗ l ong va lue = 1;return 1;defaul t :return 0;}}/∗==========================================================================∗ /DRIVERMODEL API i n t DriverModelExecuteCommand ( long number ){/∗ Executes the command <number> i f t h a t i s ava i l ab l e i n the d r i v e r ∗ //∗ module . Return value i s 1 on success , o therwise 0 . ∗ /switch ( number ) {case DRIVER COMMAND INIT :return 1;case DRIVER COMMAND CREATE DRIVER:return 1;case DRIVER COMMAND KILL DRIVER :return 1;case DRIVER COMMAND MOVE DRIVER:return 1;defaul t :return 0;}}/∗==========================================================================∗ //∗ End of CACCPlatooningModel . cpp ∗ //∗==========================================================================∗ /B.2 C++ DLL ACC Driver Behaviour ModelThe following is the C++ code for the Dynamic Linked Library to replace the driver behaviourmodel for the ACC vehicles.120/∗==========================================================================∗ //∗ ACCPlatooningModel . cpp DLL Module f o r VISSIM ∗ //∗ ∗ //∗ I n t e r f a ce module f o r ex te rna l d r i v e r models . ∗ //∗ Example vers ion wi th a very simple d r i v e r model . ∗ //∗ ∗ //∗ Version o f 2015−08−29 Mar t in Fyfe ∗ //∗ Based on 2012−08−28 vers ion by Lukas Kautzsch ∗ //∗==========================================================================∗ /#include ” ACCPlatooningModel . h ”/∗==========================================================================∗ /double cur rent speed = 0 .0 ;double des i r ed acce l e ra t i on = 0 . 0 ;double o r i g i n a l d e s i r e d v e l o c i t y = 0 . 0 ;double des i red lane ang le = 0 . 0 ;long ac t ive lane change = 0;long r e l t a r g e t l a n e = 0;double des i r e d ve l o c i t y = 0 . 0 ;long t u r n i n g i n d i c a t o r = 0 ;long veh i c l e co l o r = CMYK(255 ,255 ,255 ,255) ;double l e ad veh i c l e d i s t ance = 999.0 ;double l ead veh i c l e speed d i f f e r ence = −99.0;double l e ad veh i c l e l eng t h = 0 . 0 ;double ka = 0 . 0 ;double kv = 0 .58 ;double ks = 0 . 1 ;double ac = 0 . 0 ;double ap = 0 .0 ;double vp = 0 . 0 ;double v f = 0 . 0 ;double s = 0 . 0 ;double v = 0 . 0 ;double td = 1 . 4 ; / / 1.4 s gap .double amin = −3.0;double amax = 2 .0 ;/∗==========================================================================∗ /BOOL APIENTRY Dl lMain (HANDLE hModule ,DWORD u l r e a s on f o r c a l l ,LPVOID lpReserved ){switch ( u l r e a s o n f o r c a l l ) {case DLL PROCESS ATTACH:case DLL THREAD ATTACH:case DLL THREAD DETACH:case DLL PROCESS DETACH:break ;}return TRUE;}/∗==========================================================================∗ /DRIVERMODEL API i n t DriverModelSetValue ( long type ,long index1 ,long index2 ,long long va lue ,double double value ,char ∗ s t r i n g va l u e ){/∗ Sets the value o f a data ob jec t o f type <type>, se lec ted by <index1> ∗ //∗ and poss ib l y <index2>, to <long va lue>, <double value> or ∗ /121/∗ <∗s t r i ng va l ue> ( ob jec t and value se l e c t i on depending on <type>) . ∗ //∗ Return value i s 1 on success , otherwise 0 . ∗ /switch ( type ) {case DRIVER DATA PATH :case DRIVER DATA TIMESTEP :case DRIVER DATA TIME :return 1;case DRIVER DATA VEH ID :/∗ rese t lead ing veh i c l e ’ s data f o r t h i s new veh i c l e ∗ /l e ad veh i c l e d i s t ance = 999.0 ;l ead veh i c l e speed d i f f e r ence = −99.0;l ead veh i c l e l eng t h = 0 . 0 ;return 1;case DRIVER DATA VEH LANE :case DRIVER DATA VEH ODOMETER :case DRIVER DATA VEH LANE ANGLE :case DRIVER DATA VEH LATERAL POSITION :return 1;case DRIVER DATA VEH VELOCITY :cur rent speed = double va lue ;v f = cur rent speed ;return 1;case DRIVER DATA VEH ACCELERATION :case DRIVER DATA VEH LENGTH :case DRIVER DATA VEH WIDTH :case DRIVER DATA VEH WEIGHT :case DRIVER DATA VEH MAX ACCELERATION :return 1;case DRIVER DATA VEH TURNING INDICATOR :t u r n i n g i n d i c a t o r = long va lue ;return 1;case DRIVER DATA VEH CATEGORY :case DRIVER DATA VEH PREFERRED REL LANE :case DRIVER DATA VEH USE PREFERRED LANE :return 1;case DRIVER DATA VEH DESIRED VELOCITY :o r i g i n a l d e s i r e d v e l o c i t y = double va lue ;return 1;case DRIVER DATA VEH X COORDINATE :case DRIVER DATA VEH Y COORDINATE :case DRIVER DATA VEH TYPE :return 1;case DRIVER DATA VEH COLOR :/∗ veh i c l e co l o r = long va lue ; ∗ /veh i c l e co l o r = CMYK(255 , 0 , 255 , 0) ;return 1;case DRIVER DATA VEH CURRENT LINK :return 0; /∗ ( To avoid ge t t i n g sent l o t s o f DRIVER DATA VEH NEXT LINKS messages ) ∗ //∗ Must re t u rn 1 i f these messages are to be sent from VISSIM ! ∗ /case DRIVER DATA VEH NEXT LINKS :case DRIVER DATA VEH ACTIVE LANE CHANGE :case DRIVER DATA VEH REL TARGET LANE :case DRIVER DATA NVEH ID :case DRIVER DATA NVEH LANE ANGLE :case DRIVER DATA NVEH LATERAL POSITION :return 1;case DRIVER DATA NVEH DISTANCE :i f ( index1 == 0 && index2 == 1) { /∗ l ead ing veh i c l e on own lane ∗ /l e ad veh i c l e d i s t ance = double va lue ;}return 1;case DRIVER DATA NVEH REL VELOCITY :i f ( index1 == 0 && index2 == 1) { /∗ l ead ing veh i c l e on own lane ∗ /l ead veh i c l e speed d i f f e r ence = double va lue ;vp = current speed − l ead veh i c l e speed d i f f e rence ;}return 1;122case DRIVER DATA NVEH ACCELERATION :i f ( index1 == 0 && index2 == 1) {ap = double va lue ;}return 1;case DRIVER DATA NVEH LENGTH :i f ( index1 == 0 && index2 == 1) { /∗ l ead ing veh i c l e on own lane ∗ /l e ad veh i c l e l eng t h = double va lue ;s = l ead veh i c l e d i s t ance − l e ad veh i c l e l eng t h ;}return 1;case DRIVER DATA NVEH WIDTH :case DRIVER DATA NVEH WEIGHT :case DRIVER DATA NVEH TURNING INDICATOR :case DRIVER DATA NVEH CATEGORY :case DRIVER DATA NVEH LANE CHANGE :case DRIVER DATA NO OF LANES :case DRIVER DATA LANE WIDTH :case DRIVER DATA LANE END DISTANCE :case DRIVER DATA RADIUS :case DRIVER DATA MIN RADIUS :case DRIVER DATA DIST TO MIN RADIUS :case DRIVER DATA SLOPE :case DRIVER DATA SLOPE AHEAD :case DRIVER DATA SIGNAL DISTANCE :case DRIVER DATA SIGNAL STATE :case DRIVER DATA SIGNAL STATE START :case DRIVER DATA SPEED LIMIT DISTANCE :case DRIVER DATA SPEED LIMIT VALUE :return 1;case DRIVER DATA DESIRED ACCELERATION :des i r ed acce l e ra t i on = double va lue ;return 1;case DRIVER DATA DESIRED LANE ANGLE :des i red lane ang le = double va lue ;return 1;case DRIVER DATA ACTIVE LANE CHANGE :ac t ive lane change = long va lue ;return 1;case DRIVER DATA REL TARGET LANE :r e l t a r g e t l a n e = long va lue ;return 1;defaul t :return 0;}}/∗−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−∗ /DRIVERMODEL API i n t DriverModelGetValue ( long type ,long index1 ,long index2 ,long ∗ long va lue ,double ∗double value ,char ∗∗ s t r i n g va l u e ){/∗ Gets the value o f a data ob jec t o f type <type>, se lec ted by <index1> ∗ //∗ and poss ib l y <index2>, and wr i t e s t ha t value to <∗double value>, ∗ //∗ <∗f l o a t v a l ue> or <∗∗s t r i ng va l ue> ( ob jec t and value se l e c t i on ∗ //∗ depending on <type>) . ∗ //∗ Return value i s 1 on success , otherwise 0 . ∗ /switch ( type ) {case DRIVER DATA STATUS :∗ l ong va lue = 0;return 1;case DRIVER DATA VEH TURNING INDICATOR :∗ l ong va lue = t u r n i n g i n d i c a t o r ;123return 1;case DRIVER DATA VEH DESIRED VELOCITY :i f ( l ead veh i c l e d i s t ance <= 50) {des i r e d ve l o c i t y = vp ;}else {des i r e d ve l o c i t y = o r i g i n a l d e s i r e d v e l o c i t y ;}∗double va lue = des i r e d ve l o c i t y ;return 1;case DRIVER DATA VEH COLOR :∗ l ong va lue = veh i c l e co l o r ;return 1;case DRIVER DATA WANTS SUGGESTION :∗ l ong va lue = 1;return 1;case DRIVER DATA DESIRED ACCELERATION : {/∗ ### s t a r t commenting out from here f o r ” do noth ing ” ∗ // / double ne t d i s tance = l ead veh i c l e d i s t ance − l e ad veh i c l e l eng t h ;/ / double lead veh ic le speed = current speed − l ead veh i c l e speed d i f f e rence ;/ / double des i red d is tance = lead veh ic le speed ∗1 .4 ;/ / i f ( l ead veh i c l e speed d i f f e r ence > 0) {/ / /∗ we are f a s t e r than the lead ing veh i c l e ∗ // / i f ( l ead veh ic le speed > 0) {/ / i f ( ne t d i s tance > des i red d is tance ) {/ / /∗ slow down to lead ing veh i c l e ’ s speed wi th 1 s t ime gap ∗ // / des i r ed acce l e ra t i on = − l ead veh i c l e speed d i f f e rence/ / ∗ l ead veh i c l e speed d i f f e rence/ / / ( ne t d i s tance − des i red d is tance )/ / / 2 . 0 ;/ / }/ / e lse {/ / /∗ t r y to increase d is tance ∗ // / des i r ed acce l e ra t i on = − l ead veh i c l e speed d i f f e rence − 1 . 0 ;/ / }/ / } /∗ i f ( l ead veh ic le speed > 0) ∗ // / e lse {/ / /∗ l ead ing veh i c l e i s s tanding s t i l l ∗ // / i f ( ne t d i s tance < 2 .1 ) {/ / des i r ed acce l e ra t i on = −9.9; /∗ emergency brak ing ∗ // / }/ / e lse {/ / /∗ brake to s t a n d s t i l l i n 2.0 m dis tance ∗ // / des i r ed acce l e ra t i on = − l ead veh i c l e speed d i f f e rence/ / ∗ l ead veh i c l e speed d i f f e rence/ / / ( ne t d i s tance − 2 .0 )/ / / 2 . 0 ;/ / }/ / }/ / } /∗ i f ( l ead veh i c l e speed d i f f e rence > 0) ∗ // / e lse {/ / /∗ acce le ra te to min o f lead ing veh i c l e ’ s speed and own des i red speed ∗ // / double new speed = des i r e d ve l o c i t y ;/ / i f ( l ead veh ic le speed < des i r e d ve l o c i t y ) {/ / new speed = lead veh ic le speed ;/ / }/ / des i r ed acce l e ra t i on = new speed − cur rent speed ;/ / }/ / /∗ ### comment out u n t i l here f o r ” do noth ing ” ∗ /i f ( l ead veh i c l e d i s t ance <=50){ac = ( ka∗ap ) + ( kv∗( vp − v f ) ) + ( ks∗( s − v f∗ td ) ) ;des i r ed acce l e ra t i on = max( amin , min ( ac , amax) ) ;}∗double va lue = des i r ed acce l e ra t i on ;return 1;}case DRIVER DATA DESIRED LANE ANGLE :124∗double va lue = des i red lane ang le ;return 1;case DRIVER DATA ACTIVE LANE CHANGE :∗ l ong va lue = ac t ive lane change ;return 1;case DRIVER DATA REL TARGET LANE :∗ l ong va lue = r e l t a r g e t l a n e ;return 1;case DRIVER DATA SIMPLE LANECHANGE :∗ l ong va lue = 1;return 1;defaul t :return 0;}}/∗==========================================================================∗ /DRIVERMODEL API i n t DriverModelExecuteCommand ( long number ){/∗ Executes the command <number> i f t h a t i s ava i l ab l e i n the d r i v e r ∗ //∗ module . Return value i s 1 on success , o therwise 0 . ∗ /switch ( number ) {case DRIVER COMMAND INIT :return 1;case DRIVER COMMAND CREATE DRIVER :return 1;case DRIVER COMMAND KILL DRIVER :return 1;case DRIVER COMMAND MOVE DRIVER :return 1;defaul t :return 0;}}/∗==========================================================================∗ //∗ End of ACCPlatooningModel . cpp ∗ //∗==========================================================================∗ /125

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
https://iiif.library.ubc.ca/presentation/dsp.24.1-0340300/manifest

Comment

Related Items