This is the second half of my presentation to the National Rural ITS conference earlier this month. Due to the length of my presentation is it much longer than my regular posts. So I apologize in advance but hope you enjoy it.
There are more issues to consider when gathering data:
1) Choose sensors that meet your needs. Side fire radars like Wavetronix are great if you need lane by lane speeds and volumes. But most of the time speeds alone will tell you what you need to know, in which case standard k-band radar will work just fine. And those cost thousands less. So from a budget standpoint a lower cost per unit could mean many more sensors and much finer data resolution.
2) Simple is also better when the work is staged or moving. Side fire sensors must be moved and re-calibrated by a qualified technician. My people know how to do that for you, but it means another trip to the jobsite and another invoice for our time. K-band is more forgiving and often can be relocated by laborers on the job.
3) For queue warning or dynamic merge always place the sensor farthest up stream well beyond the point at which you expect queuing to extend. That is your emergency sensor. If it trips, you will know it’s time to move your construction area signs and message signs farther out from the job.
4) Frequency of polling. The server where the system software resides and where the data is stored, calls each device on a regular schedule and that is called polling. For travel or delay time systems, you want to smooth the data and more data points give you a more accurate picture. So you should poll every 5 minutes or so. For critical warning systems like queue warning or dynamic merge, most systems trip as soon as the average speed drops below the trigger level, then run until they have been above that level for a few minutes. But if that’s not how your system works, you should poll a minimum of every 2 minutes.
The best metrics for work zone ITS will still vary with the agency, by location, by road classification, and by the type of construction activity. There will even be times when surprises on the job will force you to adapt and take what you can get. So you need to remain flexible as best you can. Try to build a system that can accommodate different types of data, different formats, and incomplete data. As you build up a history, this will still allow you to draw conclusions, even when you get less than perfect data from each project.
Talk to your vendors. Ask them to export the data in a format that fits what you are already doing. Then it is a simple process of copying and pasting it to your data base. Most are more than happy to work with you in that way.
Consider categorizing or tagging your data in several different ways: construction activity, type of facility, traffic volumes (low, medium, high), project goals (reduced crashes, improved efficiency, etc.), and type(s) of traffic control (lane merges, lane shifts, width restrictions, use of barrier, alternate route availability, etc.)
Begin comparing data from similar projects. Do this early and often. Even if you only have two similar projects, there will be lessons to be learned by comparing them. Look for trends and outliers. What worked in terms of staging, of traffic control, and for the work zone ITS system itself? What did not work? What did you wish the system provided that it did not? What data do you find you use most?
Once you do this you will have a much better understanding of the value of these work zone ITS systems. In many ways, this is data we have not had before. We know it is valuable, but because it is new to us, we have not yet learned all of the ways in which we can use it. The standard reports provided by your vendor are often helpful. But only when you examine the data yourself will you truly see the possibilities.
As you gather more and more data from different projects, you will learn things about your traffic control, too. You might learn how best to stage certain types of construction or how to better design your work zones. Your work zones will become safer as a result.
I hope I have convinced you to make better use of your work zone ITS data. But what about states where work zone ITS is not standard practice? You can’t analyze data you don’t have. You have to use these systems first. What can you do about that? Many states don’t want to go through the process of developing specifications and contract language, especially since they aren’t yet experienced with these systems. It’s a chicken and egg sort of problem. You don’t include work zone ITS because you don’t fully understand it, but you will never understand it, until you have deployed a few systems.
We have that problem in my area. Both California and Oregon have written a high level, generic automated work zone information system spec in the hopes of seeing these systems used more often. The idea was for project design folks to then specify the type and quantity of devices for each project. But it hasn’t worked. In fact, neither state has let a single project with work zone ITS as a line item.
I’ve learned that construction design doesn’t know about work zone ITS so they aren’t able to fill in the details. They don’t know how many sensors are needed or how far apart to space them. They have never been through the scenario process where you decide that if traffic slows at this location, change these two message boards to warn of slow traffic ahead. When you think about it, it’s really not surprising that this approach has not worked.
The answer to this problem is individual system specifications: one for queue warning, another for travel time systems, dynamic merge, trucks entering/ exiting, etc. They include the types of devices needed and often include the quantities as well. Each is ready to plug into project special provisions. The design team doesn’t need to know how they work. All they need to know is that they expect a problem, such as dynamic queuing, so a queue warning system should be included.
Speaking of queue warning systems, that is the first specification you should create. 26% of all work zone fatalities are a result of end of queue crashes. And as we will soon discuss, queue warning systems are a proven countermeasure. Best of all, the states of Texas and Illinois have already done the work for you. Texas Transportation Institute created a simple, easy to use contracting method and Illinois has adopted it and improved on it. Several other states are now following their examples.
In both cases the states let a separate contract by district for a daily, weekly and monthly rate to supply queue warning systems. Texas breaks it down to two different packages: a smaller one and a larger one. The smaller system includes 4 sensors and 1 portable changeable message sign. The larger system includes 8 sensors and 2 message signs. TTI looks at volumes and planned lane closures and then calls out the appropriate system for each night’s work.
Illinois breaks it down further. They have separate line items for sensors and for message signs by day, week and month. They then call out the quantity of each device they will need to handle the expected queue lengths.
In both states the ITS work is not tied to a specific project. Rather, it is separate so they could use these systems on two projects one day, and three other projects the following day. It is not tied to construction, so they can also use them for incident response or special events. There are no minimums so the states decide when and where the systems are needed. It also motivates the contractor to do a great job so the state will call them out more often.
Texas Transportation Institute has been doing this for a couple of years now. They just released a study in partnership with FHWA focused on queue warning systems. TTI reported that at the time the report was prepared, the system had been deployed on over 200 nighttime lane closures in the I-35 corridor. They compared the crash experiences at lane closures where queues were expected but no system was used to lane closures where the system was deployed. Although the study is not complete, the data suggest that the systems are being very effective.
Crashes on nights where lane closures are deployed with an end-of-queue warning system are 45 percent lower than they would have been if the systems had not been deployed. 45 percent! TTI estimated that the systems saved between $1.4 million and $1.8 million in societal crash costs so far, and continue to be used as needed on the projects, further increasing their return on investment. Stated another way, it appears that the system reduces expected crash costs between $6,600 and $10,000 every night it is deployed!
We have always known queue warning systems save lives. But, until now, we have not had definitive data. Now it is proven. Yes, the actual numbers may vary slightly once they reach a point of statistical significance. But the results are so positive that it doesn’t matter. It’s no longer a question of whether you should use these systems. Now the question is, “Why aren’t you using them everywhere you expect frequent, dynamic queuing?”
None of the old excuses hold water now. The systems are proven not just effective, but phenomenally effective. And, the Texas/Illinois model for contracting this work is approved by FHWA and is reimbursable under HSIP at 90%. So there is no reason to hold back now. Get these systems going in your state. Collect the data. Archive it. And then begin reaping the many new lessons learned from that wealth of data. Once you have done that for a year or two, please come back here and share what you have learned with the rest of us.