Anticipate challenges with the ITS technology being tested, including problems with software modification and adaptation of previously developed technology.

A Washington State Department of Transportation’s experience with testing of new variable speed limit technology to reduce winter accidents on a mountain pass.

Date Posted
09/16/2005
TwitterLinkedInFacebook
Identifier
2005-L00086

Travel Aid: Lessons Learned and Recommendations

Summary Information

The Travel Aid system was designed to transmit suggested speed limits and advisory messages to in-vehicle units and dynamic message signs (DMS) through the Snoqualmie Pass area of I-90 east of Seattle, Washington. This 40-mile section of freeway experiences increased crash rates during the winter months because of snow, ice, fog, and other adverse weather conditions. The goal of this project, which began in 1992, was to reduce the frequency and severity of crashes through the Snoqualmie Pass.

To generate the suggested speed limits, road weather data were collected from radar vehicle detectors, roadside sensors, and environmental sensor stations and entered into an algorithm embedded within the Travel Aid operating system software. The information was processed in a central Travel Aid server located in a WSDOT project office. A Travel Aid operator then reviewed the suggested speed limit. If the operator deemed the suggestion appropriate, it was transmitted, along with traveler advisory messages, to the DMS.

This lesson is based on findings from the Travel Aid Evaluation Report completed by Booz-Allen and Hamilton in March 1999, with additional input from WSDOT staff involved in the project.

Lessons Learned

The findings from this experience indicate that a project that tests new ITS technology may experience a range of problems because of the very technology being evaluated. The lesson learned from this project centers around the challenges experienced regarding software modification, adapting previously developed technology, and the radio system:

  • Complete a functional specification for the project before beginning software modifications. Software modification is an integral part of the design and development of an ITS. Explicitly documenting the functions that a system requires will help to ensure fewer false starts and revisions.
  • Include a prototyping step as part of the software development and modification. Prototyping, which is a simulation of the systems operation, assured a way to communicate with the Travel Aid operators about how the system would look and operate.
  • Expect difficulties in retrofitting previously designed equipment with a new ITS. The Travel Aid project planned to use an available in-vehicle device. This did not work because of communication incompatibilities between the in-vehicle devices and the Travel Aid systems. These problems rendered the in-vehicle units inoperable.



These technical challenges delayed or prevented parts of the Travel Aid test from occurring. For example, the compatibility problem with the in-vehicle units would have required adding an estimated two full-time staff during the test period to test the in-vehicle units. Consequently, the in-vehicle units were never installed in the test vehicles.



This experience suggests that any test of new ITS technology that involves software modification should first develop functional specifications for the project and also include prototyping. The lesson also suggests that adaptation of previously designed equipment may present serious incompatibly problems.