Office of Operations
21st Century Operations Using 21st Century Technologies
Table of Contents


Executive Summary

The iFlorida Model Deployment began in May 2003 with ambitious goals and high hopes for what could be accomplished. iFlorida plans called for the Florida Department of Transportation (FDOT) District 5 (D5) to complete the design, build, and integration of the infrastructure required to support iFlorida operations in 2 years. The required infrastructure was extensive, spanned numerous stakeholders, and included many technologies that were new to FDOT D5, such as sophisticated traffic management center (TMC) operations software, a wireless network deployed along I-4, an interface to Florida Highway Patrol Computer Aided Dispatch (FHP CAD) data, statewide traffic monitoring, and many others. The iFlorida plans also called for deployment of these technologies in ways that required coordination among more than 20 stakeholders. It was an ambitious plan that would result in dramatically different traffic management operations for FDOT D5 and other transportation stakeholders in the Orlando area.

While pursuing this plan, FDOT faced many challenges ranging from higher failure rates than expected for some field hardware to difficulties with the Condition Reporting System (CRS) and Central Florida Data Warehouse (CFDW) software. Despite these challenges, it can be readily claimed that the overall iFlorida Model Deployment was successful. When limitations within the automated systems were discovered, FDOT developed ways to continue to support key traffic management capabilities. When the reliability of the arterial toll tag readers was lower than expected, FDOT modified the way messages were presented in the 511 system to reduce the impact of the missing data. When the CRS travel time estimation process proved inaccurate, FDOT deactivated messages that were known to be flawed. Later, it developed standard messages that could be used during uncongested periods and had operators manually create messages when congestion occurred. When the FHP CAD interface failed, a new interface was developed so that RTMC operators could continue to receive data about FHP CAD incidents. After problems with the CRS's ability to manage sign messages were observed, FDOT had RTMC operators periodically review sign messages to ensure that the correct message was being displayed and, later, had RTMC operators manage all sign messages manually. When the CFDW failed to create useful archives of CRS data, FDOT archived copies of many of the raw data streams that were being provided to the CRS.

Many of the challenges faced by FDOT centered on limitations and failures of the CRS software. FDOT, aware of the problems with the CRS and anticipating the potential that it might fail, began testing SunGuide, a replacement for the CRS, in November 2006. First, FDOT installed an existing version of the SunGuide software and configured it to manage recently deployed ITS equipment on and near I-95. When the CRS failed in May 2007, FDOT began expediting a transition to this new software. By September 2007, FDOT was operating a Beta release of the SunGuide 3.0 software and sharing its operational experiences with the software developers. This close interaction enabled FDOT to continue to use the SunGuide software and regain the operational advantages that could not be obtained through the CRS.

Through its willingness to develop alternative means to overcome the challenges and barriers it faced, FDOT ensured continued traffic management operations. The difficulties associated with the iFlorida Model Deployment also provided many opportunities to identify lessons learned from the experiences they had. The most important of these are described in the list below.

  • Following sound systems engineering practices is one key for successfully deploying a complex software system like the CRS. The CRS project began with high-level requirements defined, and the CRS contractor did not refine those broad requirements into more detailed ones. Systems engineering approaches that are less reliant on detailed requirements, such as a spiral model, were not employed. Inadequate requirements led to misunderstandings about the capabilities expected from the CRS and to insufficient testing of the software. The software development process spiraled out of control and ended with CRS software that was not usable and that ultimately was abandoned. Applying sound systems engineering practices more rigorously could have resulted in more usable code or helped FDOT more quickly determine that the contractor was not performing. Better requirement definitions up front might have prevented changes that occurred throughout the development phase. More stringent testing by the contractor might have identified problems earlier in the development cycle when they could be more easily corrected. Closer monitoring of this testing might have allowed FDOT to more quickly determine that the software was not meeting requirements.
  • It is important to devote a significant amount of time at the beginning of a software development project to ensure that all parties share a mutual vision for how the resulting software should operate. The starting point of the CRS project was a set of high-level requirements developed by FDOT. A number of meetings were held between FDOT and CRS contractor staff to review these requirements. Despite this, the requirements often left room for interpretation, and differences of opinion between FDOT and the CRS contractor about how the CRS should operate continued throughout most of the time the CRS was under development. No mutual vision of how the software should operate was developed. With SunGuide, FDOT was provided with an early version of the software and FDOT configured the software to work with a set of recently installed FDOT hardware. FDOT worked directly with SunGuide technical staff to resolve difficulties and to define enhancements to current features needed to meet FDOT needs. This evolutionary approach resulted in a shared vision of how the software should operate.
  • Software must be capable of interfacing with subsystems and the nature of the interaction must be well-defined. With the CRS, long-standing problems occurred with the interfaces between the CRS and almost every other external system with which it interfaced-the FHP CAD system, the weather provider, the travel time server, and the DMS signs. Only the interface between the CRS and the 511 system worked reliably.
  • Plan to integrate newly deployed field equipment into existing monitoring and maintenance processes. Most iFlorida field equipment included a two-year parts and labor warranty period that covered the planned two-year operational period for the iFlorida Model Deployment. FDOT seemed to have the expectation that most of the maintenance would be the responsibility of the contractors. FDOT found, however, that significant resources were still required to monitor the equipment and to manage the maintenance activities. For example, when a failure could be the responsibility of more than one contractor, FDOT was required to use their maintenance resources to identify the specific failure so that the appropriate contractor could perform the warranty repair. FDOT was not prepared for this increased demand on its own maintenance resources. The arterial toll tag readers were deployed and tested over a 4-month period beginning in February 2005, yet little or no follow up testing was performed on these devices to ensure they continued to operate until June 2005. By that time, almost half the readers had already failed. This caused a large surge in maintenance demand. FDOT did not have access to sufficient maintenance resources to diagnose these failures and the warranty contractor did not have access to sufficient spare parts to make repairs in a timely manner. Similar problems affected other iFlorida systems, including the Statewide Monitoring System, the bridge security system, and the broadband wireless system; deployment of these systems was completed before FDOT had developed a process for monitoring and maintaining them.
  • Because traffic monitoring equipment will fail, systems that rely on data from this equipment should be designed to work well when these inevitable failures occur. At FDOT, key equipment such as loop detectors, DMSs, and toll tag readers were available about 90 percent of the time. Reaching this level of service was difficult, and FDOT rose to the challenge of doing so. Even with this level of service, however, the iFlorida systems were regularly required to operate with missing data. Initial iFlorida plans called for filling in missing data with estimates from historical data or operator observations, but these plans did not come to fruition. Early in the operational period of the deployment, data gaps led to long periods of times where DMSs were blank and 511 messages were incomplete.
  • Use a staged approach for deploying new systems. The schedule for the iFlorida deployment called for the nearly simultaneous deployment of a large number of systems new to FDOT. In many cases, this resulted in deployment delays. For example, problems with the toll tag readers meant that data was not available to test the OOCEA travel time server and travel times were not available to test the CRS features that depended on them. This sometimes led to resource conflicts: it appeared that FDOT focused so many maintenance resources on repairing failed toll tag readers that maintenance of other equipment slipped. In the case of the VSL signs, the equipment was deployed, but variable speed limits were not implemented during the planned iFlorida operational period because the CRS features needed to manage variable speed limits did not work satisfactorily. (FDOT did use variable speed limits after the CRS was abandoned and FDOT began using SunGuide.) iFlorida weather data was not used, in part because FDOT's focus on getting its primary traffic management tools working correctly prevented it from spending time on integrating weather data into its traffic management activities.
  • Traffic monitoring may not be the best approach to obtaining data for statewide traveler information. FDOT found that the statewide monitoring system it deployed was too sparse to be an effective tool for obtaining statewide traffic information. Instead, it primarily used incident information from the FHP CAD system. However, the FHP CAD system did not cover all the roads for which FDOT wished to provide statewide traveler information. Some FDOT staff suggested that they could have had better statewide traveler information if they had developed methods for receiving incident data from other law enforcement organizations in the state. It should be noted that, while FDOT staff found the Statewide Monitoring System ineffective at supporting traveler information, SEOC staff members believed that the system would be very useful for monitoring hurricane evacuation traffic.
  • Travel time estimates should be validated 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. Concerns existed that the dissemination of inaccurate travel time messages on DMSs may have reduced public confidence in traveler information. One iFlorida stakeholder suggested more stringent testing for all processes that produce traveler information for public consumption.
  • Estimates of future demand may be more important to contraflow decision making than real-time traffic information. During Hurricane Frances, it was estimated that it would require 3 hours to set up contraflow on SR 528. The long setup time and the fact that contraflow operations were not allowed at night in Florida effectively required that a contraflow decision be made a day before such operations were to be implemented. Because contraflow decisions must be made based on estimates of what is essentially future traffic demand, being able to estimate the number of people expected to evacuate may be a more important consideration in the contraflow decision making process than real-time traffic information. Also important are estimates of traffic demand in the opposite direction. In one case, FDOT expected significant eastbound demand due to cruise ship passengers flying in to Orlando before traveling to the coast to board ships. Concern for servicing this demand was one factor considered when determining whether to implement westbound contraflow on SR 528.
  • Consider the needs of existing users when changing the 511 menu structure. The iFlorida deployment resulted in a significant change to the 511 menu structure. This change was necessary so that the 511 system could accommodate all the additional roads brought into the system by iFlorida. When the the new 511 system was put into use, FDOT received a number of complaints from existing 511 users about the new menu. It appeared that many of these users may have reduced their usage once the new system was in place. Putting in place a mechanism to accommodate these existing users, such as providing access to the old menu structure, could have reduced the number of complaints received and the drop in callers that occurred.
  • The voice recognition system can be a source of problems with 511 systems. About one time in seven, the iFlorida 511 system rejected a user utterance as an invalid command. Because most calls required the user to make several commands to reach the desired information, almost 50 percent of calls included at least one case where the system rejected a user utterance. This meant that a number of 511 calls ended without the caller receiving any traffic information. FDOT's My511 program helped reduce the number of commands needed to reach traveler information for those that registered with the system.
  • Few 511 callers could be classified as frequent callers. In a typical week, less than 300 users called the system at least four times during the week on at least three different days. Of the users that called frequently in a given week, less than half called frequently in the following week. This implied that few 511 callers use the system for daily trip planning. Instead, it appeared that most callers used the system to find out more information about unusual traffic conditions of which they were already aware.
  • Few callers took advantage of traveler information available for Orlando arterials and toll roads. About 80 percent of the requests for traffic information from the Central Florida 511 system were for I-4 and I-95, with requests for information on toll roads and arterials being about 15 and 5 percent of calls, respectively. A survey of travelers in the Orlando area indicated that the traveler information of greatest interest to the respondents was related to diversions and detours, such as instructions for how to bypass an incident that has occurred.
  • False alarms can be a problem with a bridge security system. The high number of false alarms in the iFlorida Bridge Security Monitoring System meant that alarms were often ignored. It appeared that the highly dynamic environment of a bridge made it difficult to specify automated video monitoring tests that would alarm if suspicious activity occurred but that would not generate false alarms. It is not clear if additional tuning of the video monitoring settings could have resulted in a better balance between sensitivity to suspicious activity and ability to reject false alarms or if a better balance is not possible with current automated video monitoring technology.

There were also opportunities to observe lessons learned about FHWA's role in the model deployment, such as those listed below.

  • Clarify expectations for a model deployment. As FDOT struggled to get most of the arterial toll tag readers operational for the iFlorida unveiling, FHWA staff noted that it might have been better to begin iFlorida operations with only a subset of the readers operational, phasing in the other readers over time. FDOT staff received this recommendation with surprise, as they were under the impression that the entire suite of iFlorida systems should be operational throughout the planned iFlorida operational period. FHWA staff noted that a model deployment, by its very nature, involves many leading edge technologies and that problems should be expected.
  • Leverage FHWA experience and expertise. Some members of the FHWA team had experience and expertise that could have benefited FDOT. For example, FDOT had little experience with large software acquisitions, and FHWA offered to provide the US DOT Research and Innovative Technology Administration (RITA) ITS Software Acquisition course to FDOT personnel involved in the iFlorida deployment - this offer was declined. FHWA also suggested that developing a detailed iFlorida Concept of Operations would help guide the deployment and operations after the deployment was completed. Following these suggestions could have helped avoid some of the problems that occurred related to the development of the CRS.
  • Maintain a local presence of experienced FHWA personnel at the deployment. While FHWA participated in key meetings, such as those to review requirements and iFlorida designs, there was little FHWA presence at FDOT between those meetings. This sometimes reduced the extent to which FHWA recommendations were followed during the deployment activities because FHWA staff members were not onsite to continue to push these recommendations. It is also possible that local presence of FHWA staff members would have helped FDOT understand that it was acceptable to deploy iFlorida capabilities incrementally, which could have eliminated some of the problems that occurred as FDOT attempted to simultaneously deploy so many new traffic management capabilities. There were also times when FHWA was not fully aware of potential for the iFlorida schedule to slip because of the deployment problems that were occurring. A local presence would have been more aware of these problems.

Many other observations were made during the evaluation over a broad range of topics, ranging from general suggestions regarding how to design, deploy, and maintain transportation system hardware and software to specific suggestions related to the operation of specific types of transportation management systems, such as interfacing with FHP CAD systems, using DMSs, and implementing traveler information. These observations are noted throughout the body of this report.

As a Model Deployment, the iFlorida project was a success. It demonstrated the capabilities of several leading edge transportation technologies, such as using toll tag readers to collect arterial travel times and automated generation of travel time information. It also demonstrated the integration of these technologies with traffic management software used to help perform and automate traffic management activities. Even the challenges faced by FDOT during the deployment—challenges that sometimes limited the benefits seen by FDOT—provided useful lessons learned that can benefit future deployments.

For example, the lack of a clear iFlorida concept of operations led to uncertainties about the basic operational practices that the CRS should support. The CRS requirements were vague and left some of these uncertainties unresolved almost 2 years into the deployment efforts, only months before iFlorida operations were scheduled to begin. The operational concepts and requirements also did not consider how operations would be affected by different failures that might occur. For example, FDOT purchased new VSL signs in 2008, in part because the signs originally purchased did not operate in an acceptable manner if communication was lost to one of two signs deployed at a single location. Future deployments should consider developing a detailed concept of operations that describes how the system will be used, including how it will operate when different failures occur.

Another source of these challenges was trying to accomplish too much too quickly. iFlorida had the potential to dramatically change the way FDOT D5 and other iFlorida stakeholders managed traffic. It greatly increased the number and types of field hardware that needed to be maintained. It also extended the scope of RTMC operations from managing traffic on I-4 to helping to manage traffic on Interstates, toll roads, and arterials in the Orlando area and on major highways statewide. RTMC operations also became responsible for working with both new types of data (e.g., automated travel times, FHP CAD incidents, weather conditions) and new systems (e.g., bridge security, LYNX bus security). The RTMC operations environment also needed to evolve from one in which RTMC operators manually managed resources such as DMS and 511 messages to one in which many activities were automated.

The compressed iFlorida schedule also led to challenges. Many systems were under simultaneous design and the interdependencies between these systems were difficult to manage. Problems with the deployment of the arterial toll tag readers made it difficult for OOCEA to test the travel time server they were developing. Delays in the availability of OOCEA travel time data made it difficult to test the CRS travel time processing tools. Problems with CRS travel time processing made it difficult to test the CRS travel time DMS message tools. When problems were discovered after the initial version of the CRS software was released in November 2005, it was not clear which of the various components that made up the iFlorida suite of interdependent software and hardware were working reliably and which were not. Future deployments should consider implementing these changes incrementally rather than simultaneously.

FDOT staffing plans may not have fully considered the demands that would be placed on the staff by the simultaneous deployment of so many new systems. FDOT staff was sometimes stretched thin, simultaneously trying to manage iFlorida deployment projects, integrating new hardware into the maintenance process, and developing new procedures for managing iFlorida operations. Maintenance staff and procedures, appropriate for pre-iFlorida levels of field hardware, proved insufficient for the increased workloads that came with maintaining the iFlorida field equipment. When problems with individual iFlorida projects developed, the situation worsened. Efforts to repair toll tag readers that had failed affected FDOT's ability to maintain other field hardware. Eventually, a de facto triage occurred as resources were focused on maintaining critical field hardware (e.g., loop detectors, toll tag readers, DMSs) and performing critical transportation activities (e.g., managing DMS and 511 messages), leaving less critical hardware (e.g., RWIS stations, statewide monitoring stations) and less critical operations (e.g., bridge security, LYNX bus security, use of weather data, VSL, data warehousing) to languish. Future deployments should consider estimating the demands that new deployment activities will place on existing staff to ensure that sufficient staff exists to handle the increased demands. Scheduling activities so that periods of high staff demand (e.g., requirements development, verification and validation) do not occur simultaneously for different projects can help reduce the impact on DOT staff.

By the end of the iFlorida operational period, FDOT was beginning to overcome the last of the challenges it faced with the iFlorida Model Deployment and were beginning to see the full benefits they had expected. FDOT had abandoned the CRS software and acquired new software, SunGuide, which provided more of the functionality that the agency was seeking. Interfaces that were unreliable under CRS (e.g., DMS, FHP CAD) were working under SunGuide. With critical operations working more reliably, FDOT began to focus on adding new capabilities to its traffic management operations, and new features were added to the 511 system. FDOT implemented variable speed limits and began to consider how to integrate weather data into its traffic management operations. Other regional transportation stakeholders began discussions with FDOT about using SunGuide and gaining access to iFlorida data. FDOT was, at last, beginning to realize the full potential that was visualized when the iFlorida Model Deployment began.