Deploy a variable speed limit system only after the software systems required to support it are mature and reliable.

Experience from iFlorida Model Deployment

Florida,United States

Background (Show)

Lesson Learned

As part of the iFlorida Model Deployment, FDOT deployed the field hardware needed to support a variable speed limit (VSL) system on a portion of I-4 and maintained a network of loop detectors on I-4 that could support determination of when reduced speed limits should be implemented. Due to problems with CRS, which was meant to be software system for the FDOT District 5 (D5) regional traffic management center (RTMC), a functioning VSL system could not be started prior to the completion of the iFlorida project evaluation (January 2009). Nevertheless, FDOT’s experience with VSL system deployment did bring to light a number of lessons learned that might benefit others considering VSL:
  • Identify statutory and regulatory speed limit requirements before considering the use of variable speed limits. Statutory restrictions limit the applicability of VSL on I-4. The minimum speed limit of 40 mph, combined with the normal speed limits of 50 and 55 mph on I-4 in Orlando, meant that speed limits could be varied only over a small range. The requirement for an engineering and traffic investigation before speed limits could be changed was also problematic. FDOT determined that it could perform this type of investigation once to identify the types of traffic conditions that would warrant lower speed limits, and RTMC staff could then change speed limits after verifying that the specified conditions for lowering speed limits had been met.
  • Develop the concept of operations for VSL before designing the VSL system and validate it against historical data. Because of the long lead time for deploying the iFlorida field equipment, FDOT contracted to deploy the VSL signs before completing the VSL concept of operations, specifying that the signs be deployed in the area where congestion most often occurred. The VSL concept of operations emphasized the benefits of lowering speed limits upstream from a congested area. A comparison of the VSL sign locations to historical patterns of recurring congestion indicated that the signs were to be located to cover the area upstream of the points where eastbound congestion typically began, though not the area upstream of the full extent of the congestion at its peak. The VSL signs appeared to be west of the area congestion typically occurred in the westbound direction. FDOT noted that the agency had discussed each of these issues prior to selecting the site for deploying the VSL signs; however, because these issues were not addressed in the concept of operations document, the basis for the VSL design was not documented.
  • Ensure that the algorithms for recommending speed limit changes can detect and correct for low vehicle speed observations that are not related to congestion. A review of historical speed data identified a number of cases where low speed measurements did not appear to be related to congested conditions. In some cases, this appeared to be caused by a faulty detector (e.g., the detector consistently reported low speeds). In others, a single low value would be embedded in a series of otherwise normal values. In either case, the algorithms for recommending lower speed limits should include methods to detect and disregard low vehicle speed measurements that are not related to congestion. (In the case of iFlorida, the problems with the CRS made this very difficult or impossible to do.) Problematic detectors might also be taken offline until repaired, in which case the algorithms must be able to adapt to the fact that detectors may be taken offline. The robustness of those algorithms could be verified by applying them to historical data.
  • Require operator approval of all speed limit changes. FDOT's design of the VSL system called for an automated system to monitor traffic and weather conditions and recommend lower speed limits when conditions appeared to warrant them. RTMC operators would be required to investigate traffic conditions and approve the recommendation only when warranted by current traffic conditions. Since any algorithm for recommending speed limits is likely to fail on occasion, this approach will prevent those failures from resulting in changing speed limits at inappropriate times.
  • Deploy a VSL system only after the systems required to support it are mature and reliable. Because of its participation in the Model Deployment and the required milestones, FDOT had to deploy infrastructure and develop the operating system concurrently. This resulted in the deployment of VSL signs before the CRS software for supporting those signs had proven reliable. These signs remained set at the fixed speed limits when the initial version of the CRS software did not operate reliably and 2 years of additional work by the CRS contractor did not remedy the problems. Thus, FDOT had to bear the cost of deploying VSL signs without obtaining the benefit of using variable speed limits.
After the CRS software for RTMC was abandoned, FDOT began working with a new contractor to migrate to a different traffic management application, SunGuide, for the RTMC. By August 2007, FDOT was using SunGuide at the RTMC. By November 2007, SunGuide supported most of FDOT's basic traffic management needs and FDOT's confidence in the system was growing. At about that time, FDOT elected to restart its delayed VSL project. In December 2007, FDOT reviewed the VSL concept of operations and began to develop a new approach for triggering speed limit changes. The agency also began testing the SunGuide software capabilities to support VSL operations. As the national evaluation was ending, it appeared that FDOT's experience with VSL on I-4 was ready to begin. The VSL system is expected to improve mobility and efficiency of traffic operations along I-4 near Orlando.

Lesson Comments

No comments posted to date

Comment on this Lesson

To comment on this lesson, fill in the information below and click on submit. An asterisk (*) indicates a required field. Your name and email address, if provided, will not be posted, but are to contact you, if needed to clarify your comments.


iFlorida Model Deployment Final Evaluation Report

Author: Robert Haas (SAC); Mark Carter (SAIC); Eric Perry (SAIC); Jeff Trombly (SAIC); Elisabeth Bedsole (SAIC): Rich Margiotta (Cambridge Systematics)

Published By: United States Department of Transportation Federal Highway Administration 1200 New Jersey Avenue, SE Washington, DC 20590

Source Date: 01/30/2009

EDL Number: 14480

URL: https://rosap.ntl.bts.gov/view/dot/3977

Other Lessons From this Source

Lesson Contacts

Lesson Analyst:

Firoz Kabir


Average User Rating

0 ( ratings)

Rate this Lesson

(click stars to rate)

Lessons From This Source

Assess security risks, threats, vulnerabilities, and identify countermeasures to ensure operations of transportation management centers.

Be flexible to use data from various sources, such as the highway police patrol’s incident data, user feedback, and monitoring stations, to develop a statewide traveler information system.

Beware of challenges involved in developing an integrated statewide operations system for traffic monitoring, incident data capture, weather information, and traveler information—all seamlessly controlled by a central software system.

Beware of costs, utility, reliability, and maintenance issues in deploying a statewide transportation network monitoring system.

Beware of the limitations of using toll tags in order to calculate travel time on limited access roadways and arterials.

Beware that software development for ITS projects can be utterly complex, which demands avoiding pitfalls by following a rigorous systems engineering process.

Define a vision for software operations upfront and follow sound systems engineering practices for successfully deploying a complex software system.

Deploy a variable speed limit system only after the software systems required to support it are mature and reliable.

Design traffic video transmission systems around the constraints of bandwidth limitations and provide provisions for remote configuration of video compression hardware.

Develop an accurate, map-based fiber network inventory and engage ITS team in the construction approval process.

Develop an effective evacuation plan for special event that gathers a large audience and consider co-locating the responding agencies in a joint command center.

Ensure compatibility of data format of the field-weather monitoring sensors with the central software in the transportation management center.

Ensure that experienced staff oversee the development of a complex software system and thoroughly follow systems engineering process.

Ensure that Highway Patrol's CAD system operators enter key information needed by the transportation management center operators.

Establish a well defined process for monitoring and maintenance before expanding the base of field equipment.

Estimate life-cycle cost of ITS technologies as part of procurement estimates in order to assess the range of yearly maintenance costs.

In developing software for automated posting of messages on dynamic message signs, focus on the types of messages that are used often and changed frequently, and also include manual methods for posting.

Incorporate diagnostic tools to identify and verify problems in the transmission of video in a transit bus security system.

Perform adequate analyses and tests to design, calibrate and validate the capabilities of a bridge security monitoring system in order to reduce false alarms.

To support statewide traveler information services, design and implement reliable interface software processes to capture incident data from the local and highway patrol police’s computer aided dispatch systems.

Use simple menu choices for 511 traveler information and realize that the majority of callers are seeking en route information while already encountering congestion.

Lesson ID: 2009-00500