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.

Experience from iFlorida Model Deployment

Florida,United States

Background (Show)

Lesson Learned

At the start of the iFlorida Model Deployment, FDOT managed about 45 dynamic message signs (DMS) deployed along I-4. Most signs were used to display delay and incident information, with a small number of sign used to display information about local attractions. During the iFlorida deployment and operational period, the number of these signs increased to 60. In addition, 20 variable speed limit (VSL) signs were deployed as part of iFlorida and a number of trailblazer signs were deployed at arterial intersections near the I-4 and I-95 interchange. These signs operated reliably, with about 90 percent of the signs operational, on average. This percentage dropped to 70 percent during the midst of the iFlorida deployment when the Condition Reporting System (CRS) software was experiencing difficulties interfacing with the signs and FDOT resources were focused on correcting other problems with the iFlorida deployment.

A number of lessons learned were identified by observing sign operations during the evaluation with regard to using dynamic message signs (DMS) for traveler information dissemination:
  • Validate travel time estimates before being used for traveler information. The CRS software miscalculated travel times that were used for DMS messages, resulting in inaccurate travel times being displayed to the public. One iFlorida stakeholder suggested that the process used to produce travel times for DMS messages should be thoroughly validated before being used in the field.
  • In developing software for automating messages posted on DMS, focus on the types of messages that are used often and change frequently. The CRS software included tools to generate travel time DMS messages automatically. FDOT operational policies for these signs meant that congestion messages were used most often during high traffic periods-exactly the time when sign messages changed frequently (because of changes in travel times). This required RTMC operators to manage congestion sign messages manually during rush hour periods while travel time messages, used when congestion was not present, were generated automatically. The workload on RTMC operators might have been reduced if congestion messages were automated rather than travel time messages.
  • Include software tools for managing DMS travel time messages manually in the event that the automated travel times become unavailable or unreliable. FDOT experienced significant reliability problems with their travel time network, so that travel time estimates were often unavailable. Although the CRS software was intended to include tools to estimate travel times based on historical values, these tools were not used. When the CRS failed, FDOT discovered that (a) static historical travel times worked well for most of the day and (b) RTMC operators could update signs manually to reflect current travel conditions when congestion occurred, although they made these updates by circumventing the CRS software.
In general, the FDOT roadside signs proved fairly reliable. Prior to the iFlorida deployment, about 90 percent of the forty-four FDOT DMSs were operational. Throughout most of 2005 and 2006, when FDOT was experiencing significant problems with other aspects of the iFlorida deployment, this percentage dropped down to about 70 percent. By early 2007, after FDOT abandoned the use of the CRS to manage sign messages, the reliability of these signs returned to pre-iFlorida levels, even as the number of signs increased from 44 to 60. Reliable messages posted on DMS increase customers’ satisfaction through assisting them manage their en route mobility conditions.

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)


Lesson of the Month for March, 2010 !

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-00508