Webinar: Vehicles Technology for Transit Signal Priority and Preemption

Transcript

Muriel Solil:
Good morning and welcome back to the Utah Connective Webinar series. This is the fourth of six webinars hosted by the Utah Department of Transportation. My name is Muriel Soill and I will be your facilitator for this event. This webinar series is intended to foster collaboration and promote information sharing among UDOT and its partners. It highlights six successful deployments across Utah, including significant deployments with connected vehicle technology that has helped to improve mobility, safety, and quality of life. Right here in Utah. All webinars are free and open to the public, but in advanced registration is required. These meetings are being recorded and the recordings will be made available to the public within one week of each webinar. Before we begin today's program, we'd like to ask you just a few questions via a Zoom poll like we have in the past. Your responses will be combined with other respondent answers and kept anonymous. Let's go ahead and get those pulled up and ask a few questions. What role best describes you? If you could take a minute to let us know, are you an engineer, a researcher, consultant, policymaker, or maybe something else we haven't listed? The second question, what industry sector do you work in? Is it public, private, nonprofit, academia, or again, something else we may not have listed. And the last and third question, how long have you worked in the field? Less than five years, six to 10 years or maybe a little bit longer, 11 to 15.
We'll give you just a minute to answer these questions and then we'll go ahead and get started with our scheduled programming.
It looks like the majority of you all joining us today are engineers with some planners, researchers, consultants, and a few other folks as well. So thank you. We look forward to having a substantive discussion this morning. Industry sectors, primarily public sector, but we also have some private sector partners and folks from the nonprofit and academic spheres. A good representative sampling of career professionals, folks just starting out, folks who've been in the industry in their profession for a long time and everything in between. Fantastic. So a little bit more about connected vehicle technology for transit signal priority and preemption, which is the topic that we'll be discussing today. Early benefits have been realized from deployments of transit, signal priority for buses, signal preemption for snowplows and preemption for emergency vehicles. These cutting edge deployments have made transit buses and snowplowing more efficient. This webinar specifically has subject matter experts who worked on these successful deployments here in Utah.
They will detail the planning, execution, testing, and maintenance of these use cases, discussing how the system interfaces with signal controllers and how we've been able to measure those benefits. If you have any questions throughout today's program, please feel free to submit them in the q and a chat feature at the bottom of your screen. If we're not able to get to every question today, we will make sure that we get back with you after the webinar. To kick things off, our first presenter is Blaine Leonard Blaine is the transportation technology manager at UDOT. In this role, he leads the planning and deployment of connected automated vehicle technology. He is chaired the American Association of State Highway and Transportation Officials connected and Automated Vehicle Working Group, and is also led the Spat Challenge Tactical working group. He is the current co-chair of the ASTO Technology subcommittee. Prior to joining UDOT in 2001, Blaine spent over 20 years in the consulting engineering business. He has a bachelor and master of science degree in civil engineering from the University of Utah. Blaine, go ahead and take it away.
Blaine Leonard:
Thanks Muriel. Appreciate that introduction and thanks everybody for joining us today. Let me pull up my presentation here. As Muriel said, we're going to focus a little bit today on priority and preemption at Traffic Signals, which is a connected vehicle technology that we started with and still use heavily, and I'll talk a little bit about that as we move through. I want to start as usual by thanking Federal Highway Administration who awarded us an A-T-C-M-T-D grant that allowed a lot of this work that you will see today to happen. We appreciate their grants team in DC and the local FHWA office and for all of the support they've given to us that grant funding allows us to bring you these webinars. So if you want some information about the AT T-C-M-T-D program and our original grant through that program, we talked about that in webinar one, I want to thank Muriel and her X-Factor team for coordinating and hosting and moderating these webinars.
They've been very effective and great partners in this. I want to thank today's presenters both from UDOT and from some of our consultants, Panasonic and Narwhal Group who have done most of the work in these deployments frankly, and have really brought a lot of expertise to the table and for our partner of the Utah Transit Authority, and you'll hear from UTA today about their perspective on this. I also want to thank all of you who are here, who are taking your time to participate with us. Maybe you're eating lunch while you're listening or doing something else. We appreciate you being here and for those who will log in and watch these after they're posted later, I know a lot of people do that, so thanks for your participation.
The goals of our webinar are really to share information. We've been through the development of connected vehicle technology here for eight years now, and we really would like to share this information with all of the rest of you tell you some of the challenges we've run into, the lessons we've learned from those challenges, foster some collaboration between agencies so we can all move forward together and to support and encourage each of you to head down this path that we've been on. Hopefully a shorter path because you can learn from some of the rest of us who've done this. Our transportation technology group here has several goals and they're rooted in safety and mobility. Our short-term uses of connected vehicle technology are often largely mobility related, and that's what we're going to talk about today is some of the mobility capabilities and benefits we can get from Connected Vehicle technology.
We also in the want to achieve full situational awareness of our system, understanding what's going on on our road network and to prepare for the time in a few years when the automakers will deploy vehicles that have connected vehicle technology on them. Specifically today we're going to talk about a couple of things we've done that are directed towards that goal of being ready for the production vehicles, specifically security credentials or security certificates on our messages and the RTCM message, which helps us with better GPS positioning. So we'll talk about those a little bit today. So as was noted, we are going to focus today on traffic signal priority and emergency vehicle and snowplow preemption. If you've watched some of our earlier webinars, we've talked a little bit about our connected vehicle deployments in Utah. Here's an overall map that covers most of those. There's a few off the map to the north that I don't show here, and we talked about this in some detail on webinar number one.
We've got about 340 roadside units deployed in about 270 vehicles. As we've noted in earlier webinars, specifically webinar number three, we started with transit signal priority. We didn't say, Hey, let's do transit signal priority. How do we do it? Hey, let's do connected vehicles. We said we want to deploy connected vehicles, we want to be ready for the vehicles that are coming from the automakers. Let's deploy something. How do we make it useful to us in the short term and transit signal priority was that feature, and so partnering with Utah Transit Authority, that's what we built. The application was more straightforward than some, so we sometimes called it a low hanging fruit, but it also gave us some good short-term benefits which enabled us to justify the expenditures and investment we were making. Later today, Michael Sheffield will talk about some of the performance benefits and also the challenges with measuring those benefits with the data that we get from our connected vehicle system.
We then expanded those deployments and you see a bunch of other blue dots corridors on this map where we expanded largely with both TSP and snowplow preemption, and again, we attempted to measure those benefits. A not very scientific benefit was recently brought to our attention this past winter. On the very bottom of your screen, you see some blue dots that represent a corridor traveled by a bus rapid transit line. We had a very heavy winter in Utah with a lot of snow and UDOT snowplow crews were incredibly busy trying to keep up with all the snow. We got record levels of snow at one point, the preemption system along that blue corridor there stopped working and we heard about it through the region leadership there, and so we jumped into a scurry mode very quickly to get that back up online, figured out what the problem was and got it up and running.
We later got feedback from the plow drivers that drive that corridor that without the preemption system in place, it can in a heavy snowstorm, take them as much as an hour and a half to plow that particular route. With our preemption system on, they were able to essentially cut that time in half. Now I realized that's just one data point and a bit apocryphal, and we wouldn't see that kind of benefit on every corridor, but measurable benefit is there for plow preemption on these corridors, and that kind of feedback allowed us to move forward with the A-T-C-M-T-D funds in hand. We were able to expand with additional corridors. The transit signal priority corridor that we added is UTA Route eight 50, which is State Street through Utah County, and I show that here in the red line. And then we added several additional plow corridors, plow preemption corridors.
These three corridors stay Route 92, pioneer Crossing and Redwood Road in Utah County are shown here in green lines, and so we will talk more today about how we did those deployments. Renee Phillip will discuss our efforts in expanding the use of data to evaluate bus idle times and fuel usage. We'll again hear from Michael Sheffield about the data from that Route eight 50 and what we learned from that data. Hal Johnson from UTA will talk to us about their perspective of this priority system and how they plan to move forward. Johnny Turner will talk a lot about the details of how this deployment is done, and I don't use the word details lightly. He's going to get into some details, and so those of you who are yearning for some details on the nitty gritty things that are required to make this work, you'll enjoy that presentation. We also had some additional technical capabilities added to our system as we worked through these deployments with these A-T-C-M-T-D funds, security credentials, which I'll talk about here in just a minute. Briefly, the integration of our data into Cirrus, which was discussed on webinar two largely, and the development of the RTCM message, which allows the GPS to be corrected and Johnny will talk about some of that detail. And so we got a lot of benefit from these additional deployments.
Messages through a connected vehicle system are transmitted in open air from an RSU or an OBU that's there, and they're just broadcast broadly to any other compatible radio RSU or OBU that's there to listen to it. It doesn't go through a cell tower as you know. It doesn't go through any kind of a central tower. It's an ad hoc message, we call it side link, and it's there just radio to radio. There is a way of securing those transmissions. And during this set of deployments, that's what we started to do was use digital security certificates to allow these messages to be transmitted securely. We have three things that come out of this deployment of security certificates, message authenticity, making sure that the messages are only coming from trustworthy sources and when you receive them, you can verify that message authorization, which means that the message you're getting can only do certain authorized things and message integrity, meaning that the message wasn't modified on route while it was being broadcast.
So that's really important to us to make sure that our system has integrity. We've attempted to follow national standards as we've done this. The primary standard that dictates these kinds of security credentials, our IEEE 1609 0.2, that's the Institute of Electronics and Electrical Engineers. Standard 1609 0.2 1609 0.2 is always being tweaked and upgraded and there's another tweak happening as we speak, but that's the guidance that we follow to use these security certificates, and it's important that we all do that so that we have consistent application of these messages around the country. There is a security credential management system manager that has been established by a couple of the OEMs and one of the certificate providers that is attempting to maintain trust in this overall system by having a central certificate authority so that all these certificates can be verifiable and coming from an authorized location, providing some authorized some oversight and policies to the national use of these certificates and monitoring misbehavior so that if entities are misbehaving in the system, broadcasting faulty information, unsecured information, their certificates can be revoked.
This credential management system is a work in progress. It's not fully developed yet, but we're participating with them to make sure that gets developed and we around the country all need to sort of follow into that system to make sure this all works appropriately. The security certificates that we use in our data transmissions, our message transmissions are provided by a trusted third party, and those come from one of several organizations that provide certificates. Once a device receives a certificate from that's attached to a message, we call it a signed message from another device, the receiving device can compare that certificate to a private key to verify that it's actually a reliable certificate and therefore the message was signed reliably. The messages are rotated, so a message is only a certain certificate is only used for a few minutes and then a new one is rotated in.
That allows you to not be able to track a vehicle specifically by following that same message on basic safety message after basic safety message after basic safety message shows an intentional design to prohibit us from being able to track a vehicle. These certificates are initially loaded into an RSU or an OBU by a vendor or in a secure facility under the authorization from that vendor and from the source of the messages. The messages have expiration dates on them and they periodically need to be replenished, which means that these devices need to have access to an internet system so they can replenish these certificates with our RSUs. That is a fiber backbone that gets us back to the internet with the OBU. It can be a cell system backhaul or some kind of a wifi connection that allows that to happen, and you have to pay attention to how that is done.
Securely devices that have security enabled on them will reject an unsigned or unverified message, and so all the messages have to have these certificates on them so that they're not rejected by the receiving device. We ran into a case as we were developing the RTCM message for instance, that on early developments we weren't signing those messages and the units receiving those messages wouldn't receive them, and so we had to go through some gyrations to disable security on some devices temporarily so we could test these messages before we continued along the path. So it's just something you need to pay attention to as you develop. We decided to implement security signing on all of our messages so that we would be secure. We didn't want people tampering with the messages or interfering with them, and we knew that in the long term we needed to have that done so that OEM vehicles equipped with veto X technology would trust our messages.
They will not trust an unsigned message. We argued for some time that, or we sort of had the opinion for some time that on a transit signal priority system, the security may not be as important and in some other messages, and so we didn't have security on them, but as we started to do these new deployments, it became clear that security was essential, and so we started adding them. Here are a few resources about security that you might find useful. The connected intersections implementation guide, CTI 45 0 1, we've referred to that several times. That's a fairly new guidance document that's been produced by SAE and ITE in collaboration with some other organizations and funded by the U-S-D-O-T. The connective vehicle pool fund study has produced a couple of documents, one of which we've referred to in the past that connect to the intersection guidance document and also a brief SCMS fact sheet that they've produced.
These can be found on the pooled funds resource page that's followed in this link here. So I realize I'm the first speaker, but as we worked through deployment of TSP and preemption in our system, from my perspective as an agency person, A DOT person, I wanted to share just a couple of lessons that I've learned along the way as we've gone through this and you'll get more lessons and more insights from some of the other speakers. But from my perspective, several things sort of stand out to me. The first one is that data analysis is not trivial. We talk a lot about the case of that when we deploy veto X, we will generate enormous amounts of data, data from the BSM message coming out of the car, data from the spat and map messages coming out of the roadside unit data that we can accumulate from the signal request and signal status messages, et cetera.
And these messages are sent every second or every 10th of a second, and they amount to an enormous amount of data. And so it's easy to say, well, we'll just grab that data and we can draw all kinds of conclusions from it. Well, you can, but the data is a little messy. It's variable, and getting clear results can sometime require a fair amount of effort, and I think you'll see that as Michael and Renee talk about their efforts to analyze this data. There are a lot of things that make this difficult specifically with transit systems. For instance, every driver drives differently, every passage of that vehicle through down the corridor encounters different traffic conditions and different weather and different cross traffic and different rider conditions that cause the vehicle movements to change a little bit. We have an ongoing discussion about how to effectively know when the signal controller actually grants priority when it's requested, and matching that data with the connected vehicle data sometimes poses a challenge, so I could go on about that, but there are some issues there.
The data is incredibly valuable, but it's not trivial to analyze it. Secondly, GPS accuracy is very important and it's not always inherently available. So a typical OBU that you will purchase has a GPS unit on board and its accuracy is generally within about a meter and a half. Well, that's good enough for some applications. It gives us some lane level accuracy, but sometimes we find cases where the bus appears to wander out of the lane, the bus doesn't actually leave the lane, but the GPS accuracy is just such that with the bus gets to one side of the lane or the other, it appears it moves to a different lane. Since priority is based on the vehicle being in a certain lane, sometimes that can cancel the priority request. And so accuracy is important. Accuracy is more important when we start looking at safety applications like red light violation warning and other things that the automakers are working on, and Johnny will talk about one of the solutions we've developed to the GPS accuracy issue using what we call an RTCM correction message.
So that's a lesson that we've learned kind of as we've worked. Probably the biggest lesson for me as we've developed this system has been that in sort of a word, we end up with a TSP system that belongs to two different owners, and I probably should explain that a little bit. The veto X system that we deploy has been developed and engineered and deploy and is maintained by a certain group of people in our group here at the Utah Department of Transportation. Traffic signals are operated, maintained by another group, by somebody down the hall and all of their maintenance people. We work together really well. We have really good cooperation with each other, but our systems rely on each other, particularly the V two X system providing signal priority and preemption relies heavily on the traffic signal controllers. When something doesn't work quite right, it's not just one team that has to look at it, it's two teams that have to look at it.
And sometimes both teams say, our part of the system is working fine when in fact there's some little nuance that neither one of them sees that we don't find until both teams sort of mesh together. Our signal operations aren't really impaired by our implementation of V two X, but sometimes V two X can be impaired by the way we implement signal operations. And so we've had a lot of discussion about that and it rolls into how we monitor and maintain this system over the longer term. If you then deploy this system on roads owned by another agency, now you add maybe a third owner or jurisdiction into this system. And so going into the deployment of something like TSP and preemption with V two X, you really need to keep in mind the various players that are involved and how to make sure they're meshed well from the beginning.
Finally, I'll leave you with a lesson I've left you with before. We need to start now. We need to be able to jump into this technology and move forward. It takes time to learn this system, deploy it successfully and get benefit out of it. The automakers are working towards deploying this, we believe, and it's time for all of us around the country to deploy aggressively. And if you haven't started, I would encourage you to get started because there is a learning curve and we've learned that from our experience. There's a learning curve. It takes some time. So that's my introduction to today and some of the lessons that I take away from the topics we're going to cover today. I appreciate your participation and I turn it over now to the others. I think Johnny is next as we learn about some more detail, we'll watch for your questions in the chat and we'll respond to those at the end or online later. Thank you very much.
Muriel Solil:
Thank you, Blaine. Love those takeaways. Data can be messy. We need to start now and collaborate with our partners. Now we turn to Johnny Turner. Johnny is the founding partner of the Narwhal Group. Johnny is the program manager for V two X systems within the company. He is responsible for V two X activities, including new hardware and software research, design development, device system deployment, integration system testing and maintenance. So he wears many hats. He leads a talented team of engineers, technicians, and developers to provide emerging ITS solutions for real world operational environments. Johnny has 23 years of experience in all areas of ITS and has a bachelor degree in electrical engineering from the University of Utah. He also has a licensed master electrician and serves as the company's contract qualifier in multiple states. Johnny, go ahead and take it away.
Johnny Turner:
Thanks, rna. Let me just get my slides here. Appreciate everybody who's in attendance today and Blaine for your intro Today. We're going to talk a little bit again, today's theme is about TSP transit signal priority and preemption. I'm going to speak mostly on TSP and snowplow preemption and get into some of the details of implementing the system and existing environment. I won't be able to go into all the details, but hopefully wet your appetite a little bit for some of the things that you'll see in these systems. So first off, we're going to talk about the roadside equipment. I know I've shared these slides before. I'm going to dive primarily into three items at the roadside, the RSU, the traffic signal controller, and the signal command module, which we use here in the Udo application implementation where we have in more cases the not typical NEMA TS two style cabinets, which is pretty prevalent throughout the whole state of Utah within all the agencies and other stakeholders as well.
So the physical installation of the RSU will begin with it. We use some sort of standoff mount in the case of the horizontal standoff amount. The purpose of it is to limit any interference from the luminary extension to make sure that we can get good wave propagation and coverage area of the RSU. And in the case of the astro bracket, that's when we need to mount to a mass arm, and that's typically due to overhead utility conflicts or places where there is in the luminary extension. So within the RSU, there's a lot of configuration and I struggle trying to share what configuration elements you need to know about. It starts from as simple as basic networking configuration like you can see in this network configuration screen, but it extends through immediate message forwarding and SNMP and setting up sort and repeat messages for things like Tim.
And I guess the big takeaway I'd like to encourage here is to establish a really good relationship with your RSU vendor to get the support because it's almost impossible to try to write a comprehensive guideline on how to work with the all RSUs. Each one's slightly different. So for some you may open taking it out of the box and the IFMA work just out of the box while others, you have to go in and turn everything on. Some other screens from the RSU, like Blaine mentioned, the SCMS, there's a screen there that shows the security credential management system. You can see that the certificates have been loaded and as mentioned before, you have to have an internet connection to those servers to get those replenishments or top offs on those security certificates. So as you set up the RSU, you need to set up the IP enroll in insecurity credential management services, and in doing that, you need to generate an enrollment request file from the radio itself, from the actual RSU, upload that to an SCMS website provider like, well, I mean there's a few out there.
Download the response from the SCMS provider and then reload that into the radio itself. And then, like I said, there's a bunch of other configuration settings like IFM and strangely as it may sound, it's still called DSRC forwards. There's a forwarding table in there that you need to forward that in there. So that's kind of the RSU. We use the RSU as radio and follow the standard for the RSU standard. And we don't run any applications on the RSU itself anymore. We did that in the very, very beginning. We don't do that anymore. Moving on, the next item is the signal command module. So it's a detector style controller that goes in the detector rack. And so in the detector rack it derives its power and also provides inputs to the controller via the back plane of the detector rack. And then on the front face, it connects to the controller for spat and also to the RSU through the ethernet network. The SEM has four channels on it, like a typical detector card. One nuance to it is that it can actually provide continuous or solid outputs or pulsed outputs, which give it greater functionality and we can do more things with it or provide additional movements or capabilities and double the capacity of the card.
So that's just kind of some of the configuration elements of the SCM will step through these kind of quickly. You can rewatch the webinar if you want to get some more detail. So the first thing we do is that we upload a map message, and in webinar three, Chuck Fel covered a lot about map creation and we can support either the FHWA mapping tool or an end map file. And so that's the first thing we typically do is we upload the map once it's created, and then we go through the configuration screen of the SCM where we set up the network configuration IP subnet gateway, the typical things, the S and MP user information for the R RS U. So the SCM can communicate with the RSU and then set up the traffic signal controller information, what IP import for example, that we are getting. The T-S-C-B-M, which is the traffic signal controller batel message, which we use to create the spat message in the SCM that gets forwarded to the RSU.
One of the other primary items that we do within the SCM is that we set up the lanes and the vehicle rolls for priority and preemption. So it's kind of hard to see, but you can see the different vehicle rolls, DOT, fire, ambulance transit, and then within each vehicle roll, we make assignments for the privileges that they have on a lane by lane basis. So for example, you can see that lane number two has a pulse to output, which is what we use for priority, and it's going to operate relay number four. And then that can be mapped clear through to the controller and it can recognize, okay, when I see a pulsed input come in on relay four, then I can implement TSPN. We'll talk about that or I'll cover that here in just a moment as well. So this is really kind of the critical element of making sure that the controller can be programmed and it's really that tie between the RSU and the controller to make the operation work and it's where the application's running. One thing to know, as Blaine mentioned about the GPS drift, what we'll do common times is we'll assign all the lanes in one approach to help overcome some of those issues that we see when we see a vehicle drop out of the lane, because when it leaves the lane, it'll cancel the request because it's not in the lane anymore. So we'll map all those approaches to help mitigate any GPS drift when we don't have corrections running.
Once the SE M'S set up, then you can use the screen to do some data validation. You can see what's happening with spat that you're getting, all those T-S-C-B-M messages are being created and that you're generating spat and setting that out to the RSU. You can see the map message and you can also see requests that are being made within the map boundary and the vehicles as they traverse the intersections. In addition to that, you can see some of the other messages and there's log files and different menus where you can see the BSM messages, the SMS ssms, and you can also see on that screen that we've got RTCM messages that are going out, and we'll talk about that in a little bit. And then also the relay channel outputs. So you can see in real time what relays are being commanded to the controller.
And that's super helpful for signal texts to know, okay, I can see these inputs going into the controller that are live and am I seeing them? Am I not seeing them? Sometimes we end up troubleshooting issues with the detector rack where for whatever reason an input's not working quite correctly. So next we'll talk about the traffic signal controller. So as part of this project, we didn't go out and replace all of the traffic signal controllers to get the latest, greatest, most connected vehicles supported signal controllers available on the market. And there's some movement happening there, but there's thousands of controllers in the UDOT and State of Utah system and it just didn't make sense to swap out controllers for some that may have some of those capabilities. So like I mentioned before, UDOT and most of the other stakeholders use the NEMA TS two style signal controller.
And so there's a picture of a typical cabinet and the front panel menu of signal controller, that's Anite cobalt intersection, and there's both that and a max time view where we turn the Ts CBM. So like I mentioned before with the RSUs, they all kind of vary. The same holds true with signal controllers. So when we go in and turn on the TS C bm, it's different for econ light than it is for in light. And my anticipation is that it would be different for lots of different intersections. Fortunately, econ light and in lite both support the TS CVM messages. There's some deficiencies there, and we're working through those, but they're available for us to use to generate spat. So in the case of econ light, all you really have to do is enter in the server IP field, the IP address of the SCM, which is where you're sending these T-S-C-B-M messages to.
And in addition to that, we have to do an SNMP set command where we have to command the controller with an SNMP value to make it start broadcasting spat, which is A UDP or excuse me, A-T-S-C-B-M, which is a UDP broadcast. And then in the case of max time, we enter those values. You can see that it says Patel UDP, and that's what we use for spat and that's built in, but you need to check the firmware versions of the signal controllers that you are using. If you're using older firmware versions, it's likely that you'll need to upgrade to a later firmware in order to be able to leverage using the T-S-C-V-M. So additional programming that's necessary within the traffic signal controller consists of the detection and logic statements as well. So here's the screen in the Q3 max time controller where you can see the statements that have been made in the controller.
So the variables are set, and you can see that in this case we have a pulsed input priority call going in on the very first line statement number one, and it's related to statements 13 and 14 where the TSP request and cancels are made. And so these logic statements are necessary in order to make the priority work in the existing UDOT environment through the use of the SCM. Similarly, there's the configuration shown here for prior, excuse me, preemption. And so you can see that statement two is where we detect the values of preemption calls coming in, and then that correlates to statement nine as well. So that's the Q3 setup. The ECO'S kind of similar if you're familiar with the eco front end, here's the walkthrough of it with its logic statements for both priority and preemption. And what's happening here is shown in the bottom right hand corner. So the first thing that happens when a vehicle goes into an intersection is, and whether it's a bus or a plow or emergency vehicle, is that call goes in and it actually shows up initially as a pulse to input.
Even a solid input showed us up as being interpreted by the controller as pulsed, and it has some weight values in here. And so it takes four tenths of a second for a preempt actually to occur. It immediately goes into priority and takes four tenths of a second to go into preemption. And then when a call leaves or a cancel message is sent, it will take four tenths of a message, excuse me, four tenths of a second before the controller will actually fall out. So that's what you can see through that bottom right hand corner of what's happening at the controller level. So I know that's a lot. Hopefully that makes more sense to the traffic signal engineers and technicians on how to set that up. You may need to watch through that a couple of times and there's some more nuances there and some honestly, timing preferences that are also depends on how you like to implement things, but there's some flexibility there.
Next we'll jump to the onboard. So the onboard for the bus consists of the OBU, the onboard processor, the connection to the CAN and the bus network. So like Blaine mentioned before, when it comes to certificate management, you have to have a connection to the internet. So in the case of the buses, there is a network connection to the internet that we can do over the air updates of the software or firmware on the OBU and OBP. And also we can do certificate top off. So that's kind of nice. We don't have to have a separate cellular connection that was already available on the bus that we could leverage it. And we have the ability to manage the OBU and OBP that way without any additional costs. So the physical installation of the OBU and the OBP, they go in the communications cabinet in the bus.
Most transit vehicles have something like this and it's readily available. Honestly, the configuration onboard the vehicle is pretty straightforward and fairly simple in comparison to the roadside elements. And then as Blaine mentioned before, we have the snowplow for preemption purposes. This goes behind a seat, this is in the picture here is in one of our test vehicles, but the spreader controller is what's typical in most UDOT plows. They use the Force America system for the spreader controller. And in addition to the CAN connection, we have the connection to the Force America. And what's in the right hand side is just the logic within the Force America controller where we go in and we provide an output. We do a 12 volt output whenever the spreader's in operation to trigger preemption for the plows.
In addition to the OBU, there's the onboard processor. So like I mentioned, you notice the settings for the onboard processor are much simpler. There's just where we define the vehicle role, the vehicle ID, some parameters of the vehicle and set that up. It's really pretty easy. And then we set the algorithm, for example, you can see UTA algorithm, and then within there we identify under what conditions when we receive a message from the bus, are we going to provide priority In this case, it's when it's late or critically late as defined by the bus's schedule or schedule reliability.
This screen is just a visualization of one on the left hand side. This is what the screen looks like when it's received a map message, and you can see all the ingress and egress lanes and the vehicle will place itself on that. In addition to that, it keeps a running list of the active maps and they age out after a little while, but hold on to 'em for a little bit. And here's another display of the V two X display user interface where you can see the bus data coming in and the BSM data going out and the spat information being received. And then when a request is happening, the SRM and SSM fields are populated as well as the RT cm when RT CMS coming in. So you can see here the different values that are available in the vehicle itself.
Next up we're going to talk about the RTCM correction. So as Blaine mentioned, the accuracy of the onboard OB is fine under some circumstances and for certain applications, but lacks in some others. So we took a couple of approaches. We started off by going to the Utah Geographic reference center. They already have an entrance server that's used for surveying purposes. So engineers and land surveyors subscribe to this service to get, excuse me, to their end Tripp server to get RTCM corrections. And there's some benefits about this system is that it doesn't require you to go out and set up a dedicated base station, and it leverages a whole network of base stations. And so not only does it provide some failover benefits, but it can use a virtual reference station. So when you provide an actual GPS or GNSS coordinate of your location, it uses some math and algorithms to determine based on where you specifically are, it uses a mesh of base stations to give you your corrections.
One of the things that it does require is it does require a network connection to this service, and it's again, based on a surveyors type system. So it may have different outages when you think about it in the environment of connected vehicle and for safety applications, it may when firmware updates or software updates occur for it, there's a need for a backup or a way to cover things. And the other part is that it may not be scalable the way that it is once you start talking hundreds or thousands of connections to it. It's based on having unique surveyor type connections for a few hours to go take survey and then disconnect. Where in the connected vehicle application, it would be an always on connection. And there is a subscription cost though because it's a partner agency, they've been kind enough not to charge DDOT for any of the deployments that we've done for testing. So under this system, this is the N Tripp server configuration. We manage this within the SCM. So you can see that we go in and we have an IP and a port login credentials, and then we have to identify a mount point and we use a virtual reference station. So there's not a lot of parameters that you need to connect or use to connect that. It's more about making sure that you have the network bandwidth and capability.
The second option that we investigate, and we actually have both of these running out in the wild, is to have dedicated base stations, which is another option within the SCM. So rather than be reliant on a network connection to the U GRCs server and trip server, we define our own base station at a cabinet. So we are planning to deploy these, not more than every 10 kilometers is what's needed. And the way we plan to deploy these, we have one of these running out in the field that's been running for a while, there's kind of two approaches you can set the unit up to survey itself in. So under those criteria, you can see in the bottom right, you have to say how long is it going to sit there and watch itself, and what is the level of accuracy that the base station needs to get to in order to survey itself in? And that just basically means that it needs to figure out where exactly it is. The quicker approach. And what we've done in our deployment to date is we've defined where the antenna is of the base station and told it where it is using a high accuracy and a high precision GPS because we're at the site and it speeds up the deployment significantly.
So here's what the onboard processor looks with a dotter board on it that can do GNSS corrections and the offboard OBP. We are using it because the current o bs on the market that we've had experience with and that are under UOC contract don't currently provide those corrections. So this provides us a way to easily manage the GNSS and we can deploy the OBP and on vehicle equipment and get greater accuracy and really validate is can this be done in a connected vehicle environment? And I believe we're one of the first ones in the country that have done this and successfully been able to do it. I will caveat that we're using R TCM 3.2 because that's what the current ENT Tripp server will support. And so we've kind of standardized on that platform. Just to provide a little bit of background as we go through this validation of the GNSS, you can see here that on this is using a tool made by U Blocks called U Center where we can see the different satellites in the sky and we can make an end Tripp connection.
You can almost make it out down to the bottom. We have a connection to the ryp server. And just to provide some idea, this is showing a 2.2 meter accuracy on the top. And then once we have that end Tripp connection, we're down to 0.02 meter accuracy, which would be two centimeters. And you can see that it's showing we have the DG NSS, which is the differential GNSS, and we have a fixed connection. So those are kind of some of the elements of the correction. The result is, and Ralph shared this last webinar, but you can see the blue line is A-D-G-N-S-S logged path. You can see that it's in the center lane, that it's nice and clear, and the red line, which is from an uncorrected OBU with a native GNSS is off to the right and shifted. And we made some circular loops through an intersection, and at some point we ended up being a whole lane off with the uncorrected GNSS feed versus the corrected or differential GNSS feed. So I know there's a lot of content there. You're welcome to watch the webinar over again or reach out to me with any questions. Appreciate
Muriel Solil:
Fantastic. Thank you so much, Johnny. We will now turn to our next presenter, Michael Sheffield. Michael Sheffield is a transportation engineering consultant who specializes in the connected and automated vehicle industry. He is passionate about leveraging emerging technologies to improve safety and mobility, and is involved in Utah's V two X planning, deployment, and evaluation. When Michael is not evaluating the impacted connected vehicles, he can be found with his family working on the ranch or playing pickleball, which is pretty big here in Utah. So Michael, with that, if you're not playing pickleball right now, I'd love to hear from you in your presentation. Take it away.
Michael Sheffield:
Thank you. I'm here. I'm here all, let me pull up my presentation. Okay. Well, it's a true joy to participate in this innovative deployment and to be part of this revolutionary work that UDOT is doing. It's pretty neat to see and know that we're just scratching the surface of what's possible with this technology. As previously mentioned, this is a connected vehicle technology for transit signal priority and preemption. I'm Michael Sheffield. I work with WCG Wall Consultant Group here in Utah. And with this deployment, the advanced transportation congestion management technology deployment, that DI just want to highlight the deployment aspect. For this part of the grant, we deployed transit signal priority and preemption applications, the goals of which are to optimize transit performance, improve safety, improve mobility, and reduce traffic congestion. Now each of these applications had their own objectives or TSP. Our objective was to expand our existing TSP system and deploy along Route eight 50 and equip an additional 34 buses with the preemption.
It was deployed along four corridors and on 20 additional snowplows, here's a map of both the TSP and preemption routes. For reference, the dotted purple line is Route eight 50 where TSP is enabled, and the green are the preemption routes where the plows go. So for Route eight 50, just a little background details, it's about 18 and a half miles long. It travels along one of the primary major arterials in the area, and it's an alternative north south route to the adjacent parallel interstate I 15. It can be quite congestion, have lots of traffic that a DT along along route eight 50 varies from 15,000 all the way up to 50, so quite a bit of traffic and movement there. The bus route operates at 15 minute headways, which is about 62 trips per direction per day. And the average daily ridership is about 2,400 with the snowplow preemption. In total, it's about 31 additional miles with these high priority corridors targeted. These are some of the heaviest traveled highest volume roads in the area. And these were the ones that the UDOT maintenance team identified as priorities.
With preemption, it's a little different and how that gets enabled and set up with the signal controller, not the intersection with TSP with transit signal priority, however, it's a little bit different and it has to be decided how much green time can be allowed when TSP is requested and served. So UDOT developed a guidebook, some guidelines for how to do this. In the past, there was a lot of manual effort. It was really subjective, but these guidelines help the signal engineers do this in a way that isn't quite so time consuming and helps them in this process. It's important to note however, that this is just, it's a guideline to support engineering judgment when implementing TSP. This isn't a UDOT policy. This isn't what has to be done. This is just a way to help the signal engineer. The goal is to provide as much green time as possible to these buses. We recognize the importance that they have in the transportation network and how if they can improve their performance, improve their travel time and their schedule adherence, that they'll become more attractive alternatives. So we want to provide as much green time as possible, but be careful so that the conflicting phases, the ones where green time is taken from to provide the bus that these conflicting phases are able to recover within a few cycles.
And a lot of the input into this was to use actual intersection performance data. We want to know how the intersection actually performs and base the amount of green time for TSP on that real performance. So we turn to the A-T-S-P-M split monitor report, the automated traffic signal performance measures. And this split monitor report was used partly because it's available at nearly all intersections where we have the detection and have that integrated. And also because that split monitor report summarizes why phases end, do they force off, meaning there's so much demand that it finally gets to a point where they have to force it off and go to the next phase. Does it gap out, meaning there's a lull in demand and it does not need the entire time programmed in the controller? Or does it skip? Maybe there are no vehicles, and that's often seen in left turn lanes where if there's not vehicles in that left turn lane, there's no need to give it the green arrow if there aren't cars. So the data that went into this process was from the existing timing plans, the split time and the min time, meaning the min green plus yellow plus red. And then from the split monitor report, these remaining five values were obtained.
The 85th and 50th percentile splits, meaning how long did the phase last, what was the 85th percentile of that duration, and then the percentage of time that a given phase was forced off, gapped out or skipped. And there's the split time, the duration of each phase. The intent is that phases that are under capacity that are gapping out or skipping more often that greater adjustments can be made. And more TSP allowed and phases over capacity would receive smaller adjustments that just will minimize the negative impacts to the cross streets, minimize the disruptions while still being able to provide the buses with extra time.
We're going to walk through a decision tree that helps us calculate exactly how much time is recommended for TSP. With a couple definitions here. TSP max means the max amount of time that a phase can be shortened when serving TSP, the acronym ps you'll see as program split and then mid time the minimum green plus yellow plus red for each phase. So starting on the left, is it okay to modify signal timing at this intersection? Yes or no? There are cases where we may not want to modify timing. Maybe an intersection off ramp, a backup of a queue is acceptable of course. But if that queue is backing up onto the main line of the freeway, caution should be observed. But if it is okay to modify signal timing at intersection, you collect the data from the split monitor report and other sources. And then the question is, are skips greater than 70%? In other words, is the phase being skipped 70% or more? If yes, then it's basically the maximum possible. And you take the phase split, excuse me, the program split minus the mid time. And that is how much that this phase is recommended to be shortened.
If skips are not greater than 70%, then we start looking at the force offs and we will. And if force offs are less than 40%, then there's an equation here where you take the min time, the average between the min time and the 50th percentile split, and use that to calculate how much the space can be shortened. And then alternatively, if force officers are less than 60% or less than 80% are also part of this decision tree. Now if force offs are not less than 80%, then the recommendation is to not allow this phase to be adjusted for TSP. And again, these are just simple recommendations to help streamline what the signal engineer does when actually implementing this. These are just guidelines. The signal engineers, they know the signals, they know the networks, they certainly have the expertise and can exercise that judgment and deviating from this and are encouraged to do so as they see fit.
So this is done for each phase. So the TSP max is that final calculation. How much can this phase be shortened? And for all the conflicting phases, you can kind of add it up in a certain way and then you're left with how much green time is allowed for the bus, the maximum allowable time. So for Route eight 50, the evaluating transit signal priority was first done through OTP or on-time performance. The evaluation took in the bus a DL data from January 1st, 2022 through June 30th, 2023. There are of course a few confounding factors worth mentioning. There were a few schedule changes to Route eight 50. During this time, utas continually fine tuning their schedule to enhance performance and make sure that the routes run smoothly and connect to other routes as needed, especially some of the major ones like the front runner that Route eight 50 crosses.
Unfortunately, for the first part of this, there was no TSP at half of the intersections. The signal controllers weren't configured properly. And this has since been fixed just about a month ago. But this was fixed after this evaluation was begun. So what we're looking at here will just be where TSP is working at half the intersections. This chart shows the on-time performance for these three different scenarios for 2022 before TSP was deployed. And then in 2023, we had two different classes of buses, buses that were equipped and able to request TSP. And then there were still some buses that were operating on the route that were not equipped with the onboard equipment to make that request. And if you just look at the overall three bars on the right, that baseline, the 2022 baseline before TSP was deployed Route eight 50 experienced on-time performance of 86.9%.
In 2023 after deployment, the equipped buses saw 1.3% improvement and the not equipped buses lowered their on time performance down 1.5. So it was important for us to see that difference to kind of have that control group of the not equipped buses to provide additional insights. So the equipped versus not equipped. In 2023, the equipped buses requesting TSP were on time. It was 2.7% higher. And again, this is just with half of these intersections being allowed to enable to serve TSP, we expect that this improvement will increase now that all the intersections are properly configured.
And when we look at travel time, this is the total route travel time. So from when a bus begins to when it ends, and on average, this is the chart that shows the comparison versus northbound southbound. And then overall, and here is even more so important to recognize that the difference in 2023 between the equipped and not equipped and being able to have that control group there. If you just look at 2022 versus 2023, you quit just the blue versus the green, you've see an improvement of 0.1 minutes about six seconds in total travel time. And that would understandably may not be the expected benefit or a worthwhile meaningful benefit, but there was obviously something inherently different in 2023. Maybe it was increased ridership, increased congestion, something else caused the total travel time to be worse, which is readily apparent with these not equipped buses. It's a two and a half minute difference and directly comparing the equipped and not equipped the equipped buses were 2.4 minutes faster. So that's quite a bit as you're a rider on transit, a passenger that adds up and is certainly a meaningful improvement. Again, we expect this travel time to improve and especially the percentage of not equipped buses will be going down as additional deployments are installed.
Some of the lessons learned just briefly is that post-deployment system monitoring is critical. Even if you've done it before, we've deployed TSP on several routes before and we kind of thought we had the process down and it was through looking at it in additional details where we were able to see that, well yeah, it's not quite working as expected at some of those intersections and we're able to fix that. Also, noting that the experiment design isn't perfect, real life operational differences pre and post-deployment exist. This isn't a simulation where you can control every single variable except the one you want to change.
And that the control group, those unequipped buses in 2023 helped us account for some of those confounding factors and identify in 2023 what the difference is between those equipped and not equipped. Something that wouldn't have been apparent if every single bus in 2023 were equipped. And finally that meaningful transit improvements are observed and these vary by route. These findings don't match routes where we've previously deployed, but in all cases meaningful improvements were observed. And while some of the long-term benefits of connected vehicles, while we're waiting for that, these are tangible, real benefits that can be provided to our transportation system. So thank you.
Muriel Solil
Thank you Michael. I love that the real benefits that can be provided to a transportation system. Speaking of benefits, we have our next presenter, Renee Philip, we'll talk a little bit about those as well. So Renee is currently a quantitative researcher serving Panasonic smart mobility office. In this role, she works to quantify the impact of connected vehicle technology on roadway safety and mobility. Her professional career has primarily focused on leading research and analytics projects across various industries including state government, like right here in Utah, electric utilities and transportation. So with that we'll kick it to Renee for her presentation.
Renee Philip:
Thank you so much Muriel. Also we'll just get set up here with the screen share. Just a moment. Alright, so I want to continue on the track, as Muriel said, of talking about how we're measuring the benefits of connected intersections. Michael just gave a great overview of some outcomes as it relates to schedule reliability and transit or travel time for TSP or transit buses, but I want to turn our attention to air quality and more specifically some interim metrics that we're looking at that will ultimately speak to air quality. But before I do that, I'm going to just give you a brief overview of connected vehicles and the data that's related to that because what I'm going to talk about is kind of heavy on data and metrics. So with that, many of you are probably aware, I've heard in our prior webinars that cars today are very dependent on internal computers and data and they are processing hundreds of parameters that really speak to vehicle health as well as status and operations.
And some of those status and operations are what you see here on the screen. Now, about 10 to 15 years ago, this was something that was really afforded to luxury vehicles, but today most cars and new cars that are coming off a lot are able to process this type of information. And cars today are also increasingly able to send out this data to others so it can give information about what's happening in and around their location. Now what makes this possible is vehicle to everything communication or via BV two X for short. And this is essentially standards that define message types and data elements that basically ensure interoperability across auto manufacturers so that if you have a GM or a board, they're all speaking the same language. And here are just a few of the big organizations that are really involved in implementing those standards for B two X communications.
And off to the right, there are a few different technical documents that outline these standards and data definitions and message types. And I want to point your attention to SAEJ 27 35. There's a lot of great detail in there and where I really want to take our attention today as it relates to data standards around data for connected traffic intersections. So to do that, I want to start out with a visual aid of a digital, well actually it's a digital representation of a traffic intersection on the current Utah deployment. And this is particularly located in Orum City along a transit bus route. And what you see here is a looped video. This was from last week, so this is not live, but of a transit bus that is traversing an intersection and as it's traversing that intersection, it is making a request for a signal priority to traverse that intersection more quickly.
Now this is currently visualized in our connected intersection manager application in the series pipe Panasonic product and Connected intersection manager essentially allows users to monitor their connected intersection applications as well as related hardware devices that are installed in the field. And first and foremost, what makes this possible is not only an awesome team of software engineers, cloud engineers, product designers, product managers, owners, I could go on and on, but really the crux of this is a lot of that B two X data and you've heard about up to this point, but I'm going to go in detail one by one just to describe it for you from this digital footprint. So let's start out again with just an overview of that map data. Map data is a digital representation of an intersection. So what you'll see contained in this map message or map data is information that characterizes an intersection.
So we can start out with something like an ingress lane or an inbound lane into the intersection and that's depicted here in pink. We also have egress lanes where you may exit the intersection and that's here in purple. And then also we have other features of an intersection like a crosswalk or a bike lane. And then we can also infer where a conflict zone is within this intersection. And that's going to be in very lay terms that box there in the center. So what's really important about map messages and what's contained in allows us to make this digital footprint is that we have data elements that speak to a reference point and nodes that come off that reference point that speak to a distance. So we can start to build out these polygons again and make this digital footprint that you see here. And this map message is also very critical for a lot of the connected intersection features that we'll talk a little bit more about today. So diving a little bit deeper, what's visualized here is also BSM data. BSM data, just as a recap is showing what's happening in a vehicle on the roadway. So that may be things like are the headlights on or is traction control activated? But as Blaine had mentioned earlier, one thing you will not get from BSM data is identifiable information. It is all anonymized and there are great measures that are taken to make sure that you cannot track a vehicle. You'll not know it's been make model owner or even longstanding traversals of where it's going.
Next step. We also have that SRM data or signal request data coming from a vehicle. So as long as we have an eligible vehicle role, so a transit bus in this deployment or an emergency vehicle or a snowplow as it's approaching an intersection, it can make a special request to have that traffic signal phase change to allow it to traverse much more quickly. And there's two ways that can be done in this deployment. You have signal priority, which is essentially a request to shorten a red traffic light or a signal phase or extend the green again so a vehicle can get through. Now this is reserved for transit buses in this deployment we also have requests for signal preemption. This is essentially requesting a little bit more of an immediate change to that signal phase to allow an immediate traversal to happen. And this is reserved mostly for emergency vehicles like fire trucks and ambulances.
But then as you see there as well, snow plow have this privilege as well. So let's back out. We've talked about map data, BSM data and SRM data. I do want to make a side note that some of the data that's contained within A BSM or an SRM is really enriched by canata and can data is considered to be controller area network information. And what's contained in data that can get put into A BSM or SRM is essentially things like what's the gear position of the vehicle? Is it in drive or park or reverse? You may obtain speed data from here as well. And other things like wiper status, and I know wiper status is something that had come up in one of the previous webinars as a data element that can be used to identify other vehicle events that are happening on the roadway maybe as it relates to a weather event.
So you have maybe weather data that's brought in, but you also can couple that with wiper status to maybe infer that it's raining outside. And then the last data message that I want to call out here is spat data. Johnny talked a little bit about this. This stands for signal phase and timing data. It essentially indicates the signal light phase, the color of the light, so green, yellow, red, and then the duration of that if it's green for five seconds, 10 seconds, whatever length of time. And what's really interesting about stat data for this deployment and for some analysis that I'm going to talk about with you in just a moment is we're using this as a way to infer how that signal request message, the SRM, how it was processed, whether it was granted or not granted. So if a bus is approaching an intersection that makes a request to get priority, we'll go look at the SPAC data to say, was there a disruption to that signal phase and timing that would be indicative of that request being granted.
So I'll get into a little bit of details and a subsequent slide to talk through some of the high level logic of what we're doing there. But before I do and kind of proceed, I want to take a pause and quickly pull the audience. So there'll be a question I'll pop up in just a second. But before that does, I want to preface this with, we realize that this is a mixed audience on the call. Not everyone may be traffic engineers familiar with traffic intersections or even traffic signal data, but for those of you who are, we'd love to see your response to this question. And if you again, feel like you don't have any information, feel free to select the last option. But the question is what data do you use most often to determine if there is a timing disruption to a typical signal phase? So again, if that signal phase is typically five seconds green, how would you determine with data if it actually was disrupted and was longer or shorter, would you use spat data? Some of the data I was just describing, might it be A-T-S-P-M data, some other data source or perhaps again, you're just not familiar with traffic signal data.
Interesting. All right, trying to process this in real time. It seems like most people are using A-T-S-P-M data, but that is also tied with not enough familiarity with this information and there is a little bit of familiarity and use of spats. That's awesome to see. And those of you that have selected other 6%, if you would love to share that information with us, if you don't bog down the chat too much, we'd like to hear a little bit more from you of maybe what other data sources you're tapping into to look to signal timing disruptions.
So let's go ahead and move on. Lemme get my clicker back, right? Alright, so we're taking all this data and now let's kind of dive into how are we using it to measure key outcomes for connected intersections. There's a whole host of metrics that we've identified in studies about how we might go forward with measuring those outcomes, but there's a couple that I do want to share with you today. As I alluded to early on and BLA had mentioned at the forefront, this is going to be stuff that is related to air quality. Now air quality is somewhat hard to define. So I do want to say that we are taking interim steps and looking at inputs into air quality. So that is vehicle idling events at intersections. And then we're also taking measurements of or estimates of fuel consumed as it relates to those vehicle idling events.
And the reason for our selection here is really twofold. One, air pollution is a hot topic today and it's something that I think Utah is contending with and we think these are inputs to that. Secondarily, some of this priority preemption activity that is happening at intersections is something that we think potentially could help to reduce air quality or emissions that lead to air quality. So with that, I want to go back to our data elements that we just discussed on that digital representation. And I want to show for you how we link these different message types and data elements to identify certain vehicle events that are happening on the roadway. Again, I'll be talking about vehicle idle, vehicle idle events, and then fuel consumption. So for vehicle idling, how do we identify that Most of the data for this is really coming from BSM data and can data, and I'll throw up here the parameters that we're evaluating.
So first the vehicle needs to be on, it needs to be sending b, sms, it's gear position needs to be in drive, not reverse, not park, but drive. And then also the speed needs to be zero miles per hour. So essentially that car is on, it's in drive and it's not moving. And then we also take the latitude and longitude point for that BSM and we map that to the map data to understand whether or not that idle event is actually happening in the intersection. And we do that by saying whether not that long sits within an ingress lane or an egress lane or a conflict zone. And if it is, it's an idle event in an intersection. And then we also pull in vehicle roll from the SRM data. This is something that is very high level. It'll just tell us if it's a transit bus, snowplow an emergency vehicle, something along those lines.
The reason for this is because for a vehicle to send out that request, we need to know that it's an eligible vehicle. So we do get some identifiable data, but it's nowhere near. I want to make sure that we're clear that it's not, this is still anonymized, we're not able to track. So it doesn't violate any of those standards of what you see for A BSM, but we will use that vehicle role in trying to work the next metric, which is fuel consumption because fuel consumption can vary significantly based on which vehicle we're evaluating. So let's move over to fuel consumption. What we're doing is we're taking that vehicle idle event and we're calculating the duration of it in seconds. So once we know how long a vehicle is idling, then what we layer on top of that is fuel consumption information that we're pulling from the Department of Energy's website.
They've got a nice little table that really provides some rough estimates by vehicle type. How much fuel is used if that vehicle is sitting idle for one hour with no load. So one quick example of this is a transit bus, it has no load and it is idling for one hour. It uses just under one gallon of fuel. So we can easily take that, multiply it by the idle time that we will calculate for the idle events and get to a fuel consumption factor. Alright, so with the events described, I want to briefly go into a description of the data and then show you some of our preliminary findings. So you've seen this chart many, many times. I won't belabor the point, but I do want to use this as an illustration again of the data that's included in this analysis. So again, we're looking at that deployment region for phase two and phase B, which is primarily situated around Orem.
I will zoom in and you can see it includes an 11 square mile area of Orum city proper that's located there in blue. And then also includes some key corridors that extend outside of one to include snowplow routes and transit bus routes. And this is just a quick illustration of some of the vehicles that are traversing this area. There are about 75 public works vehicles that are included in this analysis and that is a mix of snowplows transit buses, emergency vehicles, both ambulances and firetruck. And then we're including about 130 equipped intersections that they could be traversing through or having idle events in. And we're also looking at about a six month period of time that starts with October, 2022 and extends to March, 2023. So really with the beginning of the deployment deploy and then ceasing at an earlier this year. So with that, let me dive into some of the baseline findings that we saw through the analysis.
So starting out with vehicle idling events, there's a little bit going on in this chart, but when I want to point your attention to first is that green vertical bar chart. This represents the number of idle events that were happening each day across that six month period. And as you can see, as the deployment was coming online, the number of idle events was fairly low. But once we hit that final installation date, everything was equipped and outrunning in the field. We saw quite a bit of an uptick in the number of I events. This was just more cars, more vehicles that were out operating on the roadways. And so once we get past this final installation point, we start to see a little bit of a stabilization in the variance across these data values. Where we ended up landing on average with the number of idle events per day was about 1400. Now this did ebb flow, you see some peaks and valleys there. This is really representative of weekday versus weekend activity, but on average it was about 1400 events. And then if we look at the average duration of any one of those events, we are seeing that they lasted about 26 seconds. Again, that was something that tended to stabilize once we got to final installation. So 1400 events and on average they lasted 26 seconds.
Next the team took this information on vehicle idling duration and converted into a fuel consumption factor. So like I said, the number or the average duration of an ILE event is 26 seconds. It's relatively short. And so if you equate that into a fuel consumption factor, it ends up being, let's see, six one thousandths of a gallon consumed very, very small. I stumble over it every time I try to say it. So what we wanted to do was take that to a larger scale to make it something that was a little bit more meaningful. So we ended up estimating that to the daily level. So like I said, there's 1400 idle events that are happening each day in this deployment. So that equals about eight and a half gallons of fuel that's consumed during those vehicle idle events. Again, not a large number, but as this technology scales we get more vehicles out and operating, there's definitely a potential for that fuel consumption factor to go up and it just speaks to a greater potential to start to look at ways that we can mitigate this and reduce it potentially through greater mobility through those intersections via priority or preemption.
Alright, so where do we want to go next with this? We do have intentions and have started on deeper dives into idle and fuel data. We want to look at key segments of what's happening with priority of preemption to basically speak to the efficacy of it in terms of interim measurements of air quality. So the first one that's up is kind of bifurcating the information and looking at is there a difference in idle events, duration of those idle events and fuel consumption for granted requests for priority preemption versus non-grant requests? And we believe there is, but we need to test this with more thorough data. So we're looking at does idle decrease, does that also lead to fuel decrease? And then we think there's a straightforward way, at least as a preliminary stab to convert a lower fuel reduction into an emissions factor. We've been speaking with some industry experts on this front thinking about how we could convert this and it seems like there's an opportunity to at least start out with carbon dioxide emissions to get to an efficacy factor there.
Now one thing I want to return to really quickly. We talked about spat data at the forefront. I asked you how do you look for time disruptions to signal data we are utilizing in this deployment? Well, for these analysis we're looking at spa data and to describe that a little bit more, what we're essentially doing is taking the point in time at which a signal request message is sent out at the intersection, say by a bus, and using that as a starting point and back analyzing 30 minutes to look at what's the average signal phase for that approach and getting a value for there. And then we compare what was the signal phase actually at the point in time at which that bus was making its request. And if we see a variance there of more than five seconds or less than five seconds, we're inferring and making an association or a correlation that there was a disruption and that disruption meant essentially that that request for priority preemption was granted.
So that's our approach today. Two reasons for that. We've got a great data ecosystem that's built out through this deployment. So this is data that's directly available and can be tapped into instantaneously and on the instantaneous route. I want to reemphasize the other benefit here is that it's realtime or near realtime data. So it just opens up a whole host of opportunities whether you want to monitor how this is performing in near real time if you want to productionalize it. But the other benefit here to using near real time data is that you're not necessarily dependent on having to do a manual data pull from another source, but there's pros and cons to each. This is just an avenue of the team's pursuing. We've made a lot of progress here with some iterations and look forward to improving it as we go forward. So with that, I want to conclude quickly with a couple of data learnings.
This is definitely a theme I would like to share with you all. So two categories of these data learnings are data quality considerations and data quantity considerations. So the first one, Michael talked about this, I'll just briefly go over it once more. The team is very vigilant in doing system monitoring, monitoring post deployment, and they observed that some of the signal controllers were misconfigured on one of the key transit bus routes. So this as Michael said, has been corrected and we look forward to re-analyzing some of this data as more time passes. The other quality consideration is the signal disruption logic. As I mentioned, we're using spat messages to infer if there's a signal disruption, but it's not perfect. We realize this, there's always going to be a margin of error when we're talking about inferences. So next steps potentially are to see about bringing in some alternative data like maybe A-T-S-P-M and doing a comparison across comparison to say, are we aligned on our inferences that spat?
We signal that there's something's being granted here, but maybe A-T-S-P-M doesn't say that, or maybe they do align, but Olivia's starting point for us to dive deeper and kind of investigate that and work to improve our logic if it's needed. And then lastly, there are some sample size of data quantity considerations. With the deployment being fairly new, unfortunately there were too few observations to date to do some segments of the data that we had hoped to do. For instance, looking at vehicle idling or fuel consumption for different vehicle types, what does it look like for emergency vehicles versus transit buses or snow snowplows? So hopefully that's something we can look into as the future comes. So with that, I appreciate your time and hearing about where we are with air quality measurements and I'll pass it back to the team. Thank you so much.
Muriel Solil:
Thanks Renee here in Utah with our air quality challenges, that is a key benefit that we see with this type of technology. Speaking of air quality, we have as our last but not least, presenter, Hal Johnson with Utah Transit Authority who has done a lot over his career in helping to improve air quality along Utah's Wasatch Front. Hal Johnson is the acting director of Innovative Mobility at UTA. He has more than 25 years of project management experience in both project development and direct management of procurements and construction. Hal has been leading UTAS efforts for bus electrification, innovative mobility, as well as inner city passenger rail. He holds a master of urban and regional planning from the state University of New York at Albany and a master of arts and geography from the State University of New York in Albany, as well as the Bachelor of science at Urban Planning from the University of Utah. So comes very well experienced and qualified. With that, Hal, we'll kick it to you.
Hal Johnson: 
Hey, there we go. Good afternoon everybody. I'm working at home today. My son was six so I will do my best to get through. I've got a very quick presentation for you all. So lemme pull that up. There we go. Alright, so I'm going to give a quick discussion about utas bus transit signal priority efforts. I did want to recognize my colleague Shana Quinn, who's been really championing utas efforts in this space and she was not able to be here. So I'm making the presentation. So UT is a multimodal system. We have light rail, we have a 50 mile light rail system, a 90 mile Q meter rail system that links our city centers. This map shows our 30 minute and 15 minute bus networks. So the green lines are the 15 minute bus networks. So we're very multimodal system. We try to serve the right transit market with the right tool.
And one of the things that's really important about focusing on bus on the TSP side, as we see our customers on the bus side tend to use the bus more frequently. So they use it for five days a week more often than our rail system. They use it for not only work trips, but they use it for non-work trips. They use it as their primary mode of transportation tend to have lower incomes and more are minorities. So serving, providing more TSP helps with equity. So these are the benefits we see of TSP is really improving reliability of the system and the overall customer experience. So travel time is really important to customers, but reliability is even more important so that you know when the bus is going to be there and it's there when we promise it will be. And generally UTA buses we run about just a little bit less than 90% on time, which is really good for in the transit industry. We've seen studies in other cities where they've seen between eight or four and a 15% increase in travel speed in the corridors reduced time. And then we've done worked with UDOT on the Route two 17, which is our Redwood Road service and we saw pretty significant increases in reliability as well as less schedule availability. We have a couple of bus rapid transit systems. We operate the UVX line and Provo and Orem and our OGX line up in Ogden that use transit signal priority as well.
So just going through some of the other benefits, we're interested in connecting more of our corridors with TSP and I'll show you the corridors we're evaluating looking at right now and increasing the travel speed and improving reliability makes the bus system more attractive for customers. And we see it's really important with our rail system because we have a lot of time transferred connections. So if you're just, and I've experienced that before if you're just getting off the train and seeing your bus not there or the bus even worth leaving the station. So it has some significant benefits for really helping us make those system connections.
And also did want to mention reduced emissions. The less we're idling the buses, the more benefit we have in that space. This is our plan we're working on for TSP over the next five years is a $2.7 million deployment. We are planning to equip all the buses in our fleet and the plan is to, as buses go out of service, as we replace buses, we'll add new buses in that will be factory fitted with the TSP equipment and we'll be able to do that. We generally replace about 10% of our bus fleet every year. So we'll have a campaign to replace ADD TSP on the newer buses and then we'll be replacing buses as it goes.
One of the big benefits that we hope to see from this implementation is in addition to the customer benefits if we can. So a typical route that may be a 10 mile route will have eight to 12 buses out on the system at any one time. So if we can take a bus out of service or remove a bus from the route while maintaining the headways, that's a real significant benefit to the transit agency, both by being able to reduce the capital cost of procuring buses, but as well as we have a difficult time finding operators with the current labor conditions. So kind of the other goals we're working to do is really improve our customer experience, increase the reliability. We're looking at our performance measures garage by garage. We operate buses out of three different garage, four different garages along our inner service area.
So we'll look at kind of how the deployments go in each of the garage and we're doing it in cooperation with UDOT using their traffic signal system. And the current focus is on our bus rapid transit route as well as our core routes. And the core routes are the ones that I showed you earlier that have more than greater than 15 minute service. So these are the routes that we're targeting in 23. So route 33 35, they're one long route connecting east west eight 50 and 200. And then in 24 we're looking at five additional routes. And then 25, 27, we've got seven additional or eight additional routes on the list. And these are all our highest ridership, most productive routes. So these routes on the screen here probably represent 50% of our bus ridership. So improving these routes will be really key to improving the overall bus system.
So the impacts we want to minimize the impacts on cross street traffic have a positive impact on safety and air quality. And one of the big things that's important that we see in Utah is we really have a lot of collaboration and cooperation among the agencies. We have a great partnership with UDOT as well as with the MPOs and our cities and counties. And so we're really fortunate to have such good working relationships to be able to implement this kind of technology in a cooperative way and a benefit for the overall taxpayers and system users. I did want to mention one thing really quickly. The placement of our bus stops is really critical to make TSP. We want to really focus on getting far side stops into the system and the picture on the left is of our Ogden bus rapid transit project. This just opened last month. So that is all of my slides and I'll stop there.
Muriel Solil:
That sounds great. Thank you so much Hal. It's nice to get those additional insights about what UTA is doing in partnership with UDOT. Now we will ask that all of our presenters come back online, so if you want to unmute yourself and turn on your screen, that would be great. I would note we have one additional subject matter expert who is joining us today who didn't present but is here to field any questions that you may have and that is Rob Zimmer. So just out of a brief introduction, Rob has more than 20 years of experience and is an international council on systems engineering certified professional. His experience includes requirements, definitions, allocation and refinement, as well as deployment integration and testing of transportation, commuting and communications platforms, network hardware, vehicle sensor platforms, et cetera. Rob has military great experience and commercial verification and validation. So Rob, thank you so much for joining us as well. Let's get to some of these questions that our attendees had. I would say to our attendees, please feel free if you haven't asked your question and still would like to do so. Drop that in the chat. The first is about costs. I'll kick this to you. What are the costs involved in managing the message security? Something that you had presented about earlier in the webinar that comes from an anonymous attendee. We also have a question on costs involved with the TSP and managing the roadside equipment and intersections.
Rob Zimmer:
So thank you Muriel. And for those two good questions, I will note that we've got a whole bunch of really great questions that have come in and I doubt we'll get through all of them. I'm sorry for that. As Muriel indicated earlier, we'll post the answers to these questions when we post the presentations and we'll try to keep in touch with all of you because we'd love to answer all of these questions. Muriel has started with a couple of really hard ones and I wish I could give you really good answers for these two really good questions, but I can't. So there's a couple of reasons for that. As I indicated in one of my slides, the management of this system, we realized as we jumped into it and built it really involves a couple of different groups and we have not done a good job of really sort of capturing all of the effort that's involved in managing and maintaining these systems.
I can tell you that for security certificates, sort of the nominal cost of managing of having certificates on a roadside units is about 60 to $70 a year per device. Onboard units are a little less than that, but that's just the cost of the certificates. You need a contract with the certificate provider and there are some other options you can get from that certificate provider, like a dashboard and a portal to monitor the status of the certificates on all of your devices. And there are extra annual costs involved with those. The installation of the certificates on our individual devices has been sort of buried in with all of the other integration items. And so unfortunately I don't have a really good succinct cost for that. We are working hard to try to figure out what the best way is to manage our deployed network of hardware and software and trying to get our arms around that so we can look to the future for sort of an annualized cost.
And even though we've been at this for about eight years, frankly our system isn't mature enough or well managed enough from a comprehensive standpoint for me to be able to put a number on that. I know that's a lot of words about a non-answer and I'm sorry for that, but we don't have a good succinct answer for that. I think what you can do, and I keep going on here in limited time, think about what it costs you to maintain a traffic signal system. And I think this is a little more intense than that because of the nature of the software. So if you can quantify what your agency spends to manage and maintain a traffic signal system, this will be a little higher than that per unit.
Muriel Solil:
Thank you Blaine. I liked that. 2 cents. He got my joke. Okay.
Blaine Leonard:
This question Michael, I think you'd be good to answer this one. Do different cities in Utah all have CV technology for TSP or does UT and Hal feel free to weigh in here as well? Have to support different TSP technologies and the attendees asking about cloud-based on buses and also C-V-O-B-U compete with CAD and A VL for the J 1939 port on a bus. So kind of two slightly different questions. One about TSP technologies and then also about whether or not the OBU competes for the A VL on a bus.
Hal:
I'll kick this to how he knows, he knows about this and can respond appropriately, but we did just convert an older TSP technology and we're in the process of converting it to B two X and that was the only other operable TSP system. But I'll see how has additional comment.
Hal Johnson:
Yeah, maybe I'll hopefully understand the question. So typically our buses have multiple GPS units running on 'em and so we just tie into one GPS unit because there's multiple things that are using GPS. So the other piece of the question is going forward, we're planning to just factory fit this equipment so it'll be built into the base design of the bus, but we're able to add it to the bus now with our existing equipment.
Blaine Leonard:
Well let me weigh in with a couple of quick comments UT a's service area covers most of the northern Utah populated area and they are the largest transit network in the state. There are a couple of others around in far northern Utah and southern Utah and in Park City, but UTA is the largest we know of no other transit signal priority systems in place in Utah today other than the one we have running with UTA. And there are cities who have a VL based emergency vehicle preemption or for fire engines. Many of those are sort of older. We don't have a good handle on how many of those there are and some of the ones that exist aren't really operational today. We don't think that our OBU based transit signal priority system will interfere with an AVL based transit signal priority system at the signal cabinet. We've had some discussions about that and don't think there's a conflict there, but we don't have a large base of knowledge to make that judgment from.
Muriel Solil:
Thank you Blaine. The next question comes from Steve Vanko and Rob, you beat me to the punch in answering it, but I think this is a question that a lot of our folks will have. So I'm going to ask it and then kick it to you and Renee to answer. So Steve asks, how are the vehicles indicating if they want priority versus preemption? And if they're not explicitly requesting this, how is it determined?
Rob Zimmer:
Yeah, I can talk about this at a high level then maybe pass it to Johnny who touched on this in his presentation. So the vehicle itself does not ask for, I want priority or I want preemption when it forms a signal request message signs that message with an appropriate security certificate and sends it is asking for service at the intersection. That message includes a roll and sometimes a sub roll for what the vehicle's doing. It might be a transit indicator or emergency vehicle or DOT, which is what we use for snowplow. It's then up to the signal controller system itself to determine what kind of service to provide based on that role so the local jurisdiction can make decisions how they want to handle that. Johnny, do you want to talk about, maybe refresh on how that's processed on the intersection?
Johnny Turner:
Yeah, as Rob mentioned, there's the role in sub role of the vehicle. And so that's defined on the vehicle either in the OBU natively or in the onboard processor where that's been defined. And then as that signal request message comes in at the roadside, that can be processed based on that. So in the SCM, which is what we do here in Utah, we receive that message and we look at how that vehicle's been defined or what privileges it gets at the intersection, again based on that lane mapping. So what's the output going to do? Is it going to request preemption or is it going to request priority? But that decision is wholly made at the roadside and not buy the vehicle. Technically you could add some different sub rolls under the standard and do some permutations so that an ambulance running a certain light bar set could request priority in a separate light bar set. Could request preemption potentially, but we haven't delved into that at all. But there are some games that could be played with the sub roles.
Blaine Leonard:
Thank you for clarifying. We'll now move to Renee. We're going to give each one of you about 30 seconds to provide some parting remarks and words of advice to our attendees. I would reiterate what Blaine said that we will follow up with you if you've asked a question and we haven't had time to answer it during the webinar. We'll provide those answers directly to you and we'll also post them on our website because if you have that question, guarantee others will as well. So some parting thoughts starting first with Renee, then going to Rob, Johnny, Hal, Michael and Blaine.
Renee:
Yeah, so just very quickly, data analysis as Blaine said, is very difficult and this is quite voluminous and complex data. And so really lending on a team and a group of subject matter experts to help understand what's going on is really critical. And every individual that's on this call has been a participant in helping understand some of these air quality outcomes that I spoke about.
Rob Zimmer:
I'll just say that I want to echo something that's been said at this webinar that this is hard. The data is complicated and voluminous, but the benefits are there. We've seen the benefits of this and it's worthwhile starting. I love Blaine's mantra that he's saying is get started. And that's the only way you can really understand and realize the challenge, but also the opportunity and the opportunity really is there to understand what's happening at the intersection to provide services that benefit the public in multiple ways. So I encourage everyone to give it a shot. V two X is a capable technology that has multiple use cases that you can accomplish, including the transit signal priority, snowplow, preemption that we're doing in Utah.
Johnny Turner:
Great. And I really want to echo those comments. It is hard, but you can make it through. The support network is there. It's a lot better than it was eight years ago and the technology's much, much further along than it was eight years ago and just go after it and jump in with both feet.
Hal:
I, so I would emphasize two points. Partnerships are really key in implementing any of these kind of solutions and we're very grateful for our work with UDOT and this team. And then last piece is there's people behind it. So there's customers are using the system every single day and there's a benefit to our end user, the more reliable and the faster we can operate our offices.
Speaker 5:
Thank you. And it's exciting just to think about the future possibilities and recognizing that this is not the end goal, but it's what we've started with. It's a benefit that's real achievable and is just a stepping stone to the greater safety benefits that are forthcoming.
Blaine Leonard:
Thank you. Those were all some really great closing comments. I saw a LinkedIn post this week from Laura Chase who is the CEO of ITS America, and she's posted this same sort of message a couple of times in the last couple of weeks and referring to V two X communication, she said, we've been talking about this for a long, long time. It's here, it's time to just go do it. And that's our takeaway. I think it's time for all of us to just go do it. There are benefits there. We need to jump in, get our hands dirty and get it done. Thanks for joining us today.
Muriel:
With that, we'll leave it there. Thank you so much. We'll be in touch. Take care.