ITS Transit Standards Professional Capacity Building Program

Module 8: Arterial Management and Transit Signal Priority: Understanding User Needs for Signal Control Priority (SCP) Based on NTCIP 1211 Standard, Part 1 of 2

HTML of the Course Transcript

(Note: This document has been converted from the transcript to 508-compliant HTML. The formatting has been adjusted for 508 compliance, but all the original text content is included.)

Mac Lister’s Introduction

ITS Standards can facilitate the deployment of interoperable ITS systems, and make it easier to develop and deploy regionally integrated transportation systems. However, these benefits can only be realized if you know how to write them into your specifications and test them. This module is one in a series that covers practical applications for promoting multi-modalism and interoperability in acquiring and testing standards-based ITS Transit systems for public transportation providers.

I am Mac Lister, Program Manager, Knowledge, and Technology Transfer in the ITS Joint Program Office of the USDOT and I want to welcome you to our newly redesigned ITS Transit standards training program of which this module is a part. We have worked closely with the Federal Transit Administration and the American Public Transportation Association to develop this material. We are also pleased to be working with our partner, the Institute of Transportation Engineers, to deliver this new approach to training that combines web based modules with instructor interaction to bring the latest in ITS learning to busy professionals like you.

This combined approach allows interested professionals to schedule training at your convenience, without the need to travel. After you complete this training, we hope that you will tell colleagues and customers about the latest ITS standards and encourage them to take advantage of the archived version of the webinars.

ITS Transit Standards training is one of the offerings of our updated Professional Capacity Building (PCB) Training Program specific to transit industry domain to promote the use of ITS Transit standards such as TCIP, Automated Fare Collection, and Transit Management to name a few. Through the PCB program we prepare professionals to adopt proven and emerging ITS technologies that will make surface public transportation systems safer, smarter and greener which improves livability for us all. This series of online courses based on ITS Transit standards is in addition to a 35-module series available for free on ITS Standards for practitioners in state and local highway agencies and transit agencies. You can find information on additional modules and training programs on the USDOT web site at ITS PCB Home.

Please help us continue to make improvements to our training modules through the evaluation process. We look forward to hearing your comments. Thank you again for participating and we hope you find this module helpful.

Jeffrey Spencer’s Introduction

ITS Transit Standards help simplify the complexities, overcome procurement challenges and reduce costs of acquiring ITS systems. I would like to use a simple example to explain how this approach to ITS Transit standards is analogous to our day-to-day life. Imagine that when buying a computer—and you want to buy an upgrade, a printer, or anything else—that you must always buy that same brand at an exorbitant price. Of course, this is not the case because standards have been successfully implemented to allow interoperability. Similarly, transit standards have been developed by transit professionals like you at a national level to encourage competition and limit costs within our industry.

I am Jeffrey Spencer, ITS Team Leader in the Office of Research, Demonstration and Innovation of FTA within the USDOT and I would also like to welcome you to this ITS Transit standards training. FTA actively supports the development and implementation of transit standards and we hope that you find this series of online courses a useful tool in promoting standardization. We look forward to your participation and input.

Patrick Chan: Good day everybody. This is module eight of the ITS transit standards professional capacity building program. Module 8 is arterial management and transit signal priority: understanding user needs for signal control priority (SCP) based on NTCIP 1211 standard. This is part one of two and my name is Patrick Chan. Throughout this presentation, this activity slide will appear, indicating there is a multiple choice pop quiz following the slide.

You will use your computer mouse to select your answer. There is only one correct answer. Selecting the submit button will record your answer and the clear button will remove your answer if you wish to select another answer. You will receive instant feedback on your answer choice. I am your instructor today. I have been involved with development of ITS standards since the year 2000. I was the consultant that developed the current version, version 2, of NTCIP 1211, object definitions for signal control priority (SCP) which a majority of this module is based on. I have been involved with other ITS standards, including NTCIP 1201, object definitions for actuated signal controllers, the ITE AASHTO traffic management data dictionary and SIA 2735, dedicated short range communications message set dictionary, the data dictionary for connected vehicles.

I have 24 years of ITS experience, including four years as an ITS project manager for a public agency. So thank you for joining us today on this ITS standards course on understanding user needs for a transit signal priority in arterial management. We’ll first start off by reviewing the target audience for this course, so the participant can self-assess whether they should participate in the whole course.

Our target audience includes transit managers who make decisions and would like to better understand some of the potential benefits from implementing transit signal priority systems and other arterial management tools. Transit planning, operations, and maintenance staff who are the users of the system, who wish to better understand the capabilities of arterial management systems and strategies, such as transit signal priority. Traffic management operations staff who manage the arterial systems, who wish to better understand the needs of transit agencies. Transit and traffic systems acquisitions staff, which may include specification writers who are responsible for specifying and implementing transit signal priority. Transit electronic maintenance staff who maintain the equipment and who wish to understand the function of each component in the arterial management system. Integrated corridor management project and operations team who may need to understand institutional and operational issues for coordinating between different mobile agencies. Transit technology vendors, including device manufacturers, who are responsible for providing the hardware and software systems that support arterial management strategies. And transit ITS contractors and consultants, who wish to better understand the standards.

This slide represents the recommended prerequisites for this course. Modules 1, 2, and 3 are recommended for our participants. Modules 4 and 5 are recommended for project managers and project engineers. It is assumed for this course that all participants now have a general knowledge of transit functions, a knowledge of basic concepts of transit management standards. If the participant does not have this knowledge, it is recommended that you stop and take the appropriate prerequisite modules first, then return to take this module. This slide presents a graphical view of the recommended curriculum path for a project manager and it’s recommended that they first take introduction to ITS transit standards, transit management part 1 of 2, and TCIP, part 1 of 2.

Similarly, this slide presents a graphical view of the recommended curriculum path for a project engineer and it shows the same proposed prerequisites in the previous slides. This slide presents the learning objectives for this course. Upon completing this course, the participant should be able to identify the needs addressed by and the benefits of signal control priority on an arterial, identify the components that form an SCP system, describe the different SCP system architectures and the considerations in selecting an architecture for implementation, identify the interfaces in an SCP system and the ITS standards that address each of these interfaces, identify the user needs addressed by the standards, describe at a high level how to incorporate ITS standards into an SCP system procurement. We’re going to demonstrate learning objective number 6 by going to a fictitious case study, and 7, describe other arterial management tools and strategies.

So learning objective number 1, to describe the needs of transit agencies that may be addressed by signal control priority, following a discussion of the needs that an SCP system may address, we will review how signal control priority may help to improve transit operations. This diagram shows a typical scenario for a transit agency manager. Many fixed transit routes travel on signalized arterials. As the vehicle travels along its route, it often encounters signalized intersections which may introduce delays or unreliability to the transit schedule.

Congestion along these arterials can also introduce delays and unreliability. So a transit manager faces unreliable travel times and thus possibly poor schedule adherence due to variations in traffic congestions and service demand along signalized arterials. So what would a transit manager need or would like to see? Well, they would like to reduce unreliable travel times and/or poor schedule adherence to recurring or non-recurring congestion.

They would like to reduce the slow travel times on arterials due to recurring or non-recurring congestion. Reduce delays or unreliability due to traffic signals. And reduce the high energy usage by fleet vehicles or transit vehicles due to congestions or queues at intersections. In summary, the transit manager would like to see travel time be at least more reliable or more predictable. So one potential tool to help improve schedule adherence reliability is signal control priority.

Signal control priority is an operational strategy that provides preferential treatment or priority to facilitate the movement of fleet vehicles to signalized intersections. An SCP system improves the overall transportation system by providing preferential treatment for certain vehicles at signalized intersections without degrading the overall traffic network. It allows more efficient use of the surface street network by improving the throughput of travelers, such as high occupancy vehicles, like a transit vehicle, or goods, such as a loaded freight vehicle.

An SCP system can also be used to improve on-time performance and schedule adherence for transit vehicles. Without SCP, all vehicles are treated equally at signalized intersections without any consideration to the type of vehicle or to perceived value of the vehicle, such as the passengers or the number of passengers or the goods that it may be carrying. So how can traffic engineers or traffic signals provide preferential treatment?

We can do it by providing an earlier green signaling indication to clear queues in front of a preferred or fleet vehicle, so it’s not delayed reaching the intersection. Or it might allow the preferred fleet vehicle to move earlier in front of other vehicles. We can do it by extending an occurring green indication, so the fleet vehicle does not have to stop and wait for the current green indication to appear again. Or the traffic engineer can also activate a special phase for the preferred vehicle, such as a queue jump, which is similar to an earlier green indication, but exclusive to the fleet vehicle, so only the transit vehicle can go through the intersection. Or it may go through an intersection first, or perhaps it’s a protected turn that might be exclusive to the fleet vehicle. Now that I’ve been calling it SCP or signal control priority, transit managers or operators may be more familiar with calling it transit signal priority. Transit signal priority is a special subset of SCP. Other subsets of SCP include freight signal priority vehicles, for example, near a port to improve the flow of freight vehicles, generally loaded with goods, entering and exiting a port. Another subset of SCP is emergency vehicle priority which provides priority for emergency vehicles that are responding to a call or incident. Specific to transit fleet service, SCP improves transit vehicle efficiency. The reduction in travel time and more importantly, the reduction in travel time variability can result in increased attractiveness of transit to travelers by improved transit vehicle schedule adherence efficiency, resulting in improved reliability of service. It’s on time, it’s on schedule. Reduction in traffic signal delay, resulting in a decrease in travel times, or improved transit vehicle efficiency, which can result in schedule recovery time as the time to complete a route is shorter or more reliable, possibly leading to a savings of a transit vehicle along a route. As a note, sometimes you also may hear the words traffic signal preemption.

There is a difference between signal control versus signal preemption. In priority, a smooth transition can be set up to minimize overall disruption to traffic. Signal priority is generally preferred by the traffic signal engineers. Preemption, on the other hand, are abrupt transitions where safety is paramount. Signal preemption is preferred when a quick transition is needed for safety reasons, such as emergency vehicles responding to an incident, or a railroad crossing.

We’ve reached our first activity. So the question is, the problem is, how can SCP directly improve the attractiveness of transit to travelers? Your choices are, a) lower cost of transit, b) improve reliability of service, c) provide more frequent transit service, or d) improve passenger loads. So the correct answer is b) improve reliability of service.

SCP can be used to reduce traffic signal delay and improve transit vehicle schedule adherence, resulting in improved reliability of service. A) Lower cost of transit. SCP can improve transit efficiency, but does not directly impact the cost of transit to travelers. C) is incorrect, because with SCP, and through more efficient run cutting, a transit agency may be able to provide more frequent transit service, but it’s not a direct benefit. And d) is incorrect because SCP does not directly impact the number of passengers on a vehicle, but rather it impacts the vehicle’s on-time performance. So this slide reminds the participant of what we’ve discussed during this learning objective. The goal of an SCP system is to improve transportation operations by improving the overall efficiency of the street network for travelers and goods. SCP also can improve transit operations by improving transit vehicle schedule adherence and efficiency.

This slide reviews the key topics for the second learning objective. This learning objective describes components that together form an SCP system. So we’re going to review the centers, vehicles, and field equipment that might be part of an SCP system and describe the functions of a component called the priority request generator, priority request server, and coordinator. So the primary components of an SCP system are the priority request generator, priority request server, and coordinator.

Each component performs some specific function that is necessary for an SCP system to operate. They may be physical components, meaning they are a physical box located somewhere, such as on the fleet vehicle, in a roadside cabinet or at a management center, or it can be a logical component or a piece of software that performs that function. Maybe it’s part of the transit management software or a software component on a bus or software inside the traffic signal controller. The first component we’re going to review is the priority request generator, which is the source of a request for priority. This component, which again may be a logical device, a piece of software, takes all the inputs and if the right conditions are met, generates a priority request. These inputs might include the location of the vehicle or what direction the vehicle is approaching the intersection, what direction the vehicle wishes to exit an intersection. It might consider the location of a bus stop. Is it near side of the intersection or far side? Whether the vehicle is on schedule or not, or if the transit vehicle is full with passengers or not. Note that the transit manager may still request signal priority for the vehicle even if the transit vehicle is out of service so that the transit vehicle may get to the starting point of its next transit run. Based on these inputs, the PRG determines if it will actually generate a priority request. If it does, it may alert the traffic control system that it would like to receive priority, indicate when it would like to receive priority, and when it expects to leave the intersection. It sends its actual priority request to a priority request server and the priority request server provides that back the status of the priority request, whether it’s been granted, whether it’s queued up, or whether it’s been rejected. The next component is the priority request server. Again, it may be a physical device or it may be a piece of software. It prioritizes the different priority requests received. For example, it may receive requests from two different vehicles. However, even though one request may have a higher priority, it may not necessarily mean that the higher priority request will be serviced first.

The PRS may determine that the lower priority request will be serviced first because it will result in less overall travel delay for the intersection or for the overall network. So for example, the PRS may wish to extend the green indication for the lower priority request because by servicing the lower priority request, perhaps the overall delay may inconvenience the higher priority vehicle for just a few seconds, but if the higher priority request was serviced first, it may result in a delay of two or three minutes for the lower priority vehicle and other vehicles.

So in those higher priority requests, it may result in a couple of minutes delay, so we may decide, let’s service the lower priority request first because it will reduce the overall delay to the transportation system, which is a couple of seconds. So it’s up to the PRS to make that determination. Once the priority request server determines how to service the priority request, it sends a service request to the coordinator. In return, it receives back the status of the service request from the coordinator, then provides the status of each priority request back to the originating vehicle.

The last component is the coordinator, which is usually part of the traffic signal controller. Again, it may be a physical device or it could be a logical piece of software. So the coordinator receives a service request from a priority request server and implements the requested priority strategy, based on the programmed strategies. It sends back the status of the service request, back to the priority request server, and optionally, it may log priority requests received and sends the contents of the log back to the traffic management center.

So what we’ve reviewed are the primary components that are required in some form in a signal control priority system. Secondary components are components that may be part of the SCP system, depending on how the SCP system is designed and implemented. It may include the fleet management center, such as a transit management center, which may be the dispatch center. Its function in the SCP system may be to determine the location of fleet vehicles and determine the schedule here. It’s possibly from a computer aided dispatching or automated vehicle location system, a CAD/AVL. It may also maintain performance measures for the transit fleet. The PRG for example, the priority request generator, may be located in another transit management center. The fleet vehicle, such as a transit vehicle, might know its location, whether it’s on schedule or not. A transit vehicle might have some software responsible for managing the transit signal priority function, such as generating the priority request when needed.

The traffic management center may be responsible for controlling the traffic signal system. The priority request generator and/or the priority request server might be located in a traffic management center and it also may be used to maintain performance measures for the overall traffic network.

And finally, the management station is a logical entity, meanings it’s a software, for managing the priority request server at the coordinator. It may be used to change the parameters for handling priority requests, providing signal control priority and to download logs. It’s usually a piece of software at a traffic management center or maybe on a laptop.

We’ve now reached our second activity. So the full question is: which of the following components determines which priority requests to service? a) priority request generator, b) priority request server, c) coordinator, or d) transit vehicle. Again, which of the following components determines which priority request to service?

And the correct answer is b) priority request server. A priority request server receives the priority request from the priority request generators, processes the request, and determines whether or not and how to grant a priority based on the programmed strategies. It is not the priority request generator, which generates the priority request, nor is it the coordinator, which receives the service requests from the priority request server and implements the priority strategy. Nor is it d) the transit vehicle. The transit vehicle may generate the priority request, but it doesn’t determine which priority request to service.

This slide reminds the participant what we have discussed during this learning objective. So an SCP system consists of a priority request generator to generate the priority requests, priority request server to determine which priority request to service, and a coordinator to implement the service requests. An SCP system may also include a fleet management center, such as a transit management center, transit vehicle, fleet vehicle and a traffic management center.

Learning objective number 3 is to recognize that there may be different system architectures that may be used to implement signal control priority and to recognize some of the factors to consider when developing an architecture for your implementation. Over the next several slides, we will review some of the different system architectures for a signal control priority and review some of the technical institutional factors to consider when selecting an architecture to implement. The design or system architecture of the SCP system will be defined by several factors. They might include the physical location of the PRG, if the PRS is part of the signal controller or the traffic management center software, or it’s a separate physical entity, any intermediary entities between a priority request generator and a priority request server. By intermediary entities, I mean something that’s like a pass-through component. And the communications infrastructure that’s available. But first, since this module’s really about ITS standards, let’s review the standards that supports an SCP system.

So why standards? Standards can help to reduce the cost of future procurements in transit computer based systems while providing competition, and to facilitate a greater degree of automation and integration at those systems. These benefits are similar to what most standards provide. ITS standards supports interoperability, meaning the ability to exchange information, no matter what components you’re using. Minimize future integration costs, facilitate regional integration and it helps make procurement and testing easier. If you’re looking for more information about standards, I will refer you back to module number 1, which is introduction to ITS transit standards.

The first family of standards that we’re going to review is TCIP, our transit communications interface profile, published by APTA, it defines the standardized interfaces for the exchange of information, data, among transit business systems, subsystems, components, and devices. TCIP is intended to exchange management information for internal agency users only. If you want more information about TCIP, I’ll refer you back to module number 3, transit communications interface profiles (TCIP) part 1 of 2.

The second family of standards is NTCIP, which is the abbr for National Transportation Communications for ITS Protocols. Think of the standards, the NTCIP standards, like the English language. There are rules for communicating, which is defined by English grammar, while the dictionary provides the vocabulary. So NTCIP contains standards that provide rules for communicating, called protocols, and provides a vocabulary data dictionary which we sometimes call objects, which are necessary to control or to communicate with traffic field equipment.

One thing NTCIP standards directly address signal control priority for signalized intersections and that’s NTCIP 1211. NTCIP 1211 is information content standard, data dictionary, that provides the vocabulary between the coordinator, the priority request server, and the priority request generator to support and provide signal control priority.

So now we turn back to the system architecture. In the context of a transit signal priority, a system architecture describes the framework of the proposed signal control priority system, including the physical components that make up the SCP system and the functions that each component performs and what information gets exchanged between each of those components. TCIP version 3 and above defines five system architectures. These five system architectures do not represent all the possible architectures, but rather five typical architectures addressed by the standard. NTCIP 1211 version 2 defines the same five system architectures plus one additional system architecture. Again, these five, six architectures only represent some of the possible physical configurations of an SCP system. So let’s review some of the possible physical architectures that are addressed by the standards.

For physical architecture example number one, the PRG, the priority request generator is located on the fleet transit vehicle. The priority request is then sent to the traffic management center via the fleet transit management center. Since the fleet management center and the traffic management center are just intermediaries, they and the transit vehicle are treated as a last goal PRG. The priority request is then sent to the priority request server, which may be a separate component in the signal controller or already part of the traffic signal controller.

The service request is then sent to the coordinator. Notice that the status of the requests are sent in the opposite direction from the coordinator to the priority request server and then from the priority request server to the priority request generator. There is also an interface between the management station and the traffic management center to configure a monitor, the coordinator, and the priority request server. Note for our architectural diagrams that we’re going to review, dotted lines represent an interface that is addressed by TCIP. Solid lines represent interface that it addressed by the NTCIP standard, and hybrid lines, dots and dashes, represent an interface that might be addressed by other potential standards. So for example, there’s an ITE AASHTO traffic management data dictionary which is a center-to-center standard, which may address the interface between the fleet management center and the traffic management center.

Some of the challenges of this particular physical architecture includes that it requires a priority request generator and the intelligent software in each transit vehicle. So each transit vehicle needs to determine if it needs signal priority, is it on schedule, where it is, and when it needs priority. This requires an interface communications between the transit management center and traffic management center also, and between the vehicle and the transit management center. Some of the advantages of this physical architecture is that it may be feasible if the transit vehicle already has communications with the transit management center and easily supports data collection for performance measures in centers.

Physical architecture example number 2 is a slight variation of the first example, in that the PRG is physically located in the fleet management center, however, it treats the traffic management center as part of PRG because its traffic management center only acts as an intermediary.

As in the physical architecture number 1, the priority request is then sent to the priority request server, which may be a separate component in the controller or may be already part of the traffic signal controller. The service request is then sent to the coordinator. Notice that the status of the request, again, are sent in the opposite direction from the coordinator to the priority request server and from the priority request server back to the PRG. There’s also interface between a management station and the traffic management center to configure and monitor the coordinator and the priority request server.

Some of the downsides of this physical architecture is it requires an interface between the transit management center and traffic management center. The transit management center has the intelligence to determine where the transit vehicles are, recognize whether the transit vehicle is on schedule or not and can determine if a transit vehicle requires priority. Some of the advantages of this physical architecture is that it may be feasible, if the transit vehicle already has data communications with the transit management center, such as AVL, may be more cost effective than the first architecture because not all the transit vehicles have to be equipped with a priority request generator or the software to determine if it needs a priority request. It’s done at the single transit management center. And again, the management centers can easily support data collection for performance measures. Physical architecture number 3 is another variation of the earlier physical architecture examples in that the PRG is logically or physically located in traffic management center, using information that is provided by the transit management center. As in the previous architectures, the priority request is sent to the priority request server, which may be a separate component in the control or directly part of the traffic signal controller. The service request is then sent to the coordinator. Again, notice that the status of the request is sent in the opposite direction from the coordinator to the priority request server and then from the priority request server back to the priority request generator. There’s also interface between the management station and the TMC to configure and monitor the coordinator and the priority request server. Some of the downsides of this physical architecture, it requires an interface between the transit assets and the traffic management center, which isn’t shown. So there’s some kind of interface, communications between the transit vehicle to the traffic management center or maybe from the transit management center to the traffic management center, or perhaps to sensors in the field. Some of the advantages of this physical architecture, easily supports data collection for performance measures and institutionally, it may be more appealing to the traffic ATC, because it maintains control. It determines when the priority request is needed and generates that priority request.

Physical architecture example number 4 is a direct link between the PRG in the transit vehicle and the priority request server which is in the traffic signal cabinet. As with previous architectures, the priority request is sent to the priority request server, which may be a separate component of the controller or part of the controller. The service request is then sent to the coordinator. Again, the status of the requests are sent in the opposite direction from the coordinator to the PRS and then from the PRS to the PRG. There may be an interface between the management station and the traffic management center to coordinate and monitor the coordinator and the priority request server.

Some of the downsides for this architecture is that the performance measures might have to be collected by the field equipment or the transit vehicle, plus it requires a priority request generator in each transit vehicle and a priority request server at each signalized intersection.

Some of the advantages, no other communications between centers are required and there’s no communications time required between the traffic management center and the signal controller, or the priority request server—they can operate independently.

The fifth example, the priority request generator is located in the traffic signal cabinet. There is also a direct link between either the transit vehicle or the transit management center and the priority request generator. As with previous architectures, the priority request is then sent to the priority request server, which may be a separate component and control or priority request signal controller. The service request is then sent to the coordinator. Again, the status of the request is sent back in the opposite direction from the coordinator to the priority request server, back to the priority request generator. There’s also interface between the management station in the TMC to configure and monitor the coordinator and the priority request server.

Some of the disadvantages of this architecture, requires communications between the transit agency, either in the field, in the fleet vehicle, or the transit management center and each priority request generator in the field. Some of the advantages is, no communications between the centers are required. All the equipment is contained within the traffic signal cabinet except maybe the communications equipment in the transit vehicle or communications equipment in the transit management center or the traffic management center.

The last physical architecture, number 6, that we’re going to review is that there is direct communications between the transit vehicle and the signal controller cabinet. All the functions on the PRG, the priority request server and the coordinator are within the traffic signal controller. Thus there are no interfaces between these components. However, there may be interface between the management station and traffic management center to configure and monitor the coordinator and the priority request server. So on the downside, requires communications equipment in each transit vehicle and each traffic signal controller, but some of the advantages, there’s no communication between centers required. All equipment is contained within the traffic signal cabinet, except the communications equipment in the transit vehicle and maybe the traffic management center. Institutionally, this may be more appealing to the traffic agency because it maintains control, and no back call communications infrastructure may be required between the traffic management center and the traffic signal cabinet.

So now that we’ve reviewed the architectures addressed by the standards, this slide discusses or reviews some of the factors to be considered when selecting an SCP system architecture to be implemented. Some of the technical factors include the capabilities of the traffic signal controller and the traffic signal system, the capabilities of the transit vehicle, or the fleet vehicle and the communication structures—excuse me— infrastructure that may be in place or that can be easily added. If the fleet vehicle is equipped with AVL, vehicle location, that’s a huge factor and huge capability. The communications capability and cost are another. The communication infrastructure is in place that saves a lot on cost of implementing. Institutionally, does the SCP system cross institutional boundaries? Meaning, that’s possible that it’s the same agency or that control of the transit vehicle and operate the transit vehicle is in the traffic signal system. Are priority requests initiated at the vehicle or at the center level? Also, we create quantitative measures when priority maybe request is critical. So for example, what are the conditions for granting priority? Is it to speed up transit vehicles, in which case, all the vehicles might be granted priority, or is it to make transit service more reliable?

So priority is only granted to vehicles that are behind schedule, whether it’s in service or not. What are the benefits to the traffic agency? Well, they may include reduced traffic, as there’s less people driving, reduced congestion as we allow transit vehicles additional time to pull out, safety for light rail vehicles, to clear commercial vehicles, to travel port vehicle performance from a port, is another example. Priority for emergency vehicles, it can save lives and clear incidents faster and when it clears incidents faster, it can reduce congestion and delays.

So you see, we’ve arrived at the next activity. The question is, what is not a significant factor in selecting an architecture for an SCP system? Your possible answer choices are a) communications infrastructure, b) current capabilities on the transit vehicle, c) current capabilities of the transit vehicle driver or d) current capabilities of the traffic signal controller.

So the correct answer is c) current capabilities of the transit vehicle driver. All the functions of an SCP system can be automated without intervention or input from the driver. Not that the driver’s not important, but for operating an SCP system, everything can be automated so we don’t need driver intervention. Communications infrastructure can play a significant role in selecting the system architecture. The current capabilities of the transit vehicle, whether it has the software, whether it has AVL, can have an impact on the system architecture selected. And the current capabilities of the traffic signal controller is important. Not all signal controllers may be capable of providing signal priority.

So to summarize what we’ve learned during this learning objective, the standards describe several system architectures, which identify relationships between the different components of an SCP system. Selection of a system architecture for yourself—for your implementation—involves the evaluation of the goals and objectives for the signal control priority system, capabilities of the signal controllers, and the fleet vehicles, the communications infrastructure that’s in place, and some institutional factors.

Learning objective number 4 is to identify the interfaces between the components of the SCP system. Each component of an SCP system performs a specific function in support of the SCP. The standards do not define how those functions are performed; rather they define the interfaces or how information exchange between those components so each component can perform its function in support of signal control priority. Although we’ve introduced ITS standards, we’ll dive a little bit more into detail about how those standards can support signal control priority. Again, the ITS standards primarily focuses on interfaces between the components, what information needs to be shared to provide a feature and how that information is shared. We call the benefits of these standards as supports interoperability, lowers integration costs, and makes procurement and testing much easier.

The interfaces addressed by the TCIP standards includes those which we have between a fleet vehicle or equipment installed in a fleet vehicle, such as a CAD/AVL system, and transportation management centers, including both transit management centers and traffic management centers. So those interfaces include between a public transit vehicle data manager and a public transit vehicle priority manager. So these are pieces of software, logical software, that are located on the public transit vehicles. One is in charge of data management, where am I, am I on schedule? And one is responsible for signal priority functions, based on the information, let me generate a signal priority request.

Between the PTV priority manager and the CAD system, that’s another interface that’s addressed by TCIP. And also the interface between the data manager on the priority transit vehicle—excuse me—the public transit vehicle and the roadside priority request generator. Interfaces addressed by the NTCIP standards include the interfaces between the traffic control equipment out in the field and the transportation management center, and also the interface between the traffic control equipment and the fleet vehicles.

So we’re going to focus more on NTCIP 1211 for this module. If you want to learn more about the TCIP standard, again, I refer you back to module number 3, TCIP part 1 of 2. So the following are the interfaces addressed by NTCIP 1211. Between the management station, using the traffic management center, and a priority request server; between a management station and the coordinator; interface between a priority request generator and a priority request server; and interface between a priority request server and the coordinator.

We’ve reached another activity. So, which is not a benefit of using ITS standards? Your answer choices are a) supports interoperability, b) eliminates institutional issues, c) lowers integration costs and d) makes procurement easier. Again, which is not a benefit of using ITS standards?

So the correct answer is b) eliminates institutional issues. ITS standards can help with resolving and mitigating technical issues but not institutional issues. ITS standards do support interoperability which helps users from being limited to a single vendor’s products. It lowers integration costs by providing a common language between systems that are being integrated. And makes procurement easier as well as testing by defining the language that should be used by ITS devices for sharing information among the devices. So just to summarize what we learned in learning objective number 4, TCIP standards address interfaces between the transportation management centers and fleet vehicles, and between logical entities within the fleet vehicles, such as the CAD/AVL system on a transit vehicle. Meanwhile, NTCIP 1211 standard addresses the interfaces between specific components of an SCP system, such as the priority request server, the priority request generator, the coordinator, and the management station.

Learning objective number 5 is to identify the user needs addressed by the standards. It identifies the ways in which the system is likely to be used. So the architectural needs are dependent on the system architecture used to implement the SCP system. It defines what the system architecture needs to support so the SCP system can perform its function. First, the use of ITS standards are not mandatory if they are integral entities. That means, if two of the components, say the priority request server and coordinator, are part of the same physical device and the same software, the interface is implementation specific and is not covered by any of the standards, such as NTCIP 1211. They don’t apply. What you do internally within the same physical device is up to you—up to the vendor. Second, the standard allows two components to exchange information in real time, or near real time. In this environment, the entity receiving requests must respond immediately.

The standards also support multiple instances of entity. So for example, a priority request server can support requests from multiple priority request generators at the same time. It’s not limited to say, "Hey, I’m looking at one priority request generator. I communicate with it. I’m going to ignore other priority requests that I may receive." Provide compressed data. Some environments may have limited data capacity, for example, because of low bandwidth communication channels being used. The standards support compressing data so that the throughput of the information can be increased. The standard will specify how this compression will be done. NTCIP 1211 user needs or features are organized by the interface that they address, between a management station and a PRS, between a management station to the coordinator, between a priority request generator to priority request server, and between a priority request server and coordinator. These interfaces again apply only to components that are not physically part of the same entity. It only applies if each component is physically separate.

So let’s review some of the features that are supported by the standard between a management station and a priority request server. Manage the priority request server, describes the features necessary to configure the priority request server. Determine PRS identity, which is basic information about the priority request server, such as, what type is it, what technology, who the manufacturer is, what model number, and what version of the software is on the PRS? Determine PRS configuration, which means information about the version of the configuration data of the PRS. Think of it as a check sum. So we know if the configuration has changed, the check sum has changed, so it just verifies, do I have the right version in the database? Configure reservice period allows an operator to define a period of time to elapse before another priority request is serviced. This prevents the priority request server from constantly servicing priority requests, which might result from bunching, for example. Configure a time to live period allows an operator to manage the priority request server by not servicing priority requests that are sent by a priority request generator too early. So for example, if the time to live period is for two minutes, if you make a request for priority five minutes from now, the priority request server is going to say, "Nope, too early. Come back later when you’re closer." So it will check that requests aren’t sent too early, because the longer the time for the request, the more unreliable the request is. PRS clock synchronization allows an operator to check the date and time on the priority request server, so that we make sure that everyone has the same date and time. If one of the clocks is off by two minutes, the request is going to come in two minutes earlier or two minutes later. Determine priority request criteria allows an operator to check the criteria the PRS is using to handle priority requests. So what is it that we’re looking at, that the priority request server is using to determine which priority requests to service first? Monitor the PRS allows an operator to determine what priority strategies are being provided to handle priority requests. For example, the priority strategy A may be to extend the green signal for that transit vehicle, while priority strategy B may be to allow the green signal to come up earlier. And finally, retrieve log data allows an operator at a traffic management center, for example, to retrieve the log data from the priority request server.

Let’s review the features or user needs supported between a management station and the coordinator. Configure priority strategies allows an operator to edit the priority strategies on a controller, while determine priority strategies allows the operator to determine what priority strategies have been programmed into the signal controller. So how is it going to handle or provide priority? Monitor the coordinator allows an operator to determine what priority set is currently being implemented, to service a priority request, while retrieve log data from the CO allows an operator to retrieve the log data that’s on the coordinator. Reviewing the features support between the priority request generator and the priority request server. A priority request, it includes the vehicle type, vehicle class, the estimated time when the vehicle will arrive at the intersection and the estimated time when the vehicle will depart the intersection. Vehicle type, for example, a vehicle type is a transit vehicle, a freight vehicle, an emergency vehicle, while the vehicle class could be the type of transit vehicle. Is it LRT, light rail transit? Is it a bus rapid transit vehicle? Is it an express bus, a local bus? Depending on what type of transit service you’re providing, you may have different types of priority, whether it’s a higher priority or a lower priority.

Finally, let’s review the features supported by the standards for the interface between a priority request server and a coordinator. The first feature is to exchange service requests between the priority request server and the coordinator. Once the priority request server selects a priority strategy, the priority request server then needs to send the selected priority strategy to the CO for processing and servicing. For exchange service request status, this feature allows the PRS to verify if a priority request has been received by the CO and if the CO has provided the requested signal priority.

So we’ve reached another activity. Which of the following user needs are not supported by NTCIP 1211 version 2? So which feature is not supported by the standard? Need to know the distance of the transit vehicle from the intersection? Need to configure priority strategies? Need to exchange priority requests? And need to exchange service requests? Which of the following are not supported by NTCIP 1211?

The correct answer is actually a) need to know the distance of the transit vehicle from the intersection. So this need is actually not addressed by NTCIP 1211. It may be addressed by TCIP but not 1211. All NTCIP 1211 is interested in as part of its priority request is, when the intersection—excuse me—when the transit vehicle may arrive at the intersection and when the transit vehicle is projected to leave the intersection. That’s all it cares about, because the transit vehicle may be stopped right at the intersection because the bus stop or the tram stop is right before the intersection. So it might be stopped there, so it might be five feet, but the intersection, the signal controller doesn’t really care where it is. It’s only interested in when do you think you want to go through the intersection? That’s why this user need is not addressed by NTCIP 1211. We’re interested in when it’s estimated to arrive at the intersection and when it’s expected to leave the intersection. Where it is, is not important. It’s not exchanged by the standard. So need to configure priority strategies is addressed as part of the interface between a management station and a coordinator. Need to exchange priority requests is addressed as part of the interface between the priority request generator and the priority request server. And need to exchange service requests is addressed as part of the interface between a priority request server and the coordinator.

We’ve actually reached a second poll question. So the poll activity is, what do the ITS standards define? Your answer choices are, the conditions that must be satisfied for the priority request generator to generate a priority request. The process that the priority request server prioritizes priority requests. How the coordinator implements the priority strategy, or d) the interfaces between the components of an SCP system?

The correct answer is d) the interfaces between the components of an SCP system. So that’s what the standard defines. It defines the interfaces, the information that’s exchanged between components. The standards do not define how the PRG determines when to generate a priority request. That’s specific to your implementation, whatever factors you want to use, what are important to you. That’s not defined by the standard. The process the PRS prioritizes priority requests, that’s also implementation-specific. That’s determined by the traffic agency and they’ll program that into the traffic signal controller. And how the CO implements the priority strategy, that’s also implementation-specific. So the standards, in summary, address the interfaces, how information is exchanged and what information is exchanged between the different components. It does not specify how each device performs its functions, each component performs its functions.

So in summary, what we’ve learned in learning objective number 5, our SCP architecture needs vary, depending on the physical architecture to be implemented and the user needs are organized by the interface that they address.

In learning objective number 6, we provide a fictitious case study to show how ITS standards can be used to help agencies develop signal control priorities procurement specification. So again, this is fictitious. The current situation is, the Alphaville transit agency has been experiencing increasing travel times for one of its routes along a heavily traveled corridor. A study indicated that increased travel times were due to recurring and non-recurring congestion. The transit agency determined that transit signal priority will help improve travel time reliability. The transit vehicles are already equipped with an AVL system and there exists radio communications between the transit vehicles and the dispatch center. Transit stops are a combination of the far-side and near-side stops. The transit agency discusses with the traffic agency, who is planning to upgrade the signal controllers along that corridor anyway. The traffic agency is concerned about maintaining flow on the arterial but is willing to provide signal priority. The transit agency and traffic agency are both on the city’s fiber optic network, and thus the traffic agency already has communication links with each of its signal controllers along the corridor. The transit and traffic agencies discuss this situation and agree on the following goals and objectives for the transit signal priority. The primary goal is to increase travel time reliability for the transit service along that corridor. A secondary goal is to decrease the travel times. While performance measures are desired to verify the benefits because the transit agency has identified other corridors that may benefit from the transit signal priority, so the transit agency wants to document the performance measures, do performance measures, so they can determine, are there benefits? What are the benefits from implementing transit signal priority?

So the two agencies develop an agreement and agree on the conditions for providing a priority. Priority will be considered if a vehicle is more than two minutes behind schedule. It does not have to be a revenue run, maybe it could be a transit vehicle, trying to get to its location so it can start its transit route. Some of the discussions may have the geometric conditions to allow for a queue jump.

The capabilities of the traffic agency. The traffic agency has upgraded several but not all of the traffic controllers, signal controllers along the arterial. But they’ve agreed to adjust their procurement specifications for new signal controls to support transit signal priority. Not all signal controllers come with the capability to support priority. The new signal controllers will include the functions of the coordinator. For signalized intersections not scheduled to be replaced with new traffic signal controllers, a device may be installed at the signal controller cabinet to support the priority, transit signal priority.

Cost analysis. Based on the cost analysis, it was determined that the priority request generator should be located in the transit dispatch center. Note that because the communications infrastructure already exists between the transit vehicles and the dispatch center, the location of the priority request generator at the dispatch center reduces the cost, instead of having a priority request generator for each transit vehicle. If the communications infrastructure was not in place, it may be more effective for the priority request generator to be located elsewhere, such as on the transit vehicle or in the field at each intersection. However, since the transit agency is also considering expanding the system to other corridors, the cost to install a priority request generator at each signalized intersection, or each transit vehicle, could become very expensive. But the other reason for the priority request generator to be at the transit dispatch center, the system constantly knows the location of each transit vehicle because of the AVL system, and the dispatch center will also know the schedule for each transit vehicle and can maintain the performance measures. So for that reason, it was determined that the PRG should be located in the transit management center.

Based on the cost analysis, the PRS is determined to be located in the traffic management center. The PRS will know the operating status of the traffic signal controllers because all the traffic signal controllers are interconnected back with the traffic management center. The dispatch center will simply send a priority request to the PRS in the traffic management center. Based on that, the priority request server will consider all the priority requests along the corridor and select the appropriate strategy or strategies. The TMC will then forward that strategy, or actually, the priority request server will forward that strategy to the coordinator. It’s low cost because it takes advantage of the existing communications infrastructure and most of the processing is performed at the centers, minimizing costs for equipment on individual transit vehicles or at intersections. Again, this is because the communications infrastructures already exist between the signal controllers and the traffic management center.

Some of the user needs, some user needs may be mandatory to conform to the standard that means the user need must be supported to conform to the standard. NTCIP 1211 says these certain user needs are required. We’ll discuss this more in part 2 of this module, but reviewing some of the user needs supported by the standards, the specification writers may determine that for the interface between the management station and traffic management center and the PRS, the proposed system needs to be able to manage the priority request server, determine priority request criteria and monitor the priority request server. However, it is not necessary to retrieve the log data from the priority request server, so the specification writer might not include this particular user need in its specification. Also note that the specification writer may determine that there are additional user needs but their interface is not supported by the standard, but the standards provide a list of what user needs the agency may wish to consider for the other procurements.

This list contains the user needs supported by the standards for the interface between a management station and a coordinator. Again, we should look at all these needs and determine if they may be applicable for this specific implementation. So in our case study, the specification writer determined that all these user needs are desired for the procurement since the management station is using the traffic management center, these needs should be selected by the traffic agency. This list contains the user needs supported by the standards for the interface between the priority request generator and the priority request server, and between a priority request server and a coordinator. There are only two user needs for each interface, to forward the request and to send back the status of the request, so both are generally desired for the project. So for our case study we’re going to select these user needs.

Other changes that might result from the single control priority project. Based on the information, the transit agency may consider moving some of the bust stops to the far side intersection where priority may be provided. Partially because the estimated time of arrival and estimated time of departure could vary a lot, based on the number of passengers boarding and alighting at a bus stop. With respect particularly, since for bus stops, transit stops there before the intersection. So there’s less lead time for traffic signals to make the adjustments. So decide, let’s move some of these transit stops to the far side of the intersection, to increase the reliability. From a traffic manager’s point of view, a green extension is usually less disruptive than early greens, because we can maintain coordination along the arterial, the preference was to do green extensions. There are constraints to signal timing adjustments at certain intersections or some environments. Based on the changes, the transit agency tuned the transit schedules so more accurate information can be provided to the public.

So this slide reminds the participant of what we discussed during this particular learning objective. ITS standards can be used to identify the scope of SCP systems and to determine the features of an SCP system.

We’re now going to jump into learning objective number 7, which is, describe other arterial management tools and strategies.

The first is integrated corridor management. Integrated corridor management of freeway, arterial, transit, and parking systems within corridors allows the different partners, various institutional partner agencies to manage the transportation corridor as a system, rather than the more traditional approach of managing each as an individual asset. So we take a holistic view of the transportation corridor. We manage the corridor as an integrated asset to improve travel time reliability and predictability to help manage congestion, empower travelers through better information and more choices. In an integrated corridor, because of more proactive multimodal management of infrastructure, assets and institutional partners, travelers should receive information that encompasses the entire transportation network. Based on that information, travelers could dynamically shift to alternative transportation options, even during the trip, in response to changing traffic conditions. For example, while driving in a future integrated corridor, a traveler could be informed in advance of congestion on their route and be informed of alternative transportation options, such as a nearby transit facility’s location, when the transit vehicle is going to arrive at the station, and at the ultimate destination, and if there’s parking availability.

Other standards, other than a signal control priority status, may include the TCIP standards for managing transit assets, other NTCIP standards for monitoring traffic devices and perhaps ITE AASHTO traffic management data dictionary for center-to-center communications. And here we have a link for more information about integrated corridor management.

Transit traveler information is another tool that can be used to improve transit service along arterials. It provides travelers with information about alternatives, for example, if one mode has experienced delays, it can help travelers understand what their choices are and reroute to better alternatives, possibly reducing commuting costs. Managing traveler expectations. When travelers experience less delays, information about the delay helps travelers manage their expectations. There’s less anxiety because their arrival time is known, increased rider satisfaction, and improved perception of transit wait times. Increases sense of system reliability. With our traveler information, any deviation from predetermined schedules is noticed. However, with traveler information, it can become an understandable event. And reducing waiting time, the traveler knows the estimated time of arrival of the tram service. It reduces the total travel time, waiting time, for example, inclement weather. I’m about to go home. I take a look. When is my transit vehicle going to arrive? So if it’s going to arrive five minutes later, I might wait the extra five minutes in my office before heading out to the transit stop. Performance measures, the use of real time technology which many systems use makes it easier for riders to know when the next bus or train will arrive. So that’s performance management.

Other standards may be required, not necessarily ITS standards. For example, the general transit feed spec, or GTFS, is not necessarily ITS standards, it’s a specification. But these are standards that might be used to share transit traveler information along an arterial corridor. Other standards include NTCIP 1203, which is a standard for controlling dynamic message signs, and TMDD, which is center-to-center communications for sharing information between transit centers and other transit centers, or transit centers and traffic management centers.

So we’ve reached our final activity. Which of the following is not a characteristic of an integrated corridor management program? Your answer choices are a) sharing information between agencies, coordinating between different modes of transportation, providing traveler information or d) improving maintenance of transit vehicles.

The correct answer is d) improving maintenance of transit vehicles. That’s the responsibility of the operating agency. But the integrated corridor management can help optimize the entire transportation network by leveraging unused capacity along the transportation corridor. This can be accomplished by sharing information between the transportation agencies. Coordinating between the different transportation modes is a key component of the integrated corridor management program. And providing traveler information that allows travelers to make better informed decisions that can impact the level of congestion on the transportation network.

So in summary, other arterial management strategies include integrated corridor management, where regional agencies collaborate to manage a corridor as a system, rather than as separate assets, and transit traveler information, including real time traveler information, such as bus arrival times and incident notifications.

So in summary, for the course, what have we learned? Well, a signal control priority is an operational strategy to facilitate the movement of fleet vehicles through signalized intersections. A signal control priority system consists of a priority request generator, a priority request server, and a controller. Some of the technical factors for selecting system architecture will include the signal system and fleet vehicle capabilities and your communications infrastructure that may be in place. ITS standards can be used to design, procure, and operate a signal control priority system. And integrated corridor management strategies and transit traveler information can improve service along a transportation corridor.

This is a listing of some resources in case you’re interested in more information about more of the standards, NTCIP 1202, NTCIP 1211, the transit communications interface profile standards—TCIP—or the transit signal priority in general.

There’s also some additional resources in the student supplement guide that is available for downloading. So this is part 1 of 2. The next course in this two part course on arterial management and transit signal priorities, module 9, specifies requirements for signal control priority based on NTCIP 1211. This part 2 builds on the content of module 8, this particular module. It provides more detailed information on how to identify and use applicable ITS standards to procure and operate a signal control priority system following a systems engineering process. Focuses on tools that are provided with NTCIP 1211 standard, specifically a code of call requirements list and something called the requirements traceability matrix. So I’d like to thank you for completing this module. There is a link here to open the feedback form and if not, there’s a website for providing us with feedback. We would appreciate any feedback that you may have on this module. So thank you very much for joining us. Hope this was helpful, and enjoy your day.

#### End of Module_8_Arterial_ Management_and_Transit_Signal_Priority_Part_1.wmv ####