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

Experience from iFlorida Model Deployment

Florida,United States

Background (Show)

Lesson Learned

As part of the iFlorida Model Deployment, FDOT deployed a network of toll tag readers that were used to estimate travel times on seven Orlando arterials and on portions of several limited access toll roads. Soon after the deployment of these readers was complete in May 2005, FDOT discovered that many of them had failed between the time they were deployed and FDOT began monitoring them. There were also problems with the CRS software, which made it uncertain whether the travel times being produced by this network were being used correctly to provide 511 travel time messages. It was not until November 2007 that FDOT had procured new software that would obtain travel times from the toll tag network and automatically populate 511 messages with those travel times.

Throughout this process, lessons learned regarding the operation of a toll tag network for estimating travel times were documented. These lessons learned are summarized below.
  • Beware of limitations of using toll tags to calculate travel times. FDOT identified and/or experienced a number of factors that limited the effectiveness of the toll tag network for producing travel times. Those considering using toll tag based travel time networks should consider these factors in their designs. Some of the factors FDOT identified and problems they experienced included:
    • Limited market penetration for toll tag readers. Before deploying a toll tag network, FDOT conducted tests indicating that about 20 percent of vehicles on Orlando arterials had toll tag readers, indicating that toll tag readers would generate a large number of reads for the iFlorida arterials.
    • Misaligned toll tag readers. After deployment, FDOT found that some toll tag readers did not produce as many reads as expected. FDOT discovered misaligned antennae and obstructions between the antennae and the roadway were often the root cause of this problem.
    • Duplicate tag reads. On arterials, vehicles often passed under the toll tag readers at low speeds or were stopped under the reader. This often resulted in duplicate reads of the same tag.
    • Vehicle diversions. FDOT found that many tags read at the start of a travel time segment did not match any tags read exiting the segment. This was likely caused by vehicles diverting onto other roads before exiting the segment. The fraction of vehicles diverting seemed to increase as the travel time segment length increased.
    • Vehicle stops. An analysis of travel time observations indicated that the mean observed travel time was typically significantly higher than the median observed travel time. This was likely because some vehicles made stops between the time they entered and exited a travel time segment, introducing a high bias into the travel time observations. Methods were needed to filter out these high travel time outliers.
    • Toll tag reader failures. FDOT experienced a large number of reader failures early in the deployment and struggled to maintain high availability of the readers throughout the project. At peak performance, about 90 percent of readers were operational, though the percent of operational readers could be much lower.
    • Clock mis-synchronization. When first deployed, the internal clocks on many of the toll tag readers were not synchronized with a standard clock, which prevented use of the toll tag reader data for computing travel times.
    • Transmission of archived tag reads. The FDOT toll tag reader system maintained an archive of toll tag data at each reader. If the transmission of the tag information to the toll tag server failed, the reader would later re-transmit all of the tag reads that had previously failed to transmit. At times, this transmission required so much network bandwidth that the transmission of real-time toll tag reads from other readers was delayed, which prevented the use of the real-time data to generate real-time travel time estimates.
  • Adjust travel time estimation parameters for arterials. The algorithm that FDOT used to generate travel times from the toll tag reader data was originally developed for use on limited access highways. FDOT discovered that some of the parameter settings needed to be different to work well on arterials. For example, diverting traffic on arterials meant that the observed average travel time was typically higher than the actual travel time, which was not the case on limited access highways. The algorithm for excluding outliers is, therefore, more important on arterials than for limited access highways. The toll tag matching efficiency was much higher for limited access roads than for arterials and much lower for long arterials than for short ones. For short arterial segments (about 1 mile in length), about 50 percent of entering vehicles were later observed exiting the segment. For long arterial segments (about 5 miles in length), this percentage dropped to less than 20 percent.
  • Include tag-reads from turning vehicles for more accurate travel time estimates. Including tag reads from turning vehicles can increase the number of travel time observations generated. The FDOT algorithms used data from a single reader to supply tag reads for both the entrance into and exit from a travel time segment. Depending on the exact placement of the readers relative to the intersection, more matches can be obtained by allowing data from multiple readers to be used. (For example, if a reader supplying tag reads at the entrance of a travel time segment is placed upstream from the starting intersection, then it will not record tag reads from turning vehicles that enter the segment. Including tag reads from readers monitoring the intersecting road can provide reads from these turning vehicles.) The evaluation team tested such an algorithm and found a significant increase in the number of travel time observations recorded.
  • Monitor the maintenance of toll tag readers as soon as each has been installed and functioning. The iFlorida toll tag readers were deployed over a four month period, and FDOT did not begin actively monitoring the reader status until all the tag readers had been installed and deployment was complete. In the intervening period, many readers had failed, which created a large demand for reader repairs that FDOT was not able to fulfill.
The lessons reveal that the use of tags for estimating travel time has limitations that should be adequately addressed in order to provide accurate information for the roadway 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)

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.




United States

Goal Areas



CCTV, closed circuit television cameras, road monitoring, sensors, vehicle detector, traffic detection, traffic monitoring, congestion monitoring

Lesson ID: 2009-00488