Get Involved with Work Zone ITS

If you are an agency employee responsible for a work zone ITS deployment, there are at least two ways you can handle it. You could write a specification that clearly defines what you want and then stay out of it except at those times when you don’t feel the contractor is performing. Or, you could roll up your sleeves and use the deployment as a way of learning what the system is truly capable of providing and how best to tailor it to your project.

As a system supplier, I have worked with both groups and, in my experience the deployments where agency gets involved have all been far more successful than those where they spell out the requirements and then leave. The reasons for this are simple. No two projects are exactly the same and no two systems have exactly the same capabilities. And only through frequent discussions between agency and system provider are the capabilities and needs aligned in the most efficient and advantageous way.

When we first put a system on the road, we are making an educated guess as to where the sensors should be located, what messages will make the most sense to drivers approaching the work zone, and what trigger speeds fit the situation. I’ve always said there is science in the way a system is designed to meet requirements. But there is always a little art, too, in the way you adapt that design to conditions on the ground.  If the agency takes the first approach, it will end with the science portion. The system will work. It will do what they asked, but the agency will not be taking full advantage of all it could provide.

My advice is to get involved. Learn about the art of the deployment. Ask a lot of questions about why the system does what it does.

The best time to start is before the deployment begins. Take charge of the creation of the messages to be displayed and the trigger speeds at which they are to be used. Discuss these with the system provider, with agency folks who know the area, and with the construction folks who can explain the different stages and how each will impact traffic.

Once the system is up and running, observe it in operation. If the CMS messages warning of stopped traffic seem to come on too soon, discuss that with the contractor. Perhaps you need to bump the trigger speeds a little lower. If your people are getting too many alarms, work with the system provider until you are only notified of events you wish to know about and none of the little slow downs that occur in a typical day. By taking a little more time to do this, you will see far better results.

This approach has another big benefit. Once you have gone through this process a few times you will have a far better understanding of what the system can and cannot do. You will know where that type of system should be used in the future and your educated guess about sensors, message signs and trigger speeds will be better educated for your next project.

Finally, you will be able to speak with authority about the cost effectiveness of using the system to mitigate traffic impacts. When it comes time to defend that expense, you will be able to do so citing benefits you have measured on previous jobs.

Pooled Fund Studies and New Product Development

I recently participated in an Enterprise pooled fund study to develop an Intersection Conflict Warning System (ICWS). We will talk more at some future date about the system. But today I would like to talk about the process. I am a businessman. I have always been a little uncomfortable with government designing product. In my experience market forces will always do a better job of design and refinement than a committee could possibly do.

But in this case someone needs to dictate how the system should work. In terms of technology, this is a simple system. But sign placement, when it should display warning messages and for how long, the effects of turning movements on those design parameters, fail safe modes, and many other performance specifications cannot be left to each manufacturer to decide separately.

The agency may be found liable if the system does not do those things correctly. It is in their interest to clarify their expectations up front. There are also several of these systems in use already in states like North Carolina, Iowa and Missouri. To maximize their effectiveness and to prevent confusion, the appearance of the equipment and the way it works must be consistent from state to state. So for both of these reasons it made good sense to decide those questions now.

The group began last year with a series of conference calls. The first ones resulted in a high level list of needs and wants for such a system. Then general functionality was described to support those needs. Finally, the group began to set actual parameters for the system performance. Things like on time and off time for the different signs, distance in advance of the intersection where signs should be placed and where vehicles should be detected. These discussions were difficult over the phone so they decided to hold a face to face meeting to hash them out.

A total of nine people were at that final meeting. One county DOT and four state DOTs were represented including a current member of the National Committee on Uniform Traffic Control Devices. Two of us from the American Traffic Safety Services Association (ATSSA) were there to represent industry, one from the sign industry and another (myself) from the rural ITS industry.

The group was led by Ginny Crowson of Athey Creek Consultants. She did a wonderful job of keeping us focused and on track. The group was championed from the beginning by Jon Jackels of Minnesota DOT. Unlike many agency folks, he pushed for industry involvement. He didn’t want to get months down the road with this process only to find out that industry either could not or would not manufacture the system.  He knew it would take a little longer with everyone participating, but he also knew the results would be far more developed and ready for market.

Everyone there was passionate about highway safety and the use of technology to improve it. There were disagreements but they were always held to the same standard: which idea will result in better, more cost-effective performance. I believe the size of the group was just right, too. Everyone could be heard and a trust developed quickly between the group members.

The meeting ran from noon the first day to noon the second day including another two hours during and after dinner. We didn’t get everything done, but we came very close. The most difficult and time consuming issues were all covered thoroughly resulting in a consensus on each one.

This is a process I would recommend any time a new product or service would benefit by starting with the performance requirements. We did not discuss how companies should design their systems to meet these parameters. The choice of technologies will be left up to each manufacturer. We were only concerned with what it had to do and whether it was feasible and cost-effective.