Work Zone ITS – The Next Step (part 2)

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.

Work Zone ITS – The Next Step

On August 10th I spoke at the National Rural ITS conference at the Snowbird Resort in Utah. My goal was to push the audience to make better use of their work zone ITS data. Due to the length of my presentation I have broken it into two parts. But it is still much longer than my regular posts so I apologize in advance. I hope you enjoy it.

———————————

Thank you all for this opportunity to speak with you today. For those of you that don’t know me, I have been in the work zone ITS business for nearly 20 years. I started in the industry with ADDCO where I first learned about networking portable equipment to improve work zone safety. In 2001 I started Road-Tech to focus on this new and growing field of work zone ITS. But 20 years! It’s difficult to believe, isn’t it?

The primary goal of work zone ITS has always been improved safety and system efficiency, as it should be. But by deploying these systems we are now generating a great deal of data. It is time we began making better use of that data: both today and in the future.

This morning we will talk about data: about different kinds of data, and what works and what does not. We will talk about how best to collect that data and ways it can be used to improve the safety and efficiency of our work zones. We will talk about a new and innovative way to contract this work and, best of all, how to pay for it. Finally, I will share the exciting results of a recently released study proving the effectiveness of these systems. I want you to leave this session fired up about making better use of these systems, and knowing how to get that done.

So, why collect data? There are at least three reasons: 1) The Federal Work Zone Safety & Mobility Rule says we must collect data on our work zones and use it to evaluate their performance. In fact, the HSIP final rule describing these requirements will be published any day now. [ADD DETAIL AFTER FINAL RULE?]

2) By looking carefully at the data from current systems, we can find ways to make better use of the systems we are already using. They are like any other tool. When you fully understand its capabilities, you will make better use of it. This will result in even more improvements in the safety & efficiency of our roadways, and will make better use of our limited resources.

3) By learning more about the data generated, we learn more about the systems themselves and which ones work best in varying applications. Each manufacturer has their particular strengths and weaknesses. The easiest way to see those is through an examination of the data. This will make you better at defining what you need and want from systems on future projects.

But before you do, three things must happen:
1) You must have the right kinds of data…information you can use. In most cases this comes in the form of a log. The log will show reported speeds at each sensor with date and time stamps. It will show when a message sign was changed and what data triggered it.

2) You must collect it and hold onto it. And you must systematically categorize it for later analysis. There are data base programs available. Microsoft Access or something similar works well. But you could start with a simple spreadsheet and use that until you find you have outgrown it.

3) You must get to know your data, what affects it and how. We will talk about this in more detail later, but I will give you a simple example. On a queue warning system deployment, Caltrans noticed the message signs changing to warn of slow traffic early in the morning while volumes were quite low. They looked at the data and saw that one sensor was reporting stopped traffic while speeds at the other sensors were at the posted speed. They checked the job and found that the contractor was paving in that area and their trucks and rollers were the slow traffic. They relocated the sensor and the problem was solved.

So let us begin with data. Which data should we use? What works best and is most available? I spoke at a peer-to-peer exchange a couple of years ago about this very subject. At that time I asked far more questions than I answered. I think they were a little disappointed. But today the answers to those questions are more apparent. The list you settle on will include obvious metrics like traffic speeds and volumes, serious crashes, and perhaps delay time or queue length. Those are all measurable and reportable and are good indicators of conditions in your work zones.

You might also consider less obvious measures such as speed variance when speeding is a problem or volume reductions through the work area if your goal for the project was to divert traffic onto alternate routes.

There are several things you should consider when making these decisions. Let’s go through them one at a time.

1) Real time data versus collected data. This is obvious but bears discussion. Real time data is used to monitor current work zone performance and to trigger messages and other responses to changing conditions. Collected data is used later to evaluate work zone design, staging, and to plan future work zones in similar situations. Ideally the data you collect will work for both. But the needs for each will vary so be sure to check that all of your data needs will be met.
2) Project level data versus system performance data. The real data wonks in most agencies are accustomed to using system performance data. They want to know how well traffic flows over a single route or at a regional level. System data might tell us there was a problem in our work zone, but it would not tell us where. We need much more detailed, granular data so we can know what is occurring in and near our work zones. This is important because those systems operations folks will probably be leading any data collection effort. They are great advocates for data collection, but they don’t understand work zones. You must help them understand why you need something different.
3) Probe Data versus Spot Data. This is related to the last topic of project data versus operations data. Many agencies are knee deep in probe data. It is collected anonymously from cell phones, toll tags and BlueTooth. Cell phone data, in particular, is relatively inexpensive and easy to get. It is collected and displayed over a road segment. Some segments are as little as a couple of miles long but most are much longer. You may get lucky and find a segment covers the same stretch of road as a work zone, but not very often. So you end up with two or more segments overlapping your work zone or a single segment that’s much longer than you need. Warnings of slow or stopped traffic are only generated by probe data once average speeds over that segment drop below the trigger point. In other words, if you are only using probe data you may not learn about the incident for several minutes. Furthermore, probe data only tells you there is a problem. It won’t tell you where the problem begins. Spot data, on the other hand, tells you the moment speeds slow at a sensor. And because you have multiple sensors, you will know where in your work zone the problem begins.
4) The importance of “raw” data. The advantage of work zone ITS systems is the automation of responses to changing conditions. In that way we update message signs, send text alerts, etc. to warn of incidents and thereby reduce their impacts. It all happens instantly, without the need for human involvement. That’s great, don’t change a thing. But take the time later to look at the underlying data. When you have an incident, go back and look at what happened, when it happened, and where it happened. Compare the data to the outputs to learn how the system responded. I’ve always said that deploying these systems is 90% science and 10% art. The art comes from looking at the data and making adjustments to get the best possible performance from the ITS system.
5) The Importance of Multiple Data Points. One spot sensor might be all you need if you are worried about traffic backing up on an off ramp, or for a trucks entering system. But most of the time you need multiple sensors. For queue warning we recommend spacing them a mile to as little as a half mile apart. The smaller the distance between them, the faster you will learn of any problems. That means you will respond faster resulting in shorter delays, and fewer secondary crashes. For travel or delay time systems, more data points result in more accurate reporting.

Choosing the Best Portable Traffic Sensor

Technology has supplied our industry with a wide variety of traffic sensors. Each has its own set of advantages and disadvantages. Which one is best for your application? This may seem complicated at first, but the answers to a few simple questions will point you in the right direction.

First, please remember these are portable sensors. Ordinarily that means they should run off of 12 volt power, lending them to solar and/or battery power. They should have minimal power requirements, so they will run for an extended period of time without maintenance. And they should be easy to set-up and move around. Conditions on high way projects are constantly changing, so it must be easy to move the sensors to meet those changing conditions.

Next, think about the system to which these sensors will supply data. What data is needed? How often is it needed? How accurate must it be?

Queue warning systems just need speeds. So doplar radar works well and it is inexpensive. Doplar also works better at very low speeds. Microwave sensors provide additional data, but they are more expensive and don’t work as well below 20 MPH. Dynamic merge systems, like queue warning systems, just need average speeds. So doplar is best.

Travel time or delay time systems can be designed in a variety of ways. If most of the traffic continues on that route and doesn’t stop for any reason, probe data may work. Check the way it is reported in that location. They report speeds or travel times over a road segment. If that segment or segments match the route you want to watch, it should work well. However, if the segments don’t match up or if much of the traffic turns off or stops along the way, you will have to look at other options. One option is other forms of probe data. BlueTooth, toll tag or license plate readers can be placed at the exact limits of the route you are monitoring. But they are more expensive and still require a good volume of through traffic to report accurately. The easiest method uses spot sensors. In that case you gather average speeds at each location and calculate the average travel or delay time. Depending on the application, spot sensors are often more accurate that probe data

Will your work require you to relocate the sensors as work progresses? If so, that’s another good reason to use doplar sensors. Microwave sensors such as RTMS or Wavetronix, must be set-up and calibrated by a qualified technician. It doesn’t take long, but it is more expensive and must be scheduled. Doplar can often be relocated by laborers on the job. It is more forgiving in terms of aiming and distance from the live lanes.

On the other hand, some states now import portable sensor data directly into their real time traffic data. In that case, the portable sensor data should mirror the permanent sensor data as much as is practical. In those cases microwave sensors are probably the better choice.

The real lesson here is to consider what your needs are first, then find the tool that will best fill those needs.