Development and Testing of Priority Control System in Connected1

Vehicle Environment23

4

Jun Ding5Department of Systems and Industrial Engineering6

University of Arizona7Tucson, AZ 857218

dingjun@email.arizona.edu910

Qing He11Departments of Civil, Structural, and Environmental (CSEE) and Industrial and Systems12

Engineering (ISE)13University of Buffalo, The State University of New York14

Buffalo, NY 1426015qinghe@buffalo.edu16

17K. Larry Head18

Department of Systems and Industrial Engineering19University of Arizona20

Tucson, AZ 8572121larry@sie.arizona.edu22

23Faisal Saleem24

Maricopa County Department of Transportation252901 W. Durango St.26

Phoenix AZ 8500927faisalsaleem@mail.maricopa.gov28

29Wei Wu30

School of Transportation Engineering31Tongji University32

Shanghai, P.R. China 20180433wuwei@tongji.edu.cn34

35Submitted to TRB 92th Annual Meeting at Washington, D.C. January 201336

Word Count: 750037

Abstract and Manuscript Text: 500038

Number of Tables and Figures: 10 (= 2500 words)39

Ding, He, Head, Saleem, and Wu 1

ABSTRACT1

Traffic signals provide service for multiple modes of travelers including vehicles, trucks, transit,2pedestrians, bicycles, and emergency vehicles. Past research and experience have demonstrated3the benefits of providing traffic signal priority for individual modes such as transit, emergency4vehicles, and trucks. However, the priority treatment for each travel mode was addressed5independently within the normal traffic signal operation. With the advancement of the wireless6communication technologies, the global positioning system, and the development of the vehicle7to vehicle (v2v) and vehicle to infrastructure (v2i) systems, called Connected Vehicles (CV),8there is an opportunity to simultaneously identify, prioritize, and sever requests from multiple9vehicles. This paper demonstrates the implementation of a decision framework for prioritizing10requests for service from multiple modes within an integrated traffic signal control framework.11The framework has been developed and tested using a microscopic hardware-in-the-loop12simulation (HILS) environment based on VISSIM and field tested and demonstrated in a live13network of six intersections in Anthem, Arizona. The successful demonstration shows that the14potential for safer and more efficient multi-modal traffic signal operations is highly possible.15

KEYWORDS16

Priority Traffic Signal Control, Connected Vehicles, hardware-in-the-loop simulation17

18

Ding, He, Head, Saleem, and Wu 2

1. Introduction1

Traffic signal control has experienced very few fundamental improvements in the past 50 years.2The principles of movements controlled by intervals of phases and the use of point detection have3formed the basis for traffic signal control. Coordination, preemption, and priority were higher4level strategic behaviors that control the basic phase intervals by holding and forcing off phases5and rings to achieve the desired behavior. Advances in signal control logic have primarily6focused on enhancing priority control for transit vehicles and adaptively adjusting timing7parameters. Tools and methods have been developed to enable traffic engineers’ better use of8traffic signal control, but the fundamental logic and operations of the controller has not changed.9

Traffic signal control in most urban areas today is dynamic (actuated) in nature and coordinated10with other intersections to enable smooth flow, or progression, of traffic. However, these systems11depend on loop detectors or video based systems that are located at fixed locations in space to call12and extend signal control phases. These detection systems provide basic information such as13vehicle count, occupancy, and/or presence/passage information. This limits the use of advanced14logic that could potentially be built into modern day traffic signal controller (1).15

The advancements in technology for traffic data collection have made it possible to collect a new16form of traffic or vehicle data (i.e., disaggregated/individual traffic or vehicle data). These data17sources fall under the umbrella of probe vehicle technologies (e.g., GPS vehicle probes (2), cell18phone vehicle probes (3), Connected Vehicle probes (4), etc.). The recent advances in vehicle19positioning, probe vehicle technologies and wireless communications provide a significantly20improved opportunity for priority control. In the United States, the concept of Connected21Vehicles aims to provide wireless communications between vehicles and the infrastructure to22support applications to improve safety and mobility (5).The connected vehicle technology has23identified 5.9 GHz Digital Short Range Communication (DSRC) as the primary communications24mode for vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) safety based applications,25denoted as V2X.26

The advances in Connected Vehicle (CV) technologies provide the first real opportunity for27transforming traffic signal control in terms of the traffic signal controller logic, operation, and28performance. Connected Vehicle technology combines leading edge technologies--advanced29wireless communications, on-board computer processing, GPS navigation, equipped30infrastructure, and others--to provide the capability for vehicles to identify threats and hazards on31the roadway and communicate this information over wireless networks to give drivers alerts and32warnings. The advent of DSRC, and other wireless communications technologies, in vehicular33communication provides a critical component that, when coupled with meaningful messages34(SAE J2735), has the potential to provide detailed information required for intelligent traffic35signal control. DSRC can be leveraged to provide real-time knowledge of vehicle class36(passenger, transit, emergency, etc.), position, speed, and acceleration on each approach to an37equipped signalized intersection as well as to provide real-time Signal Phase and Timing (SPaT)38information to authorized vehicles approaching signalized intersections.39

The objective of this study is to develop a multi-modal priority signal control system in which40several priority requests from different modes (e.g. fire engines, public transits) can be41

Ding, He, Head, Saleem, and Wu 3

accommodated simultaneously. This system has been first studied and tested in a microscopic1Hardware-In-a-Loop Simulation (HILS) environment with VISSIM. Then the system has been2demonstrated in a live network of six intersections in Anthem, Arizona.3

2. Literature Review of Priority Signal System4

Signal priority is the technique of changing or maintaining traffic signal timing in order to reduce5the stopped delay for targeted vehicles, like buses or emergency vehicles. Traditional traffic6signal control logic has provided priority for different classes of users (vehicles, pedestrians,7emergency vehicles, transit, etc.) and control strategies (actuated phases and coordination)8through essentially independent mechanisms when the special or desired service is requested.9Preemption and Transit Signal Priority (TSP) are considered as two common types of priority.10Behaviors such as emergency vehicle preemption generally require higher priority consideration11than transit priority might.12

Considering preemption requests within an integrated priority control framework allows multiple13simultaneous preemption requests to be addressed. Traditionally, preemption requests are served14in a first-come-first-served manner with a possible override for one approach over another and15complete override of coordination. Although emergency vehicle operators are trained to be16observant and vigilant, there have been cases in which two emergency vehicles have collided in17an intersection (6). Statistics reveal that nearly 13% of the firefighters and police officers who lost18their lives in the line of duty are killed in vehicle-related incidents (7); roadway safety has been19noted as a significant emergency responder issue recently.20

Coordination is not usually considered a form of priority but the underlying goal is the same: be21sure the traffic signal is in a specific interval (state) at a specific point, or interval, in time.22Including coordination as a form of priority opens the opportunity for multi-modal integration of23many requesting entities within one integrated decision framework. The relative importance of24emergency vehicles, transit, pedestrians, coordination, or other modes can be determined based25on an agencies operating policy.26

TSP is a popular and promising tool for improving transit performance and reliability (8). Much27attention has been paid on developing TSP strategies and documenting the benefits of28implementation (9-13). Basically, TSP can be classified into three categories: passive priority,29active priority, and adaptive or real-time priority (14). Passive priority operates continuously30regardless of whether the transit is present or not (15). Active priority strategies provide priority31service when a transit vehicle sends a priority request (16). Adaptive or real-time TSP strategies32provide priority while trying to optimize given performance criteria including person delay,33transit delay, vehicle delay, and/or a combination of these criteria (17).34

Typically, a priority strategy includes extending a phase to allow a transit vehicle to pass or35terminate conflicting phases allowing early service to reduce delay (18-20). However, it is36possible, and maybe likely, that more than one bus may arrive on conflicting approaches at an37intersection during a cycle. In that case there is a need to simultaneously consider the multiple38requests for priority in a way that is not disruptive, or inefficient, to other traffic. Other factors,39such as occupancy and schedule adherence, are important considerations that can be used to40

Ding, He, Head, Saleem, and Wu 4

manage which priority requests should be served, but it is still likely that multiple transit vehicles1will desire priority service. Although the signal priority control strategies are applied worldwide,2little effort has been spent on the multiple priority requests scenarios (21-24). Integration of the3multiple requests for priority and the desire to operate the signal as part of a coordinated system4indicates there is a need for new signal control logic. Motivated by recent advances in vehicle5positioning, V2X communications, and DSRC technology, this paper addresses the simulation6and field implementation of an integrated priority control framework for multi-modal traffic7signal control.8

3. Architecture of Multiple Priority Requests (MPR) Signal Control System9

Among many wireless communication technologies including WiFi, 3G/4G, DSRC, and10Bluetooth, DSRC was chosen as the communication platform for information exchange because11of its low latency which is typically less than one second. The National Transportation12Communications for ITS Protocol (NTCIP) provides both communication protocols and the13vocabulary (called objects) necessary to allow electronic traffic control equipment from different14manufacturers to operate with each other as a system. The NTCIP 1211 Signal Control and15Priority (SCP) Concept of Operations is comprised of two primary components, the Priority16Request Generator (PRG) and a Priority Request Server (PRS). A vehicle acting as the PRG,17which could be an emergency vehicle, transit bus, light rail train, or other type of transit or18priority eligible vehicle, submits a request for priority to the PRS. These two elements can be19thought of as a logical process that could be physically implemented in more than one way. The20standardization occurs at the interface of these processes and represents the objects developed by21NTCIP 1211.22

The two primary interfaces are (1) between PRG and PRS and (2) between PRS and the traffic23signal controller. Based on where the PRG and PRS are located and what inputs are being24transmitted and received, five SCP scenarios are proposed in (25) to provide a logical architecture25for implementation of priority in different traffic operating environments. At a systematic level,26these five scenarios can be categorized according to whether they are implementing priority in a27centralized or distributed architecture. These architectures are based upon the traffic signal28system, on-board vehicle equipment, and communication infrastructure. The major concepts of29the distributed architecture are adopted in the multiple request priority control system discussed30in this paper. The system architecture of implementation is illustrated in Figure 1.31

Ding, He, Head, Saleem, and Wu 5

1

Figure 1.System architecture of MPR signal system (V2I)2

According to the Intelligent Transportation Society of America (ITSA) (26), a physical TSP3system is composed of three major components: the vehicle detection system that detects transit4vehicles and generates priority requests, the traffic signal control system that receives and5processes the request for priority at the intersections, and the communications system that links6the vehicle detection system with the traffic signal control system. This architecture is not limited7to TSP and is appropriate for all forms of priority control.8

In the multiple request based priority signal control system, the three major components are the9On-Board Equipment (OBE), Road Side Equipment (RSE), and the Actuated Signal Controller10(ASC). The vehicle detection system and priority request generator (PRG) are realized by the11OBE, while the communication system is realized by the wireless (DSRC) system, and the12request processing system (PRS) is realized by the RSE. There is also communication between13the RSE and traffic signal controller to implement the priority timing strategy from the PRS. All14these systems and communications are achieved by the applications (software) residing in the15OBE, RSE, and traffic signal controller.16

The OBE is a vehicle-resident device that is comprised of an embedded computer with DSRC,17WiFi, and positioning system (GPS) accurate to within two meters in normal operation. Two18major and one visualization software applications are running on the OBE:19

obe_listener: “listens” and receives messages , including a MAP (a map with20geometric information about the intersection), from nearby RSEs.21

Vehicle side Infrastructure side

GPS Antenna

DSRC networksPriority requests

PriorityRequestServer

Antenna

TrafficController

EthernetNTCIP

SignalStatus

MAPRequest tableSignal status

Cabinet

Priority RequestGenerator

MultiplePriorityRequestSolver

RSE

OBE

Ding, He, Head, Saleem, and Wu 6

obe_PRG: generates the request(s) based on the GPS data and MAPs that are1received.2

obe_webserver: provides a user interface for visualizing the signal status, request table3and priority control status.4

The flow of events in the OBE includes:5

1. A connected vehicle, OBE, continuously receives messages from nearby RSEs including6a digital MAP of the intersection, current signal status, and a table of priority requests7that are currently being served by the RSE. The obe_listener is responsible for this8process.9

2. The connected vehicle (OBE) reads vehicle information including the speed, position,10and heading from the GPS receiver and vehicle systems. This occurs frequently, such as11at 5 Hz.12

3. The connected vehicle (OBE) parses the MAP and locates its position using the GPS13data. It determines the estimated time of arrival (ETA) at the intersection stop bar. It also14determines the desired service phase (traffic signal phase) using data included in the15MAP (Note: the current SAE J2735 MAP message does not include the movement based16service phase and recommends using an in-lane and out-lane pair instead of service17phase. This requires that the RSE translate the in-lane and out-lane to signal phase).18

4. The connected vehicle (OBE) formats and transmits a signal request message (SRM)19based on the service phase, ETA and vehicle type to the RSE. This processing is done by20the obe_PRG process.21

The RSE is an intersection-resident device comprised of an embedded computer with DSRC,22WiFi, and Ethernet connections. Each RSE is connected to the intersection’s traffic-signal23controller using the Ethernet connection. The RSE receives prioritized requests from approaching24Priority Request Generators (PRG) - connected (OBE equipped) vehicles.25

The RSE then formulates the received requests of varying priority levels into an optimization26problem that is solved to provide a signal timing schedule that will minimize the weighted27priority delay. Details of the optimization problem can be found in (22-23). The solution of the28optimization problem generates a signal timing schedule that provides the time for each phase to29serve between the current time and the total time requested by all active priority requests. The30schedule is implemented on the ASC controller by setting NTCIP phase control objects including31phase HOLD, phase FORCE-OFFs, phase CALL, and phase OMIT commands.32

Three applications are running in the RSE:33

rse_PRS: receives requests from approaching connected vehicles and selects which34requests to serve.35

rse_mprsolver: solves the optimization problem formed by the selected requests and36current signal status, and then implements the schedule on the ASC.37

rse_msg_transmitter: transmits (broadcasts) current signal status, the MAP of the38intersection, and the table of active request.39

Ding, He, Head, Saleem, and Wu 7

The flow of events in the RSE includes:1

1. The RSE reads the signal timing and phase status from the signal controller.22. The RSE receives requests from approaching equipped vehicles (OBEs) and updates the3

table of active priority requests.43. The RSE decides when to solve the optimization problem based on changes to the request5

table. The request table can be updated by the receipt of a new request, the updating of an6existing request, or the canceling of an existing request. The RSE will implement the7solution from the solver using NTCIP commands.8

4. The RSE continuously (1Hz) broadcasts messages that include the MAP of the9intersection, signal status and request table.10

4. Microscopic Hardware-In-a-Loop Simulation (VISSIM) Testing Support11

Successful deployment of the priority based traffic signal control algorithm requires thorough12laboratory testing and evaluation using simulation before field implementation. Many traffic13control algorithms have been studied using hardware-in-the-loop simulation (27-28).14Hardware-in-the-loop simulation uses a combination of simulation software and real signal15controller hardware to evaluate traffic conditions and priority control algorithms in a16laboratory setting. Compared to the traditional HILS, that primarily includes traffic signal17controllers, simulation of Connected Vehicle systems also requires RSEs and OBEs as well.18

19The implementation of hardware-in-the-loop simulation is based on the use of a microscopic20simulation program, VISSIM in this study, with an Econolite ASC/3 controller, and two21Savari MobileWave units, one that is used as the RSE and one, or more, that are used as22OBEs. In addition, OBEs can be simulated in software so more vehicles can be considered in23a simulation scenario. A controller interface device (CID) is used to provide a real-time link24between the simulation program and the traffic controller (29). Figure2 illustrates the setup25used in the HILS. The HILS needs to be run in real-time to coordinate the VISSIM simulation26and hardware traffic controller unit, hence the simulation speed in VISSIM was set to one27simulation second per second and ten simulation steps per second.28

29

30

Ding, He, Head, Saleem, and Wu 8

1

Figure 2 Hardware-In-a-Loop Simulation Setup2

The HILS schematic is shown in Figure 3. The simulation computer, RSE, OBE, and the ASC/33controller are all in the same Local Area Network (LAN) domain. As shown in Figure 3, these4devices all have the Ethernet IP address starting with “LAN IP.*”. The DSRC and WiFi in the5OBEs and RSEs are also in the same domain, so the OBE and RSE can communicate to each6other. Three types of network connections are considered. The first is the Ethernet connection7between RSE and Econolite ASC/3 controller, hardware and software OBEs and the computer8running VISSIM. The priority control applications (software) running on the RSE can retrieve9controller status and implement a priority timing schedule on the controller by communicating to10it through NTCIP. A Dynamic-link library (DriverModel.dll) is used to pass a message from11VISSIM to the OBEs. The DriverModel.dll gets the x-y position of the specified (connected)12vehicle modeled in VISSIM, converts the x-y position to real-world GPS coordinates and sends13this position information to the OBE’s IP address. The second is the DSRC connection between14hardware OBEs and RSE, which allows the RSE and hardware OBEs exchange information. The15third is WiFi connection between a laptop running Putty Terminal and the RSE or OBE. After16connecting the laptop to RSE or OBE through WiFi, one can log into the RSE or OBE using17Putty Terminal to view status of the applications that are running. If the laptop is connected to an18OBE, the signal status and request table etc. can be displayed in a web browser by calling a shell19script in OBE.20

NIATT Controller Interface Device

VISSIM Simulation ASC/3 Controller

OBE

RSE

Ding, He, Head, Saleem, and Wu 9

1Figure 3 HILS schematic for the priority based signal control research2

The flow of the HILS is described as the following:34

1. Run the isolated intersection, or network, in VISSIM with the specified GPS position5origin and scale, see Figure 4.6

2. In the DriverModel.dll, convert the x-y positions of the connected vehicles into real7world positions (GPS coordinates) (30).8

3. The connected vehicles send the converted “GPS” coordinates to the associated OBE.94. The OBEs receive MAP, signal status and the active request table from RSE and “GPS”10

coordinates from VISSIM. The OBEs determine whether to send out request or not by11parsing the received MAP and based on a defined DSRC range.12

If priority request table is updated in the RSE, the RSE_mprsolver application will form a priority13control optimization problem and solve it, then implement the schedule (solution) through NTCIP14on the Econolite ASC/3 controller connected to the CID. The CID will update the controller15status in VISSIM.16

5. Field Experiments in Anthem17

The Maricopa County Department of Transportation SMARTDrive field test bed is a state-of-the-18art laboratory for testing new transportation technologies systems under the connected vehicle19environment, including vehicle prioritization at six signalized traffic intersections along a 2.3-20mile stretch of Daisy Mountain Drive in the Anthem, Arizona. A live demonstration of the21multiple request based priority control strategy was conducted on April 26, 2012. This22demonstration included equipping the six intersections with RSEs and several vehicles (two23REACT vehicles, one fire engine, and a Valley Metro Transit Bus) with OBEs to demonstrate the24

Ding, He, Head, Saleem, and Wu 10

capabilities of the system to manage public transit and emergency vehicles during mock incident1responses.2

3

Figure 4: An isolated intersection in VISSIM: Daisy Mountain Dr. and Gavilan Peak4

Participants in the demonstration boarded a Valley Metro bus and traveled through the5SMARTDrive network as shown in Figure 5. Along the route, three scenarios involving6Emergency Vehicles (EVs) were demonstrated:7

1. The bus starts at the west end of the network and proceeds along Daisy Mountain Drive.82. While the bus was approaching Anthem Way from Memorial (phase 8), a REACT9

(Regional Emergency Action Coordinating Team) vehicle (EV) was approaching from10the northwest (phase 2). The priority requests were visible to the participants on the bus,11and the transit priority was overridden by the EV priority. The exact timing sequence12depended on where in the cycle the signal was when it received the first and second13requests, but the timing favored the higher priority EV;14

3. As the bus returned back to the Gavilan Peak intersection (start) approaching from15Dedication (phase 2), a REACT vehicle and a fire engine (both EVs) approached the16intersection from the north and south (phases 4 and 8), but conflicting with the bus.17Priority was granted to the two emergency vehicles and not the bus, but the three requests18were shown in the request table to the bus passengers;19

Ding, He, Head, Saleem, and Wu 11

4. After the bus passed the Gavilan Peak intersection, two more emergency vehicles1approached the intersection from conflicting phases (phases 6 and 8). This allowed the2participants on the bus to see the two vehicle priority requests again and allowed the team3to explain the events, logic, and timing.4

Details for each of these scenarios are described below.5

6

Figure 5 The route for the field demonstration (Courtesy Jeff Jenq, Oz Engineering)7

5.1 Detailed descriptions of the three scenarios involved with EVs8

Different assumptions for the multimodal signal control system are made for the case studies with9and without Emergency Vehicle (EV), listed in Table 1.10

Table 1 Assumptions for case studies with and without emergency vehicle11Without EV With EV

Maximum Green Time extension isMaxGreenTime*(1+a ) for Transit Vehicle(typically 0<a<0.5, “a” is used to extend themaximum green time of the current plan)

Maximum Green Time extension equals 240sfor EV requested phases

No phase skipping allowed

Phases skipping allowedActuated control on non-priority vehiclephases

12

Ding, He, Head, Saleem, and Wu 12

Scenario 1: An EV from conflicting phase to the bus1

When the bus (OBE22) approaches the intersection of Anthem Way and Daisy Mountain Dr.2(phase 8), it is actively requesting phase 8 with priority of level 2 (class TRANSIT). A REACT3vehicle (simulated EV, OBE25) approaches the same intersection on a conflicting movement4from west (phase 2) with a request for phase 2 and 5 with priority of level 1 (class EV).The5RSE_mprsolver in the RSE generates a solution to the optimization problem considering only the6highest priority level 1 request. As can be seen in Figure 6, there is a green tick icon in the first7column of each active request that is being served and a red cross icon in the first column of the8request that is not being served. The bus had to stop before reaching the stop bar, so its queue9clear time is not 0. This accounts for the needed green time to clear the queue that exists between10the bus and the stop bar. It should be noticed that the REACT vehicle (EV) requests two phases11which is the desired behavior when a single emergency vehicle approaches the intersection. This12will allow both the left turn and through movements to serve clearing the approach so the vehicle13can take either movement. The EV route information is not assumed to be known.14

15

Figure 6. When the bus (OBE22) approaches phase 8, a REACT vehicle (OBE25) requests phases162, and 5.17

Scenario 2: Two EVs on concurrent phases but conflicting to the bus18

When the bus (OBE22) returned back to the intersection of Gavilan Peak from Dedication, it19requested phase 6 with priority of level 2 (class TRANSIT). A REACT vehicle (simulated EV,20OBE25) approached this intersection from south (phase 8), requesting phase 8 with priority of21level 1 (class EV), while another fire truck (OBE26) approached this intersection from south22(phase 4) almost simultaneously with the REACT vehicle, requesting phase 4 with priority of23level 1 (class EV). The request table is shown in Figure 7. As can be seen from the request table,24

Ding, He, Head, Saleem, and Wu 13

the queue clear time for the bus is not 0, which means the bus is stopped because of its lower1level of priority. ,2

3

Figure 7 When the bus (OBE22) approached phase 6, a REACT vehicle (OBE25) requested4phase 8 and fire truck (OBE26) requested phase 4.5

Scenario 3: Two EVs from conflicting phases6

After the bus (OBE22) passed the intersection of Gavilan and stopped, a REACT vehicle7(simulated EV, OBE25) approached this intersection from east (phase 6), requesting phase 6 with8priority of level 1, while another fire engine (OBE26) approached this intersection on the9conflicting movement from the south (phase 8) a little later than the REACT vehicle. The request10table is shown in Figure 8. As can be seen from the request table, the queue clear time for OBE2611is not 0, which means the fire engine is stopped because the conflicting phase is served first and it12has to wait in the queue.13

Ding, He, Head, Saleem, and Wu 14

1

Figure 8 After the bus (OBE22) passed the intersection, a REACT vehicle (OBE25) requested2phase 6 and fire engine (OBE26) requested phase 8.3

5.2 The Results of the Field Experiments4

After parsing the log file recording GPS positions, the GPS positions were extracted and plotted5in the GoogleEarth as white dots shown in Figure 9. It is seen that the trace of the bus conforms6very well to the real road. The start position (yellow star) and stop position (yellow triangle) are7used to calculate the travel time for the whole route. When scenario 2 was tested, the bus has to8stop in front of the Gavilan Peak because the EVs approaching at conflicting phases to the bus, so9the time at the stop position is picked to be the end time of the route.10

11

Ding, He, Head, Saleem, and Wu 15

1

Figure 9 The trace from the log file of the bus2

The total route is about 6.23 miles (10 km). Average speed is about 17 m/s (38 mph) for the bus,3and 20 m/s (45 mph) for EVs. After finding the starting time and the ending time for the route,4the travel time was calculated.5

In the demonstration, the travel time for first trip without priority was 0:22:02 hours (1320 s), for6the next three trips with priority the travel times were 0:10:58 hour (658 s), 0:11:20 hour (680 s),7and 0:13:20 hour (800 s), respectively. The average time for the three cases with priority is 713 s.8Although more field tests need to be run in order to show improvement over the none-priority9case or other priority control systems, the observers did experience the benefits brought by the10priority signal control strategy. The multi-modal priority signal control system was also11considered to make public transit more attractive and reliable (31).12

6. Conclusions13

Motivated by the rapid developments of the wireless communication methods especially the14advent of DSRC, a decision framework for prioritizing requests for service from multiple modes15and simultaneously accommodating several priority requests is addressed within an integrated16framework in connected vehicle environment. The setup of HILS and various wireless17communications among different components of HILS are detailed. The validation of the multiple18requests based signal priority control system has been tested and evaluated using microscopic19HILS with VISSIM. The multi-modal priority control system has been demonstrated in a live20network with six-intersection in Anthem, Arizona. The results of the demonstration showed that21the discussed priority control system has the potential to provide safer and more efficient multi-22modal traffic signal operations.23

Ding, He, Head, Saleem, and Wu 16

In addition to the functions like EV priority and transit priority presented in the paper, the priority1control system can be used to realize additional functions including coordination and pedestrians.2More field experiments will be conducted to testify the functions of coordination and other3features in the near future. The Maricopa County SMARTDrive test network is an important tool4in the development and testing of Connected Vehicle applications for advanced transportation5management.6

References7

1. Moon Y. J., Yukyung Park, and Sang-sun Lee. Development of Wireless Interface Signal8Control System for Dynamic and Optimal Management: Project Summary and System9Architecture. Transportation Research Board 85th Annual Meeting, 200610

112. Tong, D., C. Merry, and B. Coifman. Traffic information deriving using GPS probe12

vehicle data integrated with GIS. Geospatial Information Systems for Transportation13Symposium, Columbus, Ohio, 200614

153. Smith,B., H. Zhang, M. Fontaine, and M. Green. Cell phone probes as an ATMS tool.16

Research Report UVACTS-15-5-79, June 2003.1718

4. Dion, F., Robinson, R., and Oh, J. Evaluation of Usability of IntelliDrive Probe Vehicle19Data for Transportation Systems Performance Analysis. J. Transp. Eng., 137(3), pp. 174–20183, 201121

225. Research and Innovative Technology Administration, Connected Vehicle23

Researchhttp://www.its.dot.gov/connected_vehicle/connected_vehicle.htm Accessed July,24201225

266. ABC13, “Houston Fire Department ladder truck involved in accident on Dunlavy at27

Westheimer in Montrose | abc13.com,” Apr-2009. [Online]. Available:28http://abclocal.go.com/ktrk/story?section=news/local&id=6735569 Accessed: July 16th,29201230

317. TSCG, Comments: Strategic Plan for Research, Development & Technology Activities32

(2010-2015) –Docket ID RITA 2009-0005, February 8, 20103334

8. Smith, H., B. Hemily, and M. Ivanovic, Transit Signal Priority (TSP): A Planning and35Implementation Handbook. Washington D.C.: ITS America, 2005.36

379. Yagar,S., and B. Han. A Procedure for Real-Time Signal Control that Considers Transit38

Interference, Transportation Research, 28B(4), pp. 315-331, 19943940

10. Hunter, K., W. Kloos,and A. Danaher. Bus priority at traffic signals in Portland: the41Powell Boulevard pilot project, Transportation Research Record 1503, pp. 29-33, 199542

43

Ding, He, Head, Saleem, and Wu 17

11. Janos, M. and P.Furth. Bus priority with highly interruptible traffic signal control:1simulation of San Juan’s Avenida Ponce de Leon, Transportation Research Record21811,pp. 157–165, 2001.3

412. Furth, P. and T. Muller, Conditional Bus Priority at Signalized Intersections: Better5

Service Quality with Less Traffic Disruption. Transportation Research Record: Journal6of Transportation Research Board, vol. 1731, pp. 23-30, 2000.7

813. Skabardonis A. Control strategies for transit priority, Transportation Research Record:9

Journal of the Transportation Research Board, vol. 1727, pp. 20-26, 2000.1011

14. Baker, R. J. et al. An Overview of Transit Signal Priority, ITS America, Washington,12D.C., 200313

1415. Skabardonis, A. Control strategies for transit priority. Transportation Research Record15

1727, pp.20–26, 20001617

16. Garrow, M., R. Machemehl. Development and evaluation of transit signal priority18strategies, Center for Transportation Research, University of Texas, Austin, 199819

2017. Ma, W., Yang, X. G., Liu Y. Development and Evaluation of Coordinated and21

Conditional Bus Signal Priority Approach. Transportation Research Record, 2145, pp.2249-58, 201023

2418. Evans, H. and G. Skiles, Improving Public Transit Through Bus Preemption of Traffic25

Signals,” Traffic Quarterly, vol. 24, no. 4, pp. 531-543, 1970.2627

19. Balke, K., C. Dudek, and T. Urbanik II. Development and Evaluation of Intelligent Bus28Priority Concept, Transportation Research Record: Journal of the Transportation29Research Board, vol. 1727, 2000.30

3120. Liu, H., A. Skabardonis, and W. Zhang. A Dynamic Model for Adaptive Bus Signal32

Priority, in 82nd Transportation Research Board Annual Meeting, Preprint CD-ROM,332003.34

3521. Head, L. K., D. Gettman, and Z. Wei, Decision Model for Priority Control of Traffic36

Signals, Transportation Research Record: Journal of the Transportation Research Board,37vol. 1978, pp. 169-177, 2006.38

3922. He Q., L. K. Head, and J. Ding. Heuristic Algorithm for Priority Traffic Signal Control.40

Proceeding of the 90th Transportation Research Board Annual Meeting, Washington,41D.C., January 2011.42

4323. He Q., L. K. Head, and J. Ding. PAMSCOD: Platoon-based arterial multi-modal signal44

control with online data. Transportation Research Part C: Emerging Technologies. Vol.4520, Issue 1, Feb. 2012, pp. 164–18446

47

Ding, He, Head, Saleem, and Wu 18

24. Ma, W., Y. Liu, H. Xie, and X. Yang. A Dynamic Programming Model for Bus Signal1Priority with Multiple requests. Proceeding of the 90th Transportation Research Board2Annual Meeting, Washington, D.C., January 2011.3

425. Li, Y., P. Koonce, M. Li, K. Zhou, Y. Li, S. Beaird , W. Zhang, L. Hegen, K. Hu, A.5

Skabardonis, et al., Transit Signal Priority Research Tools. California Partners for6Advanced transit and Highways, 20087

826. ITS America. An overview of transit signal priority, Advanced Traffic Management9

System and Advance Public Transportation System Committees, Washington, D.C., 20031011

27. Bullock, D., B. Johnson, R.B. Wells, M. Kyte, and Z. Li. Hardware-in-the-loop12simulation Transportation Research Part C, 12 (2004), pp. 73–8913

1428. Byrne, N., P. Koonce, R. L. Bertini, C. Pangilinan, and M. Lasky. Using Hardware-in-15

the-Loop Simulation to Evaluate Signal control Strategies for Transit Signal Priority. In16Transportation Research Record: Journal of the Transportation Research Board, No.171925, Transportation Research Board of the National Academies, Washington, D.C.,182005, pp. 227–234.19

2029. National Institute for Advanced Transportation Technology. McCain-NIATT Controller21

Interface Device (CID II) Online User Manual: Version 2. 20022223

30. Farrell J. A. and M. Barth. The Global Positioning System and Inertial Navigation,24McGraw-Hill Professional (1st ed.), 199825

2631. LaHood, Ray http://fastlane.dot.gov/2012/04/arizona-dot-and-partners-roll-out-high-tech-27

traffic-management-prototype.html (online) Accessed: July 16th, 20122829