If you are considering including a work zone ITS system in a project, there are many factors you should consider. First and foremost you should be certain the system you choose will achieve the desired results. Data quality, data format, and real time data availability are all very important. But a third area should also be evaluated: how quickly can your vendor respond when equipment is damaged, stops working correctly for some other reason, or when it must be relocated.
Work zone ITS has come a very long way in quality and dependability in a few short years. But the equipment is still placed near traffic where accidents occur. Hardware can and sometimes will fail. If you include enough sensors, the failure of one is probably not an emergency, but it should be repaired or replaced quickly as the system response won’t be as good as it would be with a full set of sensors.
A more likely issue is data. The sensors may be working as intended, but due to location may not be sending data that fits your needs. For example, you may find it is picking up slow moving vehicles because it is on a steep hill, or near a weigh station offramp. Perhaps the traffic control is causing traffic to slow at that location briefly before going back to full speed. In any of these cases you may need to move the sensors to a better location so the system does not send out false alarms.
Construction activity can also cause issues. Workers may move a sensor out of their way as the paver moves past it, and then move it back once they are beyond it but without aiming it properly. The sensor shows there is no traffic because it is pointed at a flock of sheep rather than at the road. Or slow moving construction equipment, if detected by the sensors, will trigger false alarms.
This varies with the type of sensor as well. Some require more frequent attention than others. Simple radar is more forgiving. Side fire microwave sensors like Wavetronix or RTMS must be aimed precisely and calibrated at each location. Wind and vibration cause sensor trailers to move and can affect the output.
So it makes good sense to require local service and support. What the response time must be will vary greatly from project to project. Problems with one device in a travel or delay time system probably can wait for a day or two. But a sensor out in a queue warning system for a blind curve must be corrected much faster – usually in less than a few hours.
Be very specific with your expectations. Let everyone know going in what the maximum allowable downtime is for each device, each feature and for the software and server controlling them. That time will vary by device. The server and software must be up and running 24/7. Sensors are probably the second most important. Cameras and message boards are next. Alarms to users are probably last.
Consider including damages for downtime beyond the allowed maximum for each device and for the system as a whole. The number you choose should be a reasonable percentage of the total system cost. It might be the cost per day charged by the vendor for that device if that cost is known. Or you might use the system cost per day divided by the number of devices (less some percentage for the software, server and website). The important thing is to make both your expectations and the consequences if they are not met very clear to all concerned before the project bids. Then the vendor will know his or her costs going in.
But however you choose to define your requirements, be sure to include local representatives on call and available to make the little adjustments every system needs to operate at peak performance.