(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.)
Ken Leonard: ITS Standards can make your life easier. Your procurements will go more smoothly and you’ll encourage competition, but only 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 acquiring and testing standards-based ITS systems.
I am Ken Leonard, director of the ITS Joint Program Office for USDOT and I want to welcome you to our newly redesigned ITS standards training program of which this module is a part. We are 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 yourself.
This combined approach allows interested professionals to schedule training at your convenience, without the need to travel. After you complete this training, we hope 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 Standards training is one of the first offerings of our updated Professional Capacity Training Program. Through the PCB program, we prepare professionals to adopt proven and emerging ITS technologies that will make surface transportation safer, smarter, and greener, which improves livability for us all. You can find information on additional modules and training programs on our website at ITS PCB Home.
Please help us make even more 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.
Patrick Chan: Hello. So this is Module 24: Transit Signal Priority in Connected Vehicle Environments. This is actually the fourth of a series of modules on transit signal priority as part of the transit standards theories. I will be your instructor. My name is Patrick Chan. I’ve been involved in development of ITS standards since the year 2000. I’m a member of SAE technical committees that develop connected vehicle standards, including SAE J2735, which is the data dictionary for connected vehicles. I’m also the editor of version two of NTCIP 1211, Object Definitions for Signal Control Priority or SCP which supports Transit Signal Priority. I have over 29 years of ITS experience, including four years as an ITS project manager with a public agency.
So today’s learning objectors are fourfold. By the end of this module you should be able to: describe and identify—describe what transit signal priority is and how it can be provided in a connected vehicle environment; identify the applicable transit signal priority standards in a connected vehicle environment; discuss what agencies need to do to prepare for a connected vehicle transit signal priority implementation; and finally, we’re going to review some case studies and the lessons learned from other TSP implementations in a connected vehicle environment. So to start off with the first learning objective, which is to describe how transit signal priority can be provided in a connected vehicle environment.
Over the next couple of slides, we’re going to first review what is a connected vehicle environment. Then we’ll describe how transit signal priority is currently implemented and the role of NTCIP 1211 and ITS standard. We’ll identify what information is exchanged for transit signal priority in a connected vehicle environment. And finally, we’ll describe what the potential advantages are of a connected vehicle implementation as compared to other traditional transit signal priority implementations.
We’ll first start off by reviewing the major transportation challenges that transportation agencies face today and why we think a connected vehicle environment will be helpful. First is safety. In 2017, over 37,000 motor vehicle deaths were recorded as part of over 6.4 million crashes on U.S. roadways. It is also estimated that 8.8 billion hours was wasted in 2017 on the nation’s highways, wasted while you are waiting in congestion, which has an estimated economic productivity cost of $166 billion dollars. That same congestion had an impact on the environment that resulted in approximately 3.3 billion gallons of wasted fuel. So, USDOT believes that the deployment of a connected vehicle environment can help transportation agencies address these challenges. For example, USDOT believes that the appointment of a connected vehicle environment could have eliminated 80 percent of the crashes that occurred in 2017.
But what exactly is the connected vehicle environment? In broad terms, the connected vehicle environment consists of vehicles, individuals such as pedestrians or bicyclists, also known as vulnerable road users equipped with smart devices, an infrastructure that can wirelessly communicate amongst each other to provide valuable services that can address the transportation challenges presented in the previous slide. These services, enabled by software applications, could help reduce crashes, improve mobility, and improve the environment.
This connectivity is provided to arrange wireless technologies, but primarily in two categories. One, short-range communications, which provide an open network over hundreds of meters, so vehicles approaching each other can communicate and inform each other of their presence and movement. That’s known as V2V or vehicle-to-vehicle communications. These vehicles may also exchange information with the infrastructure, also known as known as vehicle-to-infrastructure or V2I. And individual travelers through smart devices, also known as V2P or vehicle-to-pedestrians. Second, remote communications, which allow these connected vehicles and travelers to access centralized services such as fleet management capabilities, regional traffic management, and personalized trip information, etc. Collectively, this connectivity is referred to as vehicle-to-everything or V2X.
So what data might be exchanged among the connected vehicle components to address the transportation challenges that we’ve previously mentioned? Well for connected vehicles via the on-board unit device, they can share their current position and sensor data with other vehicles, travelers, and infrastructure. They can also in turn receive data from the infrastructure that can reduce the likelihood of incidents and improve mobility, for example, reduce delays. Connected individuals, also known as vulnerable road users, can also share their current position of other vehicles and infrastructure and in turn receive information about their current surroundings. For example, where are the crosswalks and do they have the walk signal right now? And finally, the connected infrastructure sometimes through a roadside unit, can provide geographic and traffic information about the section and the roadway including signal timing data. They, in turn, can receive movement information from nearby vehicles and travelers to the on-board units or mobile units; for example, that there’s a vehicle approaching the signalized intersection or there’s a vulnerable road user in a crosswalk.
How is this data useful in addressing safety, mobility, and environmental challenges? The answer is by developing applications of software that can use the data to make changes to the traffic strategies based on the presence and location of travelers, such as adjusting traffic signal timing or random metering strategies. Warn travelers, such as vulnerable road users to avoid violating right away in the signalized intersections so you don’t have the crosswalk right now, signal right now, for example, so you should wait. You can also provide advisories to travelers such as a transit vehicle driver to improve the flow to a signalized intersection. Oh, the signal is going to turn green in about three seconds.
So, this module focuses on applications that support transit signal priority. Let’s start first by reviewing what is transit signal priority. Unlike signal preemption, signal priority is a strategy to provide preferential treatment of a vehicle or a traveler over other vehicles and travelers without disrupting traffic signal coordination. An effective priority strategy minimizes the negative impact on other vehicles and the traffic network and, in fact, actually may result in positive impacts. Transit signal priority can prioritize transit vehicles, increasing the throughput of travelers through the street network, especially when the transit vehicle has multiple riders.
Consider this: without priority, all vehicles are treated equally at the signalized intersection regardless of their economic value. The signal priority is a strategy that places a higher value on transit vehicles over other vehicles, such as a single passenger occupied vehicle. Similarly, emergency vehicle priority places a higher value on emergency vehicles responding to incidents while freight signal priority places a higher value on freight vehicles that may be fully loaded. But again, the focus of this module is on transit signal priority. More importantly, transit signal priority can be used to improve the reliability of transit service, meaning the bus, the transit vehicles don’t arrive too early or too late, which is important to travelers and increases the attractiveness of the transit. So hey, I know the vehicle will arrive when I expect it to. Transit signal priority applications are considered a mobility and an environmental application.
This slide presents how older generations of transit signal priority work, particularly prior to a connected vehicle environment. Most existing priority systems are optical systems consisting of an optical emitter on a vehicle and an optical receiver at the signalized intersection. The vehicle may be a transit vehicle or an emergency response vehicle. As the vehicle approaches the intersection, the optical emitter is activated either manually by the driver or perhaps based on the vehicle location if the vehicle is equipped with AVL, automatic vehicle location. The optical receiver mounted near the signalized intersection activates an input in the traffic signal cabinet, then triggers preemption or priority depending on how to signal controller cabinet is wired.
However, there are some limitations to these optical systems. First, it needs line of sight, which could be a problem in bad weather. Bad weather can also affect the operating range in the optical system. Think about a snowstorm because it’s optical. If there’s a snowstorm, the range of how far away I can see optical signal decreases. There’s also limited information. The system may not know what vehicle or type of vehicle made the request. The time a request was made or received may be the only information available for post processing. The systems also tend to be proprietary, which is a barrier to extending and expanding transit signal priority to other corridors. With proprietary systems, you have to go back to the same vendor to expand the system. The equipment also has to be purchased for each intersection that the priority is needed and for each bus that desires to be able to request priority. And finally, there’s very little security. There is little verification of the identity of the requester.
To address part of these problems of proprietary equipment, there has been several efforts to develop ITS standards that will support transit signal priority in the past. One of those standards is NTCIP 1211, which addresses signal control priority for signalized intersection. NTCIP 1211 is the information content standard and provides a vocabulary for sharing information between different components of a priority system. If you’re interested in learning more about NTCIP 122, transit modules 8 and 9 present NTCIP 1211 in more detail. Additional information about taking these courses or these modules is presented at the end of this presentation and also in the student supplement.
This slide presents a primary components of a signal priority system as defined in NTCIP 1211. Each component performs some specific functions that are necessary for a priority system. These components are the priority request generator, which generates the priority request for signal priority. Hey, I’m interested in getting priority at this intersection. The priority request severer or the PRS receives those priority requests and processes the requests to determine the optimal signal timing to service a priority request and then transmits the service request to the coordinator or controller. As a note, a priority request server can process competing priority requests and then determine which ones should be processed first. And then finally there’s the CO or coordinator. The coordinator is actually the traffic signal controller and receives the service requests from the PRS and provides the signal priority. Each is a logical component for a piece of software that performs these functions, maybe as part of a transit management software or software component on the bus or software and then traps the signal controller. They may be physical devices that are located somewhere, such as on the fleet vehicle, in the roadside cabinet or at a management center. This is discussed more in detail later in this module when we present the physical architecture.
They keep wanting to know about—to know is to know what information is exchanged between these components in the connected vehicle environment and that information is presented in the next several slides. Which in the signal priority, there are only two components that are considered in the connected vehicle environment, the priority request generator or the PRG; and the priority request server, the PRS, which is usually part of the infrastructure. Physically, there are only two entities. The requester, which may be an on-board unit on a vehicle or a smart device on a vulnerable road user; and the infrastructure, which is represented either by a roadside unit in the field or a center. From the authorized transit vehicle to the infrastructure, the information consists of a request for priority. This priority request may include when is the priority needed? When do I expect to arrive at intersections? Where is the bus going? Where am I approaching the intersection from? Am I coming from the north or the south? And when I get there, do I want to make a left turn, go through, or make a right? And finally, how high a priority is the priority request?
Well, this module focuses on transit vehicles again, but remember, a signal priority would work the same way for any authorized vehicle even authorized vulnerable road users. It could be an emergency priority, emergency vehicle or a freight vehicle. Note that the connected vehicle does not consider the interface between the PRS, priority request server, or and the coordinator in the bottom right hand corner of the slide while NTCIP 1211 does. NTCIP 1211 also addresses the interface between the PRG and the on-board unit and the RSU and the priority request server.
In addition to priority request from the vehicle to infrastructure point of view, a vehicle can also broadcast general information about its current location, its kinematics, meaning hey, what’s my current location, what’s the speed, which direction am I heading. And description about the vehicle itself, including what type of vehicle it is. Based on that kinetic information and what type of vehicle it is, the infrastructure can then make a decision its priority to be provided to the vehicle. It doesn’t necessarily need a signal, a request, a priority request message or information. In the other direction, from the infrastructure to the vehicle, information consists of the status of the priority request. So I’ve sent a priority request. Now the infrastructure can stand back, okay, what did I do with that priority request? Am I processing it right now? Am I going to grant it or deny it? And if I am doing something, what am I doing to grant your request? Am I providing an early green? And it indicates—and or am I going to extend the green for you so you have more time to go through the intersection? Other information from infrastructure of the vehicle may include signal phase and timing data. So, this is information about signalized intersection. What’s happening at the signalized intersection. That can be used by a transit vehicle to determine if the vehicle needs transitional signal priority. Oh, I’m green right now for you, in your direction of travel. I’m going straight green for the next minute, about the next minute, so you don’t need to make a priority request.
The MAP data provides information about the roadway geometry, static roadway information. This [is] so that the status of the transit vehicle can tell the intersection what lane to request priority for and what lane it would like to exit the intersection on. Generally, SPaT and MAP information data need to be provided at the signalized intersection to provide transit signal priority in a connected vehicle environment. Both messages are defined in SAE J2735, which we’ll talk about shortly. If you want information about this, learn more information about the SPaT messages on the MAP information, there’s another called CV273, which is the introduction to SPaT and MAP messages. Again, that information will be provided at the end of this module or in the student supplement.
But what are some of the advantages of using the connected vehicle environmental to provide transit signal priority as opposed to traditional systems? First, there’s lower initial cost if infrastructure and vehicles are already connected; that is, they’re already exchanging information. They may already be connected, some in support of other applications, such as V2V for safety or some signalized intersection applications such as red light violation warnings, which warn vehicles about other vehicles that might be in or entering the signalized intersection. If you’re already connected, then the transit vehicles and infrastructure only needs to be expanded to support the transit signal priority application.
There’s also other transit applications that may be considered. So, there’s another module, called Module 11: Transit and the Connected Vehicle Environment, Emerging Technologies, Applications, and Future Platforms that you may be interested in. Again, this information about this module can be found at the end of this module or the student supplement. But if you’re already supporting applications in a connected vehicle environment, then it’s a low cost just to support, just to add the transit signal priority application support.
Standardized messages across regional transit corridors is another advantage. This allows for expansion of the TSP system while still supporting innovations. For example, an application from one vendor, they offered new features without requiring changes to the transit priority infrastructure. A connected vehicle environment can also standardize security measures for all participating vehicles. This includes certificates that verify the identity of a requesting vehicle and what privileges have been granted to that vehicle. Additional performance metrics will also be available or information. Traditional signal priority systems may not be able to track which vehicles made the request, the location of the vehicle when the request was made and how often priorities requested and granted. In a connected vehicle environment, that information may be now available.
So, we reached our first activity. The purpose of these activities or quizzes are really just to reinforce and remind you of what we have learned in the previous learning objective. So, our quiz question and our activity with this learning objective is what is a disadvantage of using a traditional optical transit signal priority system? Your answers and choices are A, Special equipment is required for each intersection; B, Line of sight is required; C, Limited amount of information can be transferred; or D, All the above.
So, the correct answer is, of course, D, all of the above. All the above are disadvantages of an optical transit signal priority. Special equipment is required at each intersection and on each vehicle. Line of sight is required, and only a relatively little amount of information about the priority request or about the vehicle can be obtained in an optical system.
So, we reached out second learning objective. So, previously, we’ve, the module introduced what data as needing to be exchanged between the components to enable transit signal priority in a connected vehicle environment. Over the next several sides, we’re going to describe some of the standards that support these data exchanges to enable transit signal priority and connected vehicle environment and the content of those standardized messages.
The key standard for connected vehicle environment is the SAE J2735 standard, currently known as the Dedicated Short-Range Communications Message Set Dictionary. It’s a data dictionary for the contented vehicle environment. It defines the messages, the data elements for the connected vehicle environment. It also defines a message framework for new messages if there is a new user need as defined.
First, an introduction to the structure of the messages in SAE J2735. SAE J2735 contains definitions, updated elements, data frames, and messages. This side is a graphical depiction of the ratio between the message, the data frames, and the data elements. On the top, we’re going to use a signal request message as an example. A message is a sequence of data frames or data element providing information for a pre-defined application that collectively supports some function. An analogy of a message in England in the English language is that a message is analogous to a sentence.
Data frames are sequences of related data elements that provide information on a very specific topic. An example is location. Individually, longitude, latitude, and elevation is interesting, but to get at these three data elements are important and actually mean something together. Another example is a date and time. By itself, hours, minutes and seconds are interesting, but together it is an important data concept. So, an analogy to the English language for a data frame is a phrase. And finally, data elements are the smallest entity of data and are the words that create phrases or sentences. In the English language, a data element is the equivalent to the word. So, this is the structure the SAE J2735 standard. We have identified several messages that provide certain information for an application.
So, one of those messages of our interest of to us is the signal request message. Previously, the contents of a priority request from an authorized vehicle is described in general terms. An SAE J2735, that priority request is provided by the signal request message. This message can be used to request preferential treatment at one or more signalized intersections. Preferential treatment, if provided, is based on a vehicle’s estimated time of arrival, the lane that the vehicle expects to arrive at the intersection, and actually that lane that it expects to exit the intersection. This requires that the vehicle knows that lane identifiers at the intersection, meaning hey, which lane is what number, for example? How do identify each lane? This can be accomplished by a database on the vehicle or broadcasted by an infrastructure using a different message called the MAP message.
This is a graphical depiction of a signal request message. Over the next several slides we will view the contents of the signal request message. This module does not represent all the data elements in the signal request message, but provides an introductory overview of the key data concepts. Each data concept consists of a type and the name. The type identifies is the type of data, whether it’s a data frame or a data element and the name is the name of the instance. Each box contains an instance name of the data concept. Boxes in green are mandatory, which has to be included and yellow are optional, meaning optionally if you like, that data element can be included.
So, for every message in SAE J2735, we have a message ID and that’s the instance name. And it consists of a data element called DE_DRSCmsgID. It defies what type of message follows. So, in our case, the message ID is always going to be 14 or the signal request message where at least the 2016 version, which is the current version of the SAE J2735. Next is the timestamp, which represents the number of minutes of the current year when the message was first constructed. Notice that this is optional. However, the second or seconds within the minute that the message was constructed is mandatory. We want to know when you sent the signal request message.
The next element is the sequence number. It’s really a counter for the message. It’s defined two different ways, actually, in the SAE J2735. That message counter can be incremented every time the message is transmitted or whenever the contents of the message changes, which allows a receiver to ignore the contents of the message if it’s already been through this process. So, for example, on my message counter is 4 and I see, oh, a second message that also has the message counter of 4. I know, oh, it’s the same information; I can ignore the contents because I’ve already processed it. I know what’s in that message.
Next is requests. And this contains information for an intersection. So the message supports up to 32 requests. So, in other words, we can support a single messages to the [port]. Request up to 32 intersections in a single message can support a request for up to 32 intersections in a single message. Next is the requester. This provides information about the traveler or the transit vehicle making a request. And finally, there’s something called regional, which allows for regional extensions. We call that a SAE J2735. It may be used internationally. So, this is a section where specific regions, such as or countries, can add extensions. So, to extend it, extend the message in case there’s a need that was not previously supported in the signal request message.
Continuing that information, one of the options was requests. Remember, we can send up to 32 requests or requests for up to 32 intersections. If the request information is provided, each request consists of the following information. First, ID. It’s the ID of the intersection that we want the priority request for. So what’s the unique, what’s the ID? And it’s up to each region to determine or provide a unique ID for all the intersections in that region. The next is the requestID, which identifies the request.
Again, this is like almost like a counter. This is request number 5. This is request number 6 for this intersection. requestType indicates, hey, is this a new request? Is it an update of a previously sent request? Or I might want to cancel a previous request. So and but the first time, I send a request to intersection, it’s new. But let’s say I want to update my estimated time of arrival. I thought I was going to be one minute and now it’s going to be 40 seconds. So you may send an update request, like, hey, I was wrong, it’s now 40 seconds. Or for some other reason, oh, I’m picking up a passenger. I want to cancel a previous request. And then finally it includes inboundLane, which identifies the lane the requester requesting priority expects to enter the intersection.
Optionally, we could also include the minute, which is the number of minutes into the year that I’m expecting to arrive at the intersection and also seconds, number of milliseconds into that minute for an estimated time of arrival. Oh, I expect to arrive about 150 milliseconds into the minute. It’s in the current or the next minute. We could also provide duration, which is, which means A, I expect to arrive in 150 milliseconds, but make the request available for an extra 30 seconds after that because I’m not sure how/ when I’m actually going to arrive, but give me a 30 second window. So, that’s the purpose of the duration. And finally, you may also want to also want to provide outbound lane, which is identify a delay that I expect to exit intersection. Am I expecting to exit by going through the intersection? Or maybe I want to make a left turn. Which lane do I want to exit the intersection?
Then now, also for the requester, I want to include an ID of the requester. So generally, in the connected vehicle environment, SAE J2735 applies that this should be a temporary identifier because we don’t want—we’re concerned about privacy. So, identifier normally changes but for a signal request message in actual implementation, you have fixed ID in practice. So, it could be, for example, the vehicle identification number for that vehicle, or it might be the bus number for us. Next, we identify the type which identifies what type of vehicle it is. Is an ambulance, is it a bus, is it a pedestrian? HPMS, by the way, is the Highway Performance Measure Monitoring System, and it’s a requirement for receiving funding for interstate highways. So, that’s what could be used as part of vehicle type.
Optionally as part of signal request message, we can also include the position. Where is the vehicle right now when I made the request? What direction of travel am I heading? Am I heading northbound, southbound? What’s my current speed? Am I traveling at 15 kilometers per hour or 30 kilometers per hour? A name, which is a descriptive name but it’s actually not used in practice. It’s more for debugging purposes. And finally, a routeName, so it could be It could be Route number 15 or it could be, oh, heading to our Main Street.
Other optional information that may be included in a signal request message include the status of the transit vehicle. Is it currently parked? Am I currently helping a handicapped person? A bus lift, is it in progress? Is a vehicle door open, for example? So that provides more information about the transit’s current state of the transit vehicle, which can impact when transit’s priority is needed, transitOccupancy, and this is a relative level of ridership. Sometimes you may want have a rule that says only if the transit vehicle is partially full or fully loaded, do I provide transit signal priority. So this is a data element that can support it. And finally, transit schedule which says how far am I from my posted schedule? Am I ten seconds ahead of schedule? Am I two minutes behind schedule? And this may impact the rules for providing priority.
So, this slide summarizes what are mandatory and what is the minimum information that has to be provided in a signal request message. To summarize the mandatory elements of a signal request message is our second. When was the time the message was generated and ID, identifier of the requester. It’s generally a fixed ID. And that’s really it. That is because sometimes if you think about it, if you’re at a railroad crossing, you may want to say, hey, I’m a railroad crossing. I’m not stopping. You better give me priority. So that might be that’s why that’s the minimum required. As soon as I see that vehicle on a railroad track, I may say, yeah, I got to give this priority on for safety reasons. However, if I do want to make a request for service such as a transit vehicle, then there’s some additional mandatory elements that should be provided including the ID to identify the intersection I’m requesting priority for. The request ID which means, oh, this is my fifth request for this intersection. The request type, whether it’s a new update, updated priority request or to cancel a priority request. And inbound lane. Which direction? Which lane do I expect to enter into the intersection? So which lane do I want you to provide priority for?
So, this is a typical use case on how a signal request message is transmitted for transit signal priority and connected vehicle environment. So, a transit vehicle enters let’s say DSRC, which is the communications technology range and approaches to signalized intersections. The transit vehicle wirelessly broadcasts the signal request message with its estimated time of arrival and to identify the lanes it wishes to enter and exit both intersections. There are actually at both intersections we seize that signal request message and then relays the request to the priority request service, which processes the request for each of those intersections.
So, we’ve covered a signal request message, which is the priority request. Another message supported by SAE J2735 is the signal status message, which is broadcasted by the infrastructure, so let’s say a roadside unit, and can be received by a vehicle. The purpose of the signal status message is to say, hey, we received your priority request and now that’s here’s the status of the priority request.
So, this is from the infrastructure back to the vehicle. So, this is a graphical depiction of a signal status message. Again, boxes in green are mandatory, and yellow are optional. In the signal status message, the first element is the identifier. What message is coming?
So, a signal status message in the 2016 version of the SAE J2735 has a message ID of 15.
The next element is a time stamp, which is hey, how many minutes into the year was this message constructed? And then second numbers of milliseconds within the current that when this message was constructed. Again, sequence number, which is a message counter, and reality, the standard says this could be a count. It gets implemented every time I send it. But in practice, it indicates that this, we up increment the message only when the information inside the message has changed. And then the status, which contains information about intersection and the status of the requests that have been received for that specific intersection. And then we have a way to add regional extension at the end of the message.
Looking at a little bit more carefully at the status, each signal status message contains information for up to 32 intersections. For each intersection, the signals status message contains the sequence number, which is again, a message count that indicates hey, as the contents of this signal status for that intersection hasn’t changed. The ID, which, intersection is this status for and inbound on, which means, hey, we received a request for this particular lane and this is the identifier of that lane for entering the intersection. Continuing on, there’s also status, which is the status of that particular priority request. It could be, hey, we’re processing the requests right now. We’ve granted and this is what’s going to happen. Or we rejected it and these are and why have we rejected it, possibly. And then requester, meaning, hey, who requested the ID. And this is optional, so we’ll come back. Hey, ID number 5. This is the vehicle that requested ID of the vehicle that requested that this priority request and that we’re just returning it. But you can look for yourself and know, oh, yeah, this is the vehicle that made the request. Optionally, we can also say, hey, this is the identified lane for exiting the intersection as part of that status of the request. Estimated time of arrival in elapsed minutes per year. And second, which is the number of elapsed seconds, or actually those seconds. It’s, oh, actually seconds into the minute.
So this is a typical use case on how the signal status message is transmitted for transit signal priority in a connected vehicle environment. So, this is a scenario where two transit vehicles approach the signalized intersection, and each has broadcasted a signal request message to the signal controller. The signal controller roadside unit is broadcasting a single status—signals status message with a status for each of the priority requests.
A potentially alternative method for providing signal priority is to use basic safety messages. So and these are broadcasted by any equipped vehicle. So it’s broadcasted by the on-board unit in the vehicle and it provides the location, the kinematics again, speed, heading, acceleration of the vehicle and sensor information about the vehicle. Optionally as part of basic safety message, it can provide the type of vehicle it is. Is it a bus? Is it a truck? And it’s certified and indicates what security permissions it has, meaning if it contains a certificate, it contains what permissions it has for specific services. So basic safety messages can be used to determine priority can be granted based on the location of the vehicle, the vehicle type—is it a bus? Is it a truck? Is it an emergency vehicle? And the permissions of the vehicle.
So, this is a graphical depiction of basic safety messages. Again, boxes in green are mandatory and boxes in yellow are optional. Inside the Basic Safety Message, the message ID is 20 so a value of 20 indicates that it’s a basic safety message and then it contains core data, which includes data elements that’s included, that’s mandatory for the basis station message, which includes the location, the direction that the vehicle is traveling, the speed, the acceleration and break status. And then there’s data frames for part two, which are optional extensions such as the event state, whether the lights are on, where’s the vehicle going, where’s the vehicle coming from and vehicle classification, which is the type of vehicle. And again, it could contain regional extensions. So basic safety messages, using the basic safety messages are an optional option for using or providing transit signal priority.
And so, for example, this is a typical use case of how basic safety messages can be transmitted and used for transit signal priority in a connected vehicle environment. A transit vehicle enters the DSRC range and approaches two signalized intersections while wirelessly broadcasting basic safety messages. The roadside unit receives and processes the basic safety message information to determine the location, vehicle type and service permissions of each of the buses. If the transit vehicle is satisfied, they establish criteria for signal priority. The roadside unit can—will then send a priority request to the priority request server.
So, we’ve talked about the SAE J2735. There is other standards that may be important and vital, actually, not only to transit signal priority, but to the connected vehicle environment in general. And one of those standards is the IEEE 1609.2. It was designed for United States, but it’s actually been adopted internationally, regardless of the communications technology. So 1609.2 provides certificates. It helps provide security in the connected vehicle environment. Security involves participants in the connected vehicle environment trusting the validity of information received from other system participants. Meaning, hey, you’re providing the information. Can I trust you? This trust is critical because of the safety critical nature of connected vehicle communications, and the risks involved with broadcast communications.
The current security system for the connected vehicle environment establishes trust through the certificate, through the certification devices and the inclusion of credentials within the messages broadcasted that the center is a trusted participant. Meaning, hey, here’s a certificate that certifies I can be trusted. The credentials consist of IEEE 1609.2 certificates indicating that the center is trusted and has been granted the privileges to transmit that message.
One of the features in the 1609.2 certificates is the service-specific permissions or SSPs. The SSPs are used to indicate that additional privileges, such as ability to request preferential treatment. By equipping authorized transit and emergency vehicles with these certificates authorizing the transit signal priority request, requests from non-eligible vehicles can be excluded from the priority services. When security mechanisms are not considered in the transit signal priority for connected vehicle environment, any vehicle broadcasting priority request messages has the potential to be granted priority at a signal when they request it. So, to learn a little bit more about 1609.2 or about security, there’s two other modules. One is CV265, which is Introduction to IEEE 1609 Family of Standards. And then there’s also CSE201, which is the Introduction to Security Credential Management Systems, which is specific to connected vehicles or environments. Again, both these modules, how to access these modules will be provided at the end of this module and also can be found in the student supplement.
So there, let’s talk about a little bit about the early adoption about standards. There are currently a handful of actual trans signal priority connected vehicle environment implementations in the United States. Most implementations are pilots involving only one transit agency and one traffic agency, but several more are planned. National interoperability is not a concern; regional interoperability is. By interoperable in this context, we mean that transit vehicles from different vendors and different transit agencies may exchange information and use that information such as priority requests with any traffic signal controller from different vendors and from different agencies. And they’ll work and they’ll understand the information that’s being exchanged.
An implementation does not have to be nationally interoperable. TSP implementations are regional in nature because transit vehicles generally do not operate nationally. The implementation of transit signal priority applications is communications technology neutral, meaning the software is communications neutral. It doesn’t matter if we’re using DSRC radio or CV2X or more specifically 3GPP PC5 Mode 4. It doesn’t matter what radio is being used. The only difference is which radio is selected is at the physical layer; the applications will work the same way, regardless of the communications technology. And finally, a note that it’s the same standards, the same messages, same security concepts are used for emergency vehicles and for freight vehicles as with transit vehicles.
So, we reached our next quiz or activity. The question is, what is a mandatory element of the signal request message? Your answer choices are: A, Request identifier; B, Requester identifier; C, The sequence number or the message counter; or D, The estimated time of arrival.
And the correct answer is B, requester identifier. That’s really the only mandatory element in signal request message. The request identifier is not mandatory unless a specific request is made. For example, okay, I would like to request a signal priority at this intersection. SequenceNumber (the message counter) is optional. Is this helpful for receiver to know, oh, has the message changed. And the estimated time of arrival; again, that that is also optional.
Now we’ve reached learning objective number 3, which is to describe what agencies need to do to prepare for transit signal priority implementation in a connected vehicle environment.
This module so far has introduced the data that needs to be exchanged to support transit signal priority in a connected vehicle environment and the standards that enable it. The module will now deal with the implementation issues and considerations for implementing transit signal priorities specific to connected vehicle environment. These implementation issues, including defining the roles and responsibilities of the different agencies, the physical architecture of the transit signal priority system and some potential implementation approaches. This is a generic consideration, but basic but important one.
The transit signal priority needs to first identify one priority request may be generated. The connected vehicle environment and the transit signal priority system must support those business rules. The second key point is that transit signal priority must support the goals and objectives defined. If the performance measure is reliability, that the transit vehicles arrive on time, whether earlier or late, then the transit signal priority must be able to support measuring that metric. The last is outreach with other agencies that may also request preferential treatment.
What other public safety providers or freight operators or other transit agencies, whether it’s trucks, may request preferential treatment and who has a higher importance under different situations? Can we share the implementation costs? For example, rather than have different proprietary preemption and priority equipment, one for emergency vehicles and one for transit vehicles, split the cost of nonproprietary equipment.
The traffic agency on the other hand needs to determine where, how and when to service signal priority requests. The connected vehicle environment and transit signal priority system must support those business rules.
The next implementation step is to define the physical architecture. The physical architect describes the physical components of the transit signal priority system, the interfaces between them and where the logical components resides. Again, this being the priority request generator and the priority request server. The diagram below reflects a typical physical architecture for current transit signal priority implementations, where an optical’s emitter on the fleet vehicle transmits a request to a receiver at the intersection. The logical entities, the PRG, to PRS and CO, are all located inside the traffic signal cabinet in this case.
Training Module 8 again provides more details about defining the physical architecture. Another decision is to define how wireless communications will be provided in the region. What communications technology will be used? How will security be provided? At the time this module is developed, these decisions had not been made on a national level. However, if a region has already developed a connected vehicle environment, to realize the most benefits it may make sense to use the same communications technologies and standards.
In a connected vehicle environment, transit signal priority is provided by exchanges, signal requests and signal status messages between the on-board unit on a vehicle and a roadside unit or a center or at least that’s one way we could do it. The source of the priority request is the priority request generator, which is likely located in the transit vehicle. It could be a software application residing in the on-board unit, part of the vehicle on-boarded system or a separate device. The PRS is part of the infrastructure and it’s a logical component that may reside in the RSU on the controller or a separate device in the traffic signal cabinet or actually at a central location.
Which physical device acts as the PRS that the priority requests are maybe the most important decision for defining the physical architecture? It is at the PRS where the business rules can be enforced and decisions on how priority requests is priority is implemented. If the PRS resides in the traffic signal cabinet, any changes will have to be implemented at each and every cabinet affected. If the PRS is at a centralized location, a centralized infrastructure would have to be in place. If the PRS is integral to the transit signal controller, then the agency has little or no control over their algorithms and must work with the control vendor for any changes.
Two potential physical architectures in the connected vehicle environment are shown on this slide using the SAE J2735 signal request signal status message. The top diagram depicts the PRG as either a part of the vehicle on-board system or as a separate device on-board the vehicle. The PRG then uses NTCIP 1211 to send the priority request to the on-board unit, which then translates the data into an SAE J2735 signal request message. On the right, this RSU receives the signal request message, translates it back to the NTCIP 1211 and then forwards it to priority request server. The priority request server is somewhere in the traffic signal cabinet and then uses NTCIP 1211 to forward a service request to the CO, which is the transit signal controller.
In the second diagram, the PRG application is located within the on-board unit. It then generates a signal request message and then transmits it through the OBU to the RSU. The RSU receives the signal request, translates it to NTCIP 1211, which is then transmitted to the priority request server, which is in this case part of the traffic signal controller. Since the CO logical entity is also part of transit signal controller, the interface between the PRS and the CO is integral to the controller and thus can be proprietary. Note that in both cases, the OBU and the RSU are communications agnostic. We don’t mention whether it’s DSRC or CV2X radio.
An alternative to use the signal request messages and signal status message in the connected vehicle environment is simply use the basic safety messages generated by all vehicles as a request for priority. We’ll use the basic safety messages that are transmitted from an OBU to an RSU, a PRG process the location, the kinematics and the vehicle type of each vehicle and determines if a priority request should be generated.
The PRG could be a software application or the RSU or a device in the cabinet or a central location. The PRG then generates a priority request to the priority request server. The PRS processes the priority request and then sends our service requests to the coordinator. The PRS could be a device in the cabinet, part of traffic signal controller, be part of the RSU and or at a central location. In this example of physical architecture, the PRG and PRS are somewhere in the traffic signal cabinet and uses NTCIP 1211 to exchange information between the PRG and the PRS and between the PRS and the CO or coordinator.
Another deployment decision is to determine the vehicle types. The vehicle types is used to determine the importance of priority requests, generally based on that vehicle type. So, for example, you may want to have a railroad crossing have a higher priority over emergency vehicles, which may have a higher priority over transit vehicles, which may have a higher priority over freight vehicles. So this should be determined by the region in consultation with other agencies in the region that might be involved with granting priority, whether it’s the public safety agencies, the transit agencies, and the other traffic agencies that may grant priority. So, different types of vehicles to be considered. We just mentioned the railroad, the emergency vehicles, the transit vehicles, freight. The standards also allow you to distinguish between different classes of vehicles within that type.
So, for example, the transit vehicle is a type of vehicle, a vehicle type, but there might be different classes of transit vehicles. For example, a light rail transit vehicle may have a higher priority over a bus rapid transit, which may have a high priority over express bus, which might have a higher priority over a local bus. So, it’s called vehicle class in NTCIP 1211, but it’s called a subRole in SAE J2735. So, that’s an implementation consideration for each region. How should each—which, what type of vehicles and what classes of vehicles should have a higher priority over other vehicles and what those conditions may be.
Another important implementation is the check in. That is, when should the vehicle begin transmitting the priority request if the PRG is on the vehicle? Or what is the minimum distance from the intersection. Must the PRG detect a vehicle to generate a priority request if the PRG is somewhere else? The distance times will vary by intersection. The further away from the intersection, the more inaccurate the estimated time of arrival. However, if the check in is too close, the check in point is too close, the greater the possibility that the traffic signal control will be unable to provide priority service without affecting coordination.
There are certain facts, several factors that had to be considered for an optimal check-in point in the connected vehicle environment. One is to the transmission signal strength and the receiving strength of the RSU and on-board unit. So, the check-in point is within the transmission range of whatever wireless communication system is being used. The transmission rate, how often the data is generated and transmitted, and latency delay are other considerations. Check out has a little less of a concern for the transit agency, but it may be important to the traffic agency to allow the traffic signal controller to quickly transition back to coordination if it falls out of coordination. It’s a point so that it’s like hey, I know that the vehicle, the checkout is a point where we know, oh, the vehicle has left the intersection so you can go back to your normal signal timing, for example.
Again, the transmissions signal strength is less of a concern because it will be called to an intersection, but the transmission rate of the communications technology could be [an] issue. How soon after the vehicle physically clears the intersection will the controller know? Is it an updated signal request message? Is it a basic safety message? When will the message to be transmitted? Another consideration is how often does the AVL system on the bus let the transit signal priority application know its location? Every five seconds? Every 30 seconds? If it’s every 30 seconds, that could be a problem because, oh, the transit vehicle has left the intersection but it may not even know it left the intersection until 30 seconds later if it’s the transmission rate for AVL is every 30 seconds.
Whether the bus is nearside or farside may also have an impact on your side. Nearside bus stops are not desirable for transit signal priority. It is very difficult to estimate the time of arrival to travel through the intersections, but that the window to provide green time for the requester has to be much wider. That is more green time, may be needed to provide negatively impacted signal coordination. How long a vehicle will be at the bus stop, if there’s a right turn vehicle that’s stopped at the nearest intercession because a pedestrian is crossing, they all impact the estimated time of arrival for a vehicle to enter the intersection. The door open on a bus or the left turn signal both may indicate that the transit vehicle will move or not, so that may be helpful. But their transit signal priority system has to look for it if the transit vehicle even provides that information. Both of these, all this information, though, is supported in the signal request message, along with the transit vehicle loading a passenger or a bicycle or using their handicapped lift, for example.
But, queue jumps are as a form of transit signal priority and it’s an effective way of supporting your side bus stops. It’s a special signal indication that allows the transit vehicle to enter the section before other vehicles are released. Both so, you know, it gives a bus only signal, green, bus only green to allow the bus to enter the traffic where the queue jumps the check in point to be at the stop or the bus stop or the bus stop bay. Again, farside it’s just generally more, is, it is generally preferred because the approach speeds towards the intersection will now vary. Very much, it’s much more predictable. It won’t stop for a right turn. We are not as concerned about a bus stopping at a bus stop or worried about a right turning vehicle in front of the bus.
So we reached our third activity. The question is, where would a PRS not likely to be located? Again, priority request server not likely to be located? And the choices are: A, A transit vehicle; B, A traffic management center; C, A traffic signal controller cabinet; and D, A traffic signal controller. Where would a PRS not likely to be located?
The correct answer is A, a transit vehicle. PRS will not likely to be found aboard a transit vehicle. The PRS if you recall is a software application that takes multiple priority requests and then determines, oh, how do we best serve that those competing on priority requests? So, that would not likely be a transit vehicle but it could be at a traffic management center, like, say, on a centralized server. It could be at the cabinet. It could be a physical device in the cabinet. Or it could be performed by a traffic signal controller itself.
So we reached learning objective number 4 and learning objective number 4, the next couple of slides are really, we are going to review some case studies of four transit signal priority implementations in a connected goal environment.
Those implementations, those case studies are the multimodal intelligent traffic signal systems project. We’re going to describe and introduce how transit signal priority is provided in Tampa Hillsborough Expressway Authority, a THEA Connected Vehicle Pilot. We’ll talk a little about how transit signal priority and preemption actually was provided in Salt Lake City, Utah, by Utah DOT. And then we’ll talk about the SANDAG Bus-on-Shoulders project.
So, we’ll start first with the MMITSS. It’s actually probably the first implementation of signal priority in the connected goal environment. There was a pilot project to demonstrate the effectiveness of signal priority using connected vehicle technology. There were actually two different pilot projects. One was in Anthem, Arizona outside Phoenix and the other side was in Palo Alto, California. Each of them were slightly different because of the controllers and the equipment and the standards that they used at each of those, both of the different sites. The pilot demonstration used SAE J2735 but the 2009 version of the standard. Some of the lessons learned from the, from these MMITSS pilot projects were incorporated into the current version of SAE J2735 which was dated March 2016. Also, they used NTCIP 1202 and we’ll show you how it was used. Those objects, that standard was used. NTCIP 1202 is an ITS standard that provides the object definitions of the data dictionary, to monitor control and configure traffic controllers.
So, this is a visual of the system architecture from the MMITSS process. This is the system architecture for the MMITSS project. The equipped vehicle on the right transmits a signal request message via the on-board unit or on-board equipment to the RSU radio. That message is forwarded from the RSU radio to the MMITSS roadside processor, which is a computer, a field computer, which also received the signal timing information from the NTCIP 1202 traffic patroller using NTCIP 1202 objects.
Based on the business rules established the MMITSS process then makes the decision on signal timing changes and sends it to the controller using NTCIP 1202 command objects directing the control what to do and how to allocate the green time. The MMITSS then broadcast a signal status message back to the vehicle to acknowledge the signal request message. When the equipped vehicle departs the intersection, it then sends a cancel signal request message back to the RSU radio.
So some of the lessons learned from this pilot project. As I mentioned, first of all, that some of the lessons learned was incorporated into the 2016 version of the SAE J2735. One of the differences for this implementation was how priority was determined. and traditional transit signal priority usually provides preferential treatment based on the first come, first served basis or based purely on the importance of the vehicle type. For example, emergency vehicles always had priority over a transit vehicle. However, the algorithms used in this MMITSS project consider other performance measures such as the overall delay.
So it was trying to optimize overall delay at the signalized intersection. So it could give priority to a transit vehicle first and delay an emergency vehicle let’s say for five seconds if it reduced overall delay at the intersection. Oh, but traditionally it’s like, oh, emergency vehicle, I’m going to grant it to you, but it could create, you know, it might delay the transit vehicle for a minute and a minute and a half. So the MMITSS took that into consideration and it’s like, hey, if I just delayed the emergency vehicle for a couple of seconds, I can reduce the overall intersection delay.
The next project just this Tampa here, the Hillsborough Expressway Authority or THEA connected vehicle pilot. It’s one of the sites, one of the three sites for USDOT’s connected vehicle pilot deployment program. It’s a multimodal deployment program in downtown Tampa, Florida and it’s included a transient signal priority application with ten HART or Hillsborough Area Regional Transit buses that were equipped. This project used MMITSS as a starting point for the development, but it modified the MMITSS algorithm to support coordination between multiple adjacent intersections. Of course, this is a downtown area, so the signalized intersections were much closer so they wanted to support coordination between those intersections. And it’s there supporting NTCIP 1202. They opted to support the NTCIP 1211 objects, which we introduced earlier.
And this is the system architecture for the HART, for this connected vehicle pilot in Tampa. So the bus routes, the bus is included. The MAP data of where virtual detection zones on approach to the signalized intersection. I mean, it know, okay, when I reach this area at this point on the street that I should send a priority request. So when the bus location matches that detection zone, the On-board unit on the transit bus will broadcast a signal request message. The RSU that receives that signal request message and forwards it to the HART Transit Center via fiber connection. If the bus is on or ahead of schedule, the signal request message is blocked and nothing else happens. The priority is not provided. But if the bus is behind schedule, the central server returns the priority request back to the roadside unit.
The roadside unit included a software object that receives the priority request along with other signal request messages from other approaching vehicles, including emergency vehicles. And then it will grant the priority by sending/issuing NTCIP 1211 priority request to the signal controller for each approaching vehicle. And then the RSU would then send back a signal status message back to the vehicles indicating that hey, was priority granted or not?
The next case study is in Salt Lake City, Utah DOT. So Utah DOT embarked on a project to deploy connected vehicles along [an] 11 mile urban arterial corridor. The corridor consisted of 30 or so signalized intersection and had included a transit bus route running along the corridor. The goal of this project, of the point of transit signal priority use of connected vehicle technologies, was to improve schedule reliability while meeting SPaT challenge, which was a challenge for all 50 states in the United States to the fully connected vehicle technologies for at least 20 signalized intersections.
To implement transit signal priority along this corridor, the Utah DOT used, again used Arizona’s MMITSS software algorithms but modified it to support the equipment that Utah DOT deployed. They deployed roadside units and on-board units from different vendors. And to consider schedule adherence and passenger loading, for example, is the bus full, to determine whether signal priority should be granted or not.
In Utah DOT’s implementation, the on-board priority request generator on the left, shown as the on-board processor, uses its GPS location and received MAP messages from the signalized intersection to determine the identifiers of the lane that the vehicle expects to enter and exit the intersection. Using its position and estimated desire service time of that ingress and egress lanes if a priority requests a desire, the on-board unit generates a signal request message. The PRS in the roadside processor unit on the right side of the diagram collects those signal requests messages from the vehicles, selects a service, and then triggers the appropriate priority input on the controller. The PRS extension has been a signal status message back to the buses to indicate the status of those priority requests.
Some of the lessons learned from the Utah DOT. One of the interesting things about the Utah DOT deployment is that it also supported signal preemption for snowplows. As you can imagine, there’s a lot of snow in Utah, so those same intersections that provide transit signal priority also provides signal preemption to the Utah DOT snowplow vehicles in addition to other signalized intersections, meaning other signalized intersections in the area also provided signal preemption for those snowplows. Again, it’s the same messages. It’s the same infrastructure. But they use the same infrastructure to support two different applications. Priority for transit signal, priority for transit vehicles and signal preemption for the snowplow vehicles.
Right now, evaluation study is underway for this bus rapid transit project and for the snowplow pre-emption project. But based on what they’ve seen so far, they believe it’s been very successful and they’re planning to implement more corridors. Oh, by the way, I forgot to mention that part of the reason why they want to provide preemption to snowplow vehicles is that’s very difficult, especially in snow when it’s snowing, for snowplow vehicles to stop and slow down and it makes the signalized intersections more dangerous. So that’s why they provide signal preemption for those vehicles.
The last case study is for SANDAG or in the San Diego region, the Bus on Shoulders Project. It is a pilot project to explore technologies to support buses traveling in transit-only lanes of a freeway. So, this project was by SANDAG, which is their San Diego Association of Governments, which is the MPO, in partnership with the transit system down there, with Caltrans and then the USDOT. So, it’s a pilot project implementing transit signal priority using CV technology at a ramp meter instead of a signalized intersection. The goal of the pilot project was really to explore technologies, but it’s, however in this region, the transit-only lanes on the freeway were the shoulder lanes of the freeway and there was a safety concern on where the on ramps merged with the shoulder lane. As a result, connected vehicle technologies are being used to force ramp readers to hold vehicles on the on ramp as transit vehicles approach the conflict on the merge area.
This is a diagram showing how this project worked. It depicts the Bus on Shoulders concept at the ramp meters. It uses wireless technology to transit vehicle broadcast its location via the on-board unit. Roadside unit at the ramp meter receives those messages, processes the location to transit vehicles, and as a transit vehicle approaches the conflict merge area, the ramp meter is instructed to hold the vehicles on the on ramp until the transit vehicle clears the conflict area.
This is an interesting project in that they don’t use signal requests messages. It’s that the transit vehicles are broadcasted a safety message indicating, hey, this is where I am right now. This is my kinematics. This is my speed, my direction of travel, my acceleration. So, the transit vehicles do not transmit signal request messages but the ramp meters, though, do broadcast the signal status messages over back to the on-board unit. So it’s like, yeah, we’re holding it, the ramp meter for you so you could safely go through the conflict area.
Another interesting aspect of this project is that when they started the project they were planning to use DSRC communications radios, but they decided to move over and use a cellular C-V2X or the PC5 Mode 4 radios instead because they used something called wave short messages (WSM). That’s what the WSM stands for. It will allow them to switch over to the CV2X radios seamlessly. Applications were the same. It’s just the radios; the radio technology is different.
So, we’ve reached our last activity. Which of the following is an important consideration when deploying transit signal priority in a connected vehicle environment? Your answer choices are: A, Security; B, Physical architecture; C, Criteria for granting priority requests; or D, All the above.
And the answer, of course, is the all the above. All of them are important considerations for a transit signal priority system in a connected vehicle environment. Security is important. We have to know who’s got the proper credentials, who’s authorized to make requests for priority. Physical architecture is an important consideration for a transit single priority, especially the location of the priority request server. And what are the criteria for the priority request? Because you’ve got to have to make sure that your system can support that criteria.
So just to summarize what we’ve learned in this module. In this module, we described what the connected vehicle environment is and showed how by wirelessly sharing information between vehicles and the infrastructure, how transportation agencies can provide transit signal priority. We reviewed some standards that may be used to provide transit signal priority in a connected vehicle environment, specifically, SAE J2735, which is the data dictionary, then IEEE 1609.2, which provides the security certificates. We also described some of the information that has passed back and forth between the transit vehicle and the infrastructure in the transit signal priority system. Next, we talked about some of the deployment decisions that must be made when designing a transit signal priority system in a connected vehicle environment.
So while the focus again is on transit signal priority, the same concepts do apply for freight or emergency vehicle priority also. And the implementation may benefit from investment by multiple agencies. And finally, we presented four different transit signal priority deployments in a connected vehicle environment and discussed some of the differences between the deployments and some of the lessons learned, how they implemented their specific implementations. Finally, it is important to remember why we are deploying a connected vehicle environment through the wireless exchange of information among vehicles, travelers or vulnerable road users, and infrastructure; connected vehicles has the potential to improve safety and mobility on our roadways while also improving the environment.
As I mentioned at the beginning, this is the fourth of a series of modules on transit signal priority. The first module to describe how a signal priority system works and what they are capable of. The second module, Module 9 (Arterial Management and Transit Signal Priority: Understanding User Needs for Signal Control Priority (SCP) Based on NTCIP 1211 Standard - Part 2 of 2), this detailed how ITS standards can be selected and used to support a signal priority system. And the third module discussed how select ITS standards are used to develop, specify and test a signal priority implementation.
These are some other modules that might be of interest. Module 11 introduces the connected vehicles standards relevant to transit agencies in general, including the communications protocol standards themselves. Module 23 introduces how transit vehicles can prepare transit vehicles for the connected vehicle environment. So this focuses on the vehicles themselves. And then while this particular module focuses on the of the messages and the information that goes back and forth, it was also mentioned that the SPaT and MAP messages are also needed as signalized intersections so that more information can be found in CV273. And we mentioned two modules. If you want to find out more information about security, one of them is CSE201, Introduction to Security Credential Management System. And the other one is an Introduction to the 1609 Wave Messages.
So thank you again for completing this module. Please use the feedback link. We’d love you to provide us with your thoughts and comments about the value of the training. Thank you very much for attending.