13. Summary and Conclusions

The iFlorida Model Deployment began in May 2003 with ambitious goals and high hopes for what could be accomplished. Problems faced along the way prevented FDOT from achieving many of these goals. FDOT did, however, continue to support key traffic management capabilities while these problems were occurring, though many operations that were expected to be automated had to be conducted manually. This ensured that the traveling public continued to benefit from the iFlorida capabilities and allowed identification of some lessons learned related to these operations. The next section summarizes the history of the iFlorida Model Deployment. Section 13.2 summarizes the lessons learned.

13.1. Summary of the iFlorida Model Deployment

iFlorida plans called for FDOT 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 TMC operations software, a wireless network deployed along I-4, an interface to 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.

Unfortunately, the Model Deployment faced numerous barriers to achieving its full potential. Maintaining all of the newly deployed field hardware proved difficult. Significant failures occurred with the arterial toll tag readers, the Statewide Monitoring System, the wireless broadband network, and the bridge security system. But, the most significant challenge concerned the integration of all the components through the CRS software. The CRS was the traffic management software that was intended to combine data from the iFlorida field equipment and provide tools to manipulate this data and control FDOT traffic management assets, such DMSs, 511 messages, the traveler information Web site, and road ranger services. Some of the shortcomings of the CRS software included:

• Difficulties interfacing with the FHP CAD system. The CRS software was expected to receive incident data from the FHP CAD system and provide tools to integrate that data into the incident data entered directly into the CRS by RTMC operators. However, the CRS software had difficulty interpreting the location information received from the FHP CAD system and sometimes placed an incident at an incorrect location. RTMC operators overcame this barrier by entering all incident data by hand.
• Limited capability for handling missing travel time data. The original specifications for iFlorida called for missing travel time data to be filled in by estimates from either historical data or operator observations. This requirement was later classified as non-critical and wasn't implemented when the CRS was first activated. This meant that many DMS signs were blank and many 511 messages stated that data was unavailable. The CRS requirements called for the CRS to include tools to estimate travel times based on historical data when observations were unavailable. These tools never functioned as expected in the CRS.
• Miscalculating travel times. After the CRS had been in operation for several months, RTMC operators and other iFlorida stakeholders began reporting that some of the travel times displayed on DMSs and included in 511 messages were incorrect. Although these errors decreased in frequency over time, they persisted for the entire period that FDOT used the CRS software.
• Improper processing of weather data. When FDOT first began using the CRS software in the RTMC, the CRS operator interface included a large number of alerts related to good weather conditions. The CRS contractor had expected the weather data provider to filter the weather data so that CRS received information about severe weather conditions only. The CRS software itself did no such filtering. The CRS software was also supposed to consider weather conditions when estimating current travel speeds based on historical data, a feature that never functioned.
• Difficulties interfacing with DMSs. Soon after FDOT began using the CRS, RTMC operators noticed that it did not always update DMS messages as expected. Sometimes the CRS was unable to manage messages for a DMS, and sometimes a DMS message set by an operator would appear for a brief time, then be replaced by another message. Other times all of the DMS icons would disappear from the RTMC operator user interface. Eventually, FDOT abandoned the use of the CRS for managing DMS messages.
• Difficulties with recording 511 messages. Soon after FDOT began using the CRS software, RTMC operators reported that the 511 messages they recorded sometimes skipped. RTMC operators were sometimes forced to record a message several times before the quality of the audio was sufficient to use in the 511 system.
• Instability of the CRS software. Throughout the time FDOT used the CRS software, it was prone to instabilities and crashes, with early versions crashing numerous times each week. Later versions of the software proved more stable, though it commonly crashed one or more times each week. After the CRS contractor quit the project in April 2007, instabilities in the software increased dramatically. Within a month, FDOT could not restart the software when it crashed, after which FDOT stopped using the CRS.

Many factors contributed to these failures. First among them was that FDOT did not follow a rigorous systems engineering process in managing the development of the CRS software. At the start of that project, it was noted that no clear statement of the concept of operations for iFlorida existed and that many of the requirements for the CRS software, the software that would support those operations, were vague and incomplete.

A second contributing factor to the failure for integration was the ambiguous relationship between FDOT and the CRS contractor. Early in the project, most client-contractor interactions with the CRS contractor occurred between CRS contractor management staff and FDOT project management. Contractor employees who would be developing the CRS software and regional traffic management center (RTMC) operators who would be using it were seldom directly involved in the discussions. The CRS contractor had pre-existing software that it hoped to use to meet most FDOT requirements, and the CRS contractor sometimes seemed more intent on convincing FDOT that the capabilities of its pre-existing software were best for FDOT rather than on understanding FDOT's intentions for the CRS software. It was hoped that close collaboration between FDOT and the CRS contractor would result in a shared vision for iFlorida operations that the CRS software would support. This did not occur, and fundamental questions related to iFlorida operations were still being discussed as the scheduled completion date for the CRS software approached.

A third contributing factor was the lack of a rigorous systems engineering approach to software development. The CRS contractor had originally proposed using a "spiral model" for developing the CRS, which would have provided FDOT with many opportunities to provide feedback to the CRS contractor and refine the CRS requirements. FDOT chose not to use this approach. System engineering practices suggest that CRS contractor develop detailed requirements based on the high-level functional requirements provided by FDOT. These detailed requirements would completely define the funcational capabilities of the CRS in unambiguous and testable terms. Instead, the CRS contractor adopted the high-level functional requirements as the detailed requirements for the CRS. The FDOT staff member overseeing the CRS development was not experienced in software procurements, and accepted these requirements as the basis for the CRS design and testing.

A fourth contributing factor was a confusing program management structure for the iFlorida program. On FDOT's side, top-level management sometimes superseded decisions made by FDOT CRS project management during meetings with the CRS contractor. This made it difficult for final decisions to be made during meetings between the CRS contractor and FDOT CRS project management, because it was uncertain who had the final authority for making a decision. One example was the use of spliced speech for generating 511 messages. FDOT top-level management had decided early in the project that they did not want spliced speech used in the 511 system. During discussions with the CRS contractor, FDOT CRS project management was convinced that spliced speech should be used. Later, FDOT top-level management intervened and the decision to use spliced speech was reversed. The fact that decisions made by FDOT staff working directly with the CRS contractor were often later reversed by higher level FDOT staff led to many miscommunications and damaged client-contractor relations. The continued miscommunications and client-contractor mistrust magnified the ramifications of errors that occurred until the entire CRS software project became too difficult to manage and was abandoned.

Because the CRS software and some of the field hardware did not work as expected, it made it difficult for FDOT to support all of the iFlorida activities it had hoped to pursue. In some cases, planned activities were abandoned or postponed, while other iFlorida activities were completed, though completing them often required FDOT personnel to do things manually that they expected to be automated. The following list summarizes the extent to which FDOT completed the activities that were part of the initial iFlorida plans.

• Deploying new field hardware. FDOT did deploy most of the field hardware needed to support iFlorida operations. Problems with maintaining the hardware sometimes limited its effectiveness. More details are provided below.
  • Network extensions. The FDOT fiber network was extended along a number of roads in order to provide communication to iFlorida field devices. Network connectivity was also established between FDOT and other area transportation stakeholders, including OOCEA, the Brevard County EOC, LYNX, and the City of Orlando IOC.
  • Toll tag and license plate readers. FDOT deployed toll tag and license plate readers on some stretches of toll road managed by the Turnpike Authority, on seven key Orlando arterials, and on evacuation routes between the east coast and Orlando. At the time iFlorida was expected to become operational, many of these readers had failed and FDOT struggled to repair them. During some periods, about 90 percent of these readers would be operational. At other times, this percentage would be much lower.
  • Microloop detectors. Eighteen microloop detectors were deployed on SR 528, a key evacuation route from the east coast to Orlando. Four additional detectors were deployed on a parallel section of SR 520. This data was used to collect travel time data on SR 528, though no hurricane evacuation occurred between the time the loops were available and the time that the iFlorida evaluation ended.
  • Arterial CCTV. Cameras were deployed at a number of key arterial intersections in Orlando, The reliability of these cameras was low, perhaps because their loss did not strongly impact planned iFlorida operations.
  • RWIS stations. FDOT deployed ten RWIS stations in Central Florida, but had a disagreement with the contractor over who was responsible for developing the software to push that data to the CRS. The data was pushed to MADIS, pulled from MADIS by FDOT's weather data provider contractor, and pushed to CRS. This introduced a time lag between the collection of the data and receipt of the data by CRS, which diminished its usefulness. After about one year of operations, the data feed to MADIS was stopped.
  • Statewide monitoring. FDOT initially proposed upgrading 54 existing TTMS stations to provide real-time data, with 48 of the upgrades also providing traffic video. FDOT later decided to deploy 25 new traffic monitoring stations at existing microwave tower sites, primarily to reduce the communication costs. FDOT found that these sites were not very effective at providing information useful to support statewide traveler information and that the cost of maintaining them was high. The SEOC expected that video from those devices would be very useful during a hurricane evacuation, though no evacuation occurred between the time the devices were deployed and when the evaluation ended. As FDOT became aware of the high cost and limited usefulness of these devices, its level of effort in maintaining the equipment dropped. The equipment was often out-of-service and little used.
  • Variable speed limit signs. FDOT deployed variable speed limit signs, but did not use them, principally because of a lack of confidence in the ability of the CRS software to properly manage the VSL messages. After FDOT began using SunGuide, it conducted tests of the VSL signs and determined problems with the signs that prevented their use. As of July 2008, FDOT planned on purchasing new VSL signs to support VSL operations.
  • Bridge security. A bridge security system was deployed that included cameras to monitor the environment around two selected bridges and software to monitor the resulting video. Tests indicated that the system could detect intrusions. However, video failures were common and a high rate of false alarms meant that system alarms were often muted and ignored.
  • Bus security. A wireless broadband network was deployed along a section of I-4 to provide communications for security video and panic buttons that were placed on some LYNX buses. FDOT personnel indicated they had witnessed the system working. However, failures of the communication network foiled several official demonstrations of the system, and persistent failures meant that the system was never used operationally.
  • Laptops for FHP patrol cars. FDOT planned on helping FHP take advantage of the I-4 wireless broadband network by purchasing laptops for FHP patrol cars, giving patrol officers access to iFlorida traffic information. These laptops were not purchased.
• Other Data Collection. In addition to data from the field devices, iFlorida plans called for four other sources of data to support iFlorida traffic management operations.
  • OOCEA travel time server. Independent of iFlorida, OOCEA deployed a network of toll tag readers to measure travel times on the toll roads they managed. FDOT provided the toll tag and license plate readers from its network of readers to this server so that it could compute travel times for FDOT. These travel times were then pushed from the OOCEA server to the CRS software. Although there were some initial problems with the server software (such as determining the best parameters to use on arterials), it worked reliably throughout most of the iFlorida operational period.
  • FHP CAD integration. FHP and the FHP CAD contractor worked with the CRS contractor to develop an interface allowing export of FHP CAD incident data to the CRS. This interface did not work properly, and FDOT did not often use this data for traffic management. Eventually, FDOT quit using this interface entirely and hired another contractor to develop a new, web-based interface that would give RTMC operators access to FHP CAD data.
  • LYNX and GOAA traveler information. The initial plans called for LYNX and GOAA to enter event data (such as bus service disruptions or airport delays) into the CRS, and the CRS would make this information available through the Central Florida 511 system and the traveler information Web site. Instead, LYNX and GOAA developed their own automated phone information system, and the Central Florida 511 system allowed callers to transfer to these other systems.
  • Road weather data. FDOT contracted with a weather data provider to provide current and predicted weather data to the CRS, which was to use it for traveler information, to estimate travel times when measurements were unavailable, and to estimate future travel times. No use was made of this weather data for traffic management. It was not clear whether the expected CRS capabilities were not available or whether other problems with the CRS prevented FDOT from focusing on the use of the iFlorida weather data.
• Traffic Management. The purpose for collecting and obtaining the data listed above was to better support traffic management operations. The following four items describe the status of the iFlorida traffic management activities.
  • The CRS software. The CRS software was expected to consolidate data from all the sources listed above and provide tools that used this data to facilitate traffic management operations. The list below describes the status of the CRS traffic management features.
    • Travel time estimation. The CRS software was expected to estimate I-4 travel times based on speed measurements from I-4 loop detectors. This capability seemed to work most of the time. The CRS software was also supposed to combine travel time estimates to produce travel times appropriate for use on DMSs, in the 511 systems, and on the traveler information Web site. Errors in the CRS software meant that many of these travel times were miscalculated. The CRS was also expected to fill in missing travel time data with historical data and to predict future travel times. These capabilities were not demonstrated during the evaluation period.
    • Incident data management. The CRS software was expected to obtain incident information from the FHP CAD system, allow RTMC operators to enter additional incident information, use that information to help manage DMS and 511 messages, and make incident data available on the traveler information Web site. The software did manage incident information, though problems with the interface to the FHP CAD system meant that RTMC operators had to enter all incident data manually.
    • DMS message management. The CRS software was expected to automatically generate travel time messages for DMSs and to allow RTMC operators to override those with manual messages when appropriate. It was also to allow FDOT to design "sign plans" that could automatically populate signs with appropriate messages when certain triggering events occurred. For example, a crash on I-4 closing a lane could activate a sign plan that posted crash messages on signs near the crash location. When the crash and related congestion ended, the crash messages would automatically be removed. Problems with the travel time estimation process limited FDOT's use of automated travel times. Problems with the interface between the CRS and the signs limited FDOT's use of all the other CRS DMS message management features.
    • 511 message management. The CRS software was expected to automatically generate travel time messages for 511 and allow RTMC operators to override those with manual messages if an incident occurred. These messages were pushed to a 511 service provider, who used them to populate the iFlorida 511 systems. Concerns over the accuracy of the travel times computed by the CRS limited the extent that FDOT used the CRS travel time message generation features. FDOT did regularly use the CRS to manage manual 511 messages.
    • Traveler information Web site management. The CRS software was expected to make traveler information available to the public via a traveler information Web site. The CRS did make traveler information available to the public via a Web site.
  • The CFDW software. The CFDW was expected to archive the data provided to the CRS and generated by the CRS or CRS operators during traffic management operations. It was expected to provide data mining tools to help FDOT use this data to explore its traffic management operations. It was also intended to provide non-FDOT users with access to the data. The CFDW never compiled a useful archive of CRS data. The data mining tools often ran so slowly against the collected data that the tools were never used by FDOT.
  • Central Florida and Statewide 511. The 511 service, which was supported by a 511 service provider, appeared to work well, though voice recognition service often failed to understand spoken commands given by 511 callers.
  • Traveler information Web site. This Web site was available most of the time, though missing data and problems with the CRS often limited the availability and accuracy of the data on the site. FDOT also was very dissatisfied with the look-and-feel of the Web site, as the traffic maps available there were of lower quality than those available from other Internet map providers.
• Auxiliary iFlorida Activities. The iFlorida plans included several activities that were not directly related to day-to-day traffic management. These activities are described below.
  • Network reliability. FDOT had developed a method for determining a quantitative measure of network reliability called the Florida Reliability Method, which reflected the fraction of time that travel time is significantly longer than usual. FDOT planned on using the travel time data collected for iFlorida to conduct a network reliability analysis of Orlando roads. Problems with the CFDW prevented them from completing the network reliability analysis during the evaluation period. FDOT began preparing to conduct this analysis in May 2008 based on data archived by SunGuide.
  • Metropolitan planning. FDOT provided funds to the region's Metropolitan Planning Organization to explore how archived iFlorida data might be used to improve regional planning activities. Problems with the CFDW prevented this activity from occurring. Plans were cancelled in May 2008 after the contractor hired to perform this work reviewed the available data.
  • Probe vehicle test bed. The initial iFlorida plans called for deploying a probe vehicle test bed, which would test the effectiveness of using probe vehicles for collecting traffic data. These plans were abandoned early in the deployment, by mutual agreement between USDOT and FDOT.
  • Traffic modeling for emergency response. FDOT planned to explore the use of traffic modeling applications to test the effectiveness of alternate routes in case a bridge was destroyed or disabled. These plans were delayed because problems with the CFDW limited access to iFlorida data. Work on this project resumed in the spring of 2008 based on data compiled by SunGuide.
  • RTMC vulnerability assessment. FDOT planned to conduct a vulnerability assessment of the D5 RTMC and develop general security guidelines that could be applied at other FDOT RTMCs. This activity was completed as planned.
  • Daytona International Speedway evacuation plan. FDOT planned to work with the Daytona International Speedway to develop an emergency evacuation plan for the speedway and to work with other venue operators in the region in order to identify the role ITS can play in supporting emergency evacuations from large venues. This plan was developed and shared with other venue operators.

Despite the challenges that FDOT faced, it can be readily claimed that the overall iFlorida Model Deployment was successful. When limitations of 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 on 511 messages. 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.

In this way, FDOT ensured continued traffic management operations through all of the technical and operational barriers it faced. The challenges associated with the iFlorida Model Deployment also provided many opportunities to identify lessons learned from the experiences the agency had-lessons that are scattered throughout this report and summarized in the following section.

13.2. Lessons Learned

This section of the report summarizes the lessons learned during the iFlorida Model Deployment. The key lessons listed are taken from the body of the report and organized according to the chapters in this report. Each lesson is listed, and a reference is made to the page in the report on which the lesson is called out.

Deployment and Operating Experience

• The design for TMC software should include stand-alone tools for diagnosing problems with the systems feeding data to it. (See page 17.)
• The TMC software requirements should address the actions that should be taken when different types of failures occur. (See page 18.)
• Devote time at the start of the project to ensure that the contractor shares an understanding of what is desired from the software. (See page 22.)
• Software projects are complex efforts that require skills that are not necessarily common to transportation agencies. Sustaining trained, certified, and knowledgeable staff is a key to success. (See page 23.)
• The cost structure for a software project is significantly different than that for traditional DOT projects. (See page 23.)
• Requesting documentation of detailed testing performed by the contractor can help ensure that appropriate tests are performed. (See page 24.)
• Being involved in the initial configuration of the system can help determine whether the configuration process is overly complex. (See page 24.)
• Contractual requirements can be used to ensure that software fixes can be implemented without disrupting operations. (See page 25.)
• Tools for testing of individual software components can help pinpoint the root cause of problems that may occur. (See page 25.)

Maintaining a Network of Field Devices

• In field equipment contracts, include requirements for tools to monitor the operational status of the deployed equipment and for helping with equipment monitoring once the deployment is complete. (See page 30.)
• Integrate the ITS Group into the construction process to help ensure that consideration of the fiber network is included in construction plans. (See page 40.)
• Installing fiber in visible locations rather than underground can help contractors avoid damaging the fiber. (See page 40.)
• It can be more cost-effective to relocate fiber prior to construction to reduce the likelihood and impacts of fiber cuts than make repairs when cuts occur. (See page 40.)

Using Toll Tag Readers for Traffic Monitoring

• The system design should include design of the video monitoring tests that will be applied. (See page 49.)
• A toll tag travel time system should accommodate many different types of failures that might occur, including reader failures, clock mis-synchronization, incorrect reader location assignments, and network failures. (See page 51.)
• Field studies can help determine if toll tag market penetration is sufficient to support the use of a toll tag travel time system. (See page 53.)
• The effect of diverting traffic on arterials can introduce a high bias into the observed average travel time. (See page 65.)
• For limited access highways, diverting traffic is less likely to introduce a high bias into the observed average travel time. (See page 66.)
• Including tag reads from turning vehicles increases the number of travel time observations generated. (See page 70.)
• It is important that a system to monitor and maintain field equipment be in place by the time any field equipment is deployed. (See page 72.)
• Reader failures will occur. The systems that rely on the readers must be designed to work around those failures. (See page 73.)
• The tag matching efficiency is much higher for limited access roads than for arterials. (See page 76.)
• The tag matching efficiency is much higher for limited access roads than for arterials. (See page 76.)
• The tag matching efficiency drops quickly as the segment length increases. (See page 76.)
• Toll tag readers introduce a delay in producing travel time estimates equal to the estimated travel time. (See page 78.)
• The latency inherent in toll tag based traffic monitoring systems could limit its effectiveness for incident detection. (See page 78.)

Interfacing with the FHP CAD System

• A process must be in place to update incident type translation tables whenever incident types are changed on the CAD side of a CAD-DOT interface. (See page 82.)
• The DOT should work with the Highway Patrol to ensure that practices are in place to enter key information in the correct fields within the CAD system. (See page 82.)
• The use of event-driven messages requires implementation of methods to identify and recover from dropped events. (See page 83.)
• Identify the fields for which the CAD system does not perform strong quality control checks. Those fields may require extra effort to use them within a DOT system. (See page 84.)

Using DMSs for Traveler Information

• Validating all travel time estimates before using them for traveler information can prevent dissemination of false data and possible loss of public confidence in the traveler information systems. (See page 89.)
• Ensure that the TMC software supports automated generation of common types of messages, such as congestion messages. (See page 96.)
• Design the TMC management software to automatically produce the types of messages that are used often and change frequently. (See page 96.)
• The software used to manage travel time messages on DMSs should include methods for managing sign messages when travel times are unavailable. (See page 96.)

Implementing Variable Speed Limits

• Identify statutory and regulatory speed limit requirements before considering the use of variable speed limits. (See page 103.)
• The concept of operations for VSL should be validated against historical data. (See page 110.)
• The algorithms for recommending speed limit changes should be able to detect and correct for low vehicle speed observations that are not related to congestion. (See page 110.)
• Operator approval should be required for all speed limit changes (See page 110.)
• A VSL system should not be deployed until the other systems required to support it are operating reliably. (See page 111.)

Statewide Operations

• A key to making use of a microwave network is accommodating its bandwidth limitations. (See page 117.)
• Microwave tower locations should not be the primary factor in selecting locations for traffic monitoring stations. (See page 118.)
• Travel costs can make the costs of maintaining a statewide traffic monitoring System high. (See page 118.)
• Involving all other DOT districts in the design of a Statewide Monitoring System may make it easier to distribute maintenance responsibility for these stations across the districts. (See page 119.)
• Interfacing with local police organizations to obtain more complete incident information may be a better source of statewide traveler information than a statewide monitoring system. (See page 120.)
• A Statewide Monitoring System may be too sparse to consistently provide useful traveler information. (See page 121.)
• The FHP CAD was the primary source of statewide traveler information. (See page 122.)

Evacuation Operations

• Difficulties with the iFlorida deployment limited the impacts on Florida evacuations that occurred. (See page 127.)
• The determination of whether to use contraflow depends on estimates of future demand. Real-time traffic data is of limited use in making this estimate. (See page 135.)
• A tool that integrated current traffic condition data would be a valuable tool for supporting SEOC traffic management decision making. (See page 135.)
• The distributed model for emergency management used in Florida worked very well. (See page 136.)

Traveler Information Operations

• Limiting the number of 511 segments for each road simplified the menu structure for choosing a segment. (See page 145.)
• Dividing 511 segments into sub-segments for reporting travel times allowed more detailed travel time information to be presented. (See page 146.)
• Pre-recorded travel time messages for all road segments reduced message splicing and increased audio quality. (See page 149.)
• The use of FTP to update 511 messages allowed for continued 511 service even when the TMC management software failed. (See page 149.)
• Monitoring feedback helped adapt the call tree to better meet user expectations. (See page 151.)
• Monitoring user requests that could not be interpreted by the system allowed new phrases and pronunciations that should interpreted by the 511 system to be identified. (See page 152.)
• Travel time summaries were used in the 511 system to provide travel times for alternate routes between pre-defined locations. (See page 152.)
• Transitioning to a new 511 system may alienate existing users accustomed to the former system. (See page 154.)
• Most 511 calls are made while users are on the road. (See page 156.)
• About 5 percent of days had much higher than usual 511 call volumes, and those days often occurred in conjunction with unusual traffic incidents. (See page 159.)
• A significant percentage of the drivers of vehicles impacted by an incident appeared to call the 511 system. (See page 160.)
• 511 users made few traffic information requests for arterials. (See page 163.)
• The percent of I-4 travelers using the 511 system for information on I-4 traffic is very small-too small to have a measurable impact on traffic conditions and congestion. (See page 164.)
• Caller requests to regional 511 systems may focus on traveler information, with few callers requesting transfers to other 511 systems. (See page 165.)
• The My Florida 511 system, a personalized 511 sytem, required fewer commands to access traffic information and provided callers with traffic information more quickly. (See page 166.)
• The percent of calls made by by My Florida 511 users, a personalized 511 service offered by FDOT, did not increase over time. (See page 167.)
• Very few 511 users appeared to regularly use the system as part of their daily commute planning. (See page 170.)
• 511 implementers should consider establishing and monitoring metrics on the effectiveness of the speech recognition used in their 511 system. (See page 172.)
• Populating the Statewide 511 system with high quality traffic information was challenging. (See page 176.)
• In most months, relatively few callers requested traffic information from the Statewide 511 system. (See page 180.)
• Reviewing mock ups of highly graphical user interfaces, such as map interfaces, before starting development of the interface can help ensure that the resulting interface is esthetically pleasing. (See page 184.)
• The Web site requirements should include details about the types of tracking information that should be maintained about Web site users. (See page 186.)
• Traffic data collected by FDOT was the basis for traveler information services provided by both regional and national traffic information providers. (See page 189.)

Weather Data

• Providing RWIS data to the MADIS mesonet or to the Clarus system will make the data available to the meteorological community. (See page 195.)
• When systems that must interact are being developed by different contractors, the contractual language for those contractors should specify how the systems will interface and who is responsible for developing each part of the interface. (See page 196.)
• The contract with a data provider should clearly describe the data that will be provided and its format. (See page 196.)
• The design of the system that uses provided data should be complete before a contract with a data provider is put in place. (See page 197.)
• A coordinated master schedule should be maintained that reflects the dependencies between the projects. (See page 198.)
• Interface documentation should clearly describe the data that is passed through the interface. (See page 198.)

Security Projects

• The system design should include design of the video monitoring tests that will be applied. (See page 204.)
• System testing should include verifying that the number of false alarms is not excessive. (See page 204.)
• The system design should include alarm plans for normal operations and other alarms plans that might be used during construction activities. (See page 206.)
• The design for a TMC should include standoff distances that help maintain a clear space around the building. (See page 210.)

13.3. Conclusions Related to iFlorida Evaluation Hypotheses

One of the first steps taken in conducting the iFlorida evaluation was development of the Evaluation Plan, a document that described specific hypotheses that would be explored during the iFlorida Model Deployment. Many of these hypotheses were explored, while some were not because of the various problems that occurred during the evaluation. This section of the report lists the original evaluation hypotheses and identifies any conclusions that were drawn related to each hypothesis or, when no conlusions could be drawn from the model deployment, describes why that occurred. The hypothese are arranged in the order they appeared in the iFlorida Model Deployment Evaluation Plan, as published in April 2005.

13.3.1. The Design Review Hypotheses

The Design Review was a crosscutting study that focused on documenting the experiences of the iFlorida Deployment Team during the design process. There were no hypotheses, per se, for the design review. Instead, different activities were defined that would gather information for the evaluation. The planned evaluation activities are described in the following list, with more information available in two previously published reports, iFlorida Model Deployment Design Review Evaluation Report and iFlorida Model Deployment-Deployment Experience Study, and in section 2 of this report.

• Document the iFlorida system engineering process. FDOT did not strictly follow standard systems engineering practices for the CRS software. FDOT provided high-level functional requirements to the CRS contractor at the start of the project. The CRS contractor adopted these as detailed requirements without further refinement, and modifications and refinements of these requirements occurred throughout the CRS development. In the end, the CRS software was abandoned and replaced with SunGuide software.
• Document the iFlorida design. The iFlorida design is documented in parts throughout this report. For example, iFlorida traffic operations are described in section 1.1.1.
• Document the basis for key iFlorida design decisions. Key iFlorida design decisions were documented during the evaluation.
• Document the use of data quality and message set standards. Previous reports addressed about data quality and message set standards. Information about the use of IEEE 1512 standards for FHP-CAD is described in section 5 of this report.
• Document methods for ensuring data quality. Inadequate methods were implemented to ensure data quality, and FDOT experienced significant problems with data quality, both in terms of data availability and accuracy of data that was available. These issues are addressed in section 2 of this report.
• Document privacy and security issues regarding iFlorida data and methods used to address those issues. Because the data warehousing features of the iFlorida deployment did not function correctly, FDOT did not address privacy and security issues regarding the data.
• Document integration challenges regarding the iFlorida data and methods used to overcome them. FDOT experienced a number of challenges in integrating data from different sources. These challenges are described in section 2 of this report.
• Document the business and data management practices planned for the iFlorida data. One of the weakness of the iFlorida Model Deployment was the lack of a clear concept of operations, so that neither their business practices for how to best take advantage of the iFlorida data were nor their practices for managing the data were well defined.

13.3.2. The Deployment Experience Study Hypotheses

The Deployment Experience Study was a crosscutting study that documented the experiences of the iFlorida Deployment Team while deploying the iFlorida infrastructure. The planned evaluation activities are described in the following list, with more information available in two previously published reports, iFlorida Model Deployment Design Review Evaluation Report and iFlorida Model Deployment-Deployment Experience Study, and in section 2 of this report.

• Document the effectiveness of the iFlorida system engineering process and lessons learned in applying it. FDOT experienced significant problems with developing the CRS software, and the root cause of many of those problems can be traced to a failure to follow standard systems engineering practices.
• Document the actual deployment costs and schedule and the reasons for changes that occurred. The deployment costs of the deployment activities are scattered throughout this report.
• Document data quality challenges that were faced and how those challenges were overcome, and document the results of data quality tests. FDOT did not perform adequate tests of data quality and suffered from data quality issues throughout much of the model deployment. Data quality problems were related to both failures of field devices and software mismanagement of data received from those devices. Sections 2 and 3 of this report describe data quality challenges that FDOT faced.
• Document privacy and security challenges that were faced and how those challenges were overcome. Problems with the operation of the CRS and CFDW software meant that there was little usage of the iFlorida data outside of FDOT, limiting the extent to which FDOT was faced with privacy and security challenges regarding that data.

13.3.3. Metropolitan Operations Hypotheses

The primary objective of the iFlorida metropolitan operations was to collect traffic data, use that data to support operational and programming decisions, and provide metropolitan services such as Orlando 511, roadway diversion information, and variable speed limits. This element of the evaluation examined the impact of the iFlorida deployment on transportation system operations in the Orlando metropolitan area by documenting the ways iFlorida changed operating practices and evaluating the impact of those changes. For the purpose of the evaluation, the metropolitan operations were divided into groups of related activities. These groups and the evaluation hypotheses related to each are described in the following lists.

Transponder and license plate readers travel time measurements

FDOT deployed an extensive collection of transponder readers to measure travel times on arterial roads and a small number of license plate readers. The license plate readers saw little use. The transponder readers were used extensively to generate travel time information. Information about these readers

• The travel time data will be reliable. Early in the deployment and at different times throughout, FDOT experienced significant problems with maintaining their network of toll tag readers. At its best in February 2007, toll tag based travel times were available about 90 percent of the time, though this percentage was often below 70 percent.
• The travel time data will be accurate. The travel time data produced by the toll tag readers appeared to be accurate, though achieving this accuracy required algorithms for excluding travel time observations for vehicles that made stops. Some segments produced too few travel time observations for accurate travel time estimation, and most produced too few observations during periods of low usage, such as late at night.
• The approach will be cost effective. The approach was effective for producing arterial travel time information, information that is difficult to obtain through other types of measurement. However, the maintenance cost of the toll tag reader system was higher than expected and the 511 demand for arterial travel time information was low.

More information about these readers can be found in sections 3 and 4 of this report.

Variable speed limit trial

The iFlorida VSL capabilities were not utilized during the deployment. As the evaluation period ended, FDOT was preparing to enable their VSL signs.

• Document how VSL is used (e.g., to reduce speeds in response to weather conditions, to reduce speeds prior to an incident-induced queue). VSL was not used.
• The infostructure will provide the data needed to trigger variable speed limits. One of the reasons VSL was not implemented was a lack of confidence in the CRS capabilities to support VSL operations.
• Travelers will comply with the variable speed limits.VSL was not used.
• VSL will increase safety (if VSL is used in that manner). VSL was not used.
• VSL will decrease congestion when an incident occurs on I-4 (if VSL is used in that manner). VSL was not used.

More information on the iFlorida VSL system is available in section 7 of this report.

Roadway Diversion Study

FDOT used two DMS's along I-4 to provide information to travelers about the travel times on two alternate routes to and around Orlando. The shorter route was along I-4, but was prone to congestion, and the longer route was along a toll road, SR 417. FDOT also sometimes displayed incident-related detour information on other DMSs.

• Document how roadway diversion is used (e.g., during normal operations, during incidents, types of messages used). FDOT displayed travel times for both routes only when the travel time along SR 417 was shorter (i.e., when I-4 was congested).
• The infostructure will provide the data needed to trigger roadway diversion messages. The loop data was sufficient to support diversion messages, though early in the deployment the CRS software sometimes displayed travel times that were computed incorrectly.
• Travelers will change routes based on roadway diversion messages. Traveler route changes were difficult to assess from available data.
• Roadway diversion will decrease congestion and increase network reliability. The data indicated increasing congestion on I-4 throughout the iFlorida operational period.

More information about the roadway diversion messages is available in section 6.2.2 of this report.

Laptop usage by FHP patrol cars and Road Rangers

FDOT planned to provide laptops to FHP patrols and Road Rangers that would take advantage of the wireless broadband deployed along a portion of I-4 to support the LYNX Bus Security project. These laptops were not purchased.

• Laptops will be useful to FHP patrols and Road Rangers. The laptops were not purchased.

Evaluate the use of the iFlorida infrastructure for traveler information

FDOT used iFlorida data to support many modes of traveler information, including 511, a traveler information website, and DMS's.

• Document the effectiveness of the metropolitan traveler information system. The Central Florida 511 system handled a large number of 511 calls each day, though the number of calls did not increase significantly over pre-iFlorida levels. The traveler information website saw little usage. DMS's were used throughout iFlorida operations, though limitations of the CRS prevented the use of automated sign message generation capabilities.

More information on iFlorida traveler information capabilities is in sections 6 and 10 of this report.

Evaluate the use of the iFlorida infrastructure to manage recurring congestion

FDOT took advantage of the new iFlorida traffic monitoring and traveler information capabilities to improve their traffic management processes. However, problems with the CRS software prevented them from implementing some features (e.g., VSL, automated sign message plans). Also, recurring congestion in the Orlando area is concentrated on I-4 and many traffic monitoring and traveler information capabilities along I-4 were in place before iFlorida began. Early in the evaluation, it was expected that coordination might occur between FDOT and other Orlando traffic operation centers to improve response to congestion. For example, sign messages could encourage detours onto nearby arterials when I-4 was congested, and signal timings on those arterials could be modified to better accommodate the diverting traffic. FDOT expected the CRS software to provide the data sharing capabilities key to supporting this type of coordination. When the limitations of this software became apparent, this type of coordination effort ceased. Greater coordination began to emerge once FDOT began using the SunGuide software.

• Document how the iFlorida infrastructure is used at traffic operation centers (e.g., the D5 RTMC, the Orlando IOC, the OOCEA operations center) to manage recurring congestion. FDOT's relied primarily on the dissemination of traveler information to help manage recurring congestion.
• Document organizational challenges that were faced in coordinating congestion management practices among the Orlando traffic operation centers. The failures of the CRS software prevented coordinated congestion management practices from developing.
• iFlorida will decrease traffic congestion. Congestion management practices changed little during iFlorida operations, so impacts on congestion were not expected and detailed analyses were not performed. Reports on the use of Trailblazer signs to provide detour information to travelers leaving the Daytona International Speedway after an incident closed all lanes on I-4 indicated that these signs reduced congestion by helping travelers follow detour routes.
• iFlorida will increase traffic safety. Congestion management practices changed little during iFlorida operations, so impacts on congestion were not expected and detailed analyses were not performed.

Evaluate the use of the iFlorida infrastructure to manage incident response

It was anticipated that the iFlorida infrastructure would change incident response activities on Orlando arterials by providing improved traffic monitoring capabilities on those roads. The problems with the CRS software meant that iFlorida traffic monitoring capabilities were not shared with other Orlando traffic operation centers, so the impact of the deployment on incident response for those roads was limited. Because I-4 was already closely monitored before iFlorida, the iFlorida deployment did little to change incident response on those roads.

• Document how the iFlorida infrastructure is used at traffic operation centers (e.g., the D5 RTMC, the Orlando IOC, the OOCEA operations center) to manage incident response. FDOT used traffic monitoring cameras to identify incidents that occurred on I-4 and shared that video with FHP dispatchers co-located at the D5 RTMC. When an incident involved a lane closure, FDOT would post incident-related messages on DMS's upstream from the incident and on the 511 system. iFlorida data was not used at other traffic operation centers.
• Document organizational challenges that were faced in coordinating incident response practices among the Orlando traffic operation centers. Little new coordination occurred as a result of the iFlorida deployment.
• iFlorida will decrease incident-induced congestion. Because incident response practices changed little because of the iFlorida deployment, no significant impact was expected.
• iFlorida will decrease secondary accidents. Because incident response practices changed little because of the iFlorida deployment, no significant impact was expected.

Document the use of the iFlorida infrastructure to manage transit operations

It was anticipated that iFlorida data would be available to LYNX and LYNX might use that data to better manage their transit operations. Problems with the CRS software meant that the iFlorida data was not shared with LYNX.

• Document how the iFlorida infrastructure is used at the LYNX transit operations center. iFlorida data was not available at the LYNX transit operations center.

Other evaluation activities

• Document how the iFlorida infrastructure is used at transportation management centers in Orlando. It was anticipated that several transportation management centers in the Orlando area would adopt the use of the CRS software, and that the shared software and data would help improve operations at these centers and coordination between them. Several organizations began making plans with FDOT to do just that early in the deployment, but those plans were halted when the inadequacies of the CRS software became apparent. Those talks resumed when the SunGuide software proved more reliable.
• Document lessons learned in operating a metropolitan infostructure. The difficulties FDOT faced in reaching full operational performance from iFlorida prevented the type of coordination required for a metropolitan infrastructure to form.
• iFlorida will result in improved system performance. The type of area-wide coordination that was expected to increase performance did not occur.

13.3.4. Statewide Operations Hypotheses

The primary objective of the iFlorida statewide operations was to collect traffic data from across the state to support statewide traveler information services and hurricane evacuation activities. This element of the evaluation focused on the effectiveness of those activities, with the following lists describing the specific evaluation hypotheses that were planned. Section 8 of this report provides more details on the evaluation of statewide operations.

Using Microwave Communications to Transmit TTMS Data

FDOT deployed a collection of 26 traffic monitoring stations across the state and used an existing microwave communications network to provide connectivity between those stations and D5.

• The TTMS data will be reliable. The microwave communication system proved itself to be a reliable way to provide connectivity to remote field devices. However, FDOT found that the field devices were costly to maintain and that the data produced had limited value. As FDOT focused maintenance efforts on other equipment, these devices fell into disrepair.
• The TTMS data will be accurate. The data provided by the TTMS appeared to be accurate.
• The approach will be cost effective. The use of the microwave communication system was a low cost approach for connecting remote devices. However, utilizing the network required placing devices near the towers, which sometimes meant they were not placed at the optimal locations for traffic monitoring. This reduced the usefulness of the resulting traffic monitoring. FDOT found that the resulting data was not very useful for supporting statewide traveler information systems and noted that the money spent on TTMS might have been better spent on developing interfaces to additional CAD systems throughout the state.

Hurricane Operations

The main impact of statewide operations on hurricane evacuations was expected to be the availability of additional data through the TTMS. A video feed was established from D5 to the SEOC to carry TTMS video. Traffic data from the TTMS was not available to the SEOC.

• Document the effectiveness of the statewide data in supporting hurricane evacuations. Several hurricanes struck Florida while iFlorida was being deployed, but none struck once the deployment was complete. Observations during the hurricane evacuations that occurred prior to the iFlorida deployment provided some insights into the potential impacts of the deployment on hurricane evacuations. Interviews with SEOC staff indicated that the availability of statewide traffic video from the TTMS was expected to greatly increase situational awareness of statewide traffic conditions during a hurricane evacuation.

Section 9 of this report focuses on the impact of iFlorida on evacuation operations.

Evaluate the use of statewide data for traveler information

The iFlorida deployment established the first statewide traveler information services in Florida – a statewide 511 system and a traveler information website.

• Document the effectiveness of the statewide traveler information system. The statewide traveler information services saw limited use except during specific events, such as wildfires that caused road closures. Many statewide 511 callers used the system as a gateway to reach regional 511 systems.

Section 10 focuses on iFlorida traveler information services.

Other evaluation activities

• Document the uses of iFlorida statewide data. The CFDW software, which was to be create a data archive of iFlorida data and provide interfaces for real-time access to that data, did not function as expected. There was little opportunity for users to access iFlorida statewide data.
• Document lessons learned in operating a statewide infostructure. Many lessons learned were documented related to the collection and use of statewide traffic information. However, the failure of the CFDW software meant that a statewide infostructure was never established.

13.3.5. Evacuation Operations Hypotheses

The main impact of statewide operations on evacuation evacuations was expected to be the availability of additional data to support evacuation decision making and increased coordination among regional traffic management centers during an evacuation. The limitations of the CRS software limited the availability of the iFlorida data to evacuation decision makers in the Orlando area and the extent to which additional coordination could occur. The fact that no hurricane evacuations occurred after iFlorida became operational also limited the ability to assess the impacts of the deployment on evacuation operations. Section 9 of this report focuses on the impacts of iFlorida on evacuation operations. The following lists summarize the results related to the original evaluation hypotheses that were proposed for this element of the evaluation.

Contraflow operations on SR 528

One of the planned contraflow routes in Florida runs along SR 528 from the east coast of Florida to Orlando. The iFlorida deployment increased traffic monitoring along this route by deploying micro-loop detectors, license plate readers, and CCTV monitoring.

• Document how the evacuation route monitoring data will be used to support contraflow decision making and monitoring. The evaluation team witnessed contraflow decision making during Hurricane Frances while the iFlorida deployment was underway. Because the decision to implement contraflow was made a day ahead of implementation, the value of real-time traffic data to support this decision seemed limited. The decision was based more on expected traffic volumes for the following day. Because the State did not consider implementing contraflow on SR 528 after iFlorida became operational, it was unclear if the availability of real-time data would change the contraflow decision-making process.
• The evacuation monitoring data will be reliable. The evacuation monitoring equipment tended to be out of service more often than other equipment that was more key to FDOT D5's day-to-day operations, but still showed a relatively how level of service. More information is available in Section 3.3 of this report.
• The evacuation monitoring data will be accurate. The data appeared to be accurate.
• The available data will support contraflow decision making processes. Because no hurricane evacuations occurred in Florida while the evaluation was active, the evacuation monitoring data was not used to support contraflow decision making. Observations of the contraflow decision-making process while iFlorida was being deployed indicated that real-time traffic monitoring data might provide little help in contraflow decision making.

Monitoring high wind conditions on the SR 528 Causeway Bridge

FDOT deployed wind speed monitors on the SR 528 Causeway Bridge with the expectation that this data would help with the determination of when to close the bridge because of unsafe conditions created by high wind speeds. Because this data reached FDOT through MADIS, the data arrived after a 15-minute delay, reducing its usefulness for real-time decision making. The bridge closure decision was also typically made based on observations by personnel stationed at the bridge rather than on observed wind speeds.

• Document how the RWIS data will be used to support monitor wind conditions on the bridge. Both the planned and actual usage of this data was documented.
• The RWIS wind speed data will be reliable. The wind speed data appeared to be reliable, though the network path through which FDOT received the data introduced significant delays.
• The RWIS wind speed data will be accurate. No specific tests of the accuracy of this data were conducted.
• The available data will support bridge closure decision making processes. The data had limited impact on bridge closure decision making. The 15-minute delay between data collection and receipt of that data by FDOT limited the usefulness of the data for bridge closure decision making. Also, the FHP bridge closure process emphasized the observations of personnel stationed at the bridge rather than wind speed measurements.

More information on the bridge wind speed monitors is included in section 11 of this report.

Brevard County EOC, SEOC, D5 RTMC, and Orlando IOC Evacuation Operations

When the iFlorida deployment began, it was expected that many of the regional operation centers would have access to the CRS software, which would give them access to the software and facilitate more coordinated decision making. Problems with that software meant that it was not adopted by other operation centers, which limited the impact of iFlorida on both traffic management and evacuation operations.

• Document how the iFlorida infrastructure will be used to support evacuation decision making and monitoring at these operation centers. The iFlorida data was not available at centers other than the D5 RTMC.
• iFlorida will improve emergency operations at these operation centers. iFlorida had little impact on emergency operations at these centers.

HEADSUP

HEASUP is a software tool that we being developed by FDEM to support hurricane evacuation decision making. At the start of the iFlorida deployment, it was anticipated that iFlorida data would provide real-time information about statewide traffic conditions to HEADSUP. Difficulties with maintaining the statewide traffic monitoring stations and problems with the CFDW software, which was to include interfaces allowing access to the iFlorida data, discouraged FDOT from pursuing this activity.

• Document how the iFlorida data will be used in FDEM's HEADSUP software. iFlorida data was not provided to FDEM.

Evacuation Exercises and Simulations

Limitations in the data archives created by the CFDW software prevented FDOT from performing these exercises and simulations while the CRS and CFDW were in use. FDOT began these activities once the SunGuide data archiving services became available and a reasonable store of archived data was available.

• Document how evacuation exercises and simulations were used to improve evacuation planning and if these activities led to greater use of iFlorida data. These activities were not completed during the evaluation period. FDOT began them in 2008.

Using traveler information to support evacuations

No hurricane evacuations occurred after the iFlorida systems were operational. FDOT did use the pre-existing 511 system to provide traveler information during Hurricane Charley and Hurricane Frances and activated the statewide 511 system during Hurricane Wilma.

• Document how the iFlorida traveler information capabilities will be used to support evacuations. FDOT did not develop a concept of operations describing how their traveler information resources would be used during a hurricane evacuation and no hurricane evacuations occurred so that observations would reveal how these resources were used. Observations during hurricane evacuations that occurred before the iFlorida systems were operational provided some insight into how the iFlorida traveler information resources would likely be used.
• iFlorida traveler information will be an effective means of providing information to evacuees. No hurricane evacuations occurred after iFlorida systems became operational.

Other evaluation activities

• Document lessons learned in using an infostructure to support hurricane evacuations. The lack of an effective infostructure and hurricanes that caused evacuations in Florida limited the opportunities to identify lessons learned.
• iFlorida will result in improved evacuation management. Many of the anticipated improvements were related to improved access to iFlorida data and coordination among regional operation centers. The problems with the CRS software limited both of these factors, so few changes in evacuation management occurred.

13.3.6. Weather Data Hypotheses

FDOT contracted for a vendor to provide real-time weather data to the iFlorida systems. This data included current and forecast weather conditions for iFlorida roads and alerts for severe weather conditions. FDOT also deployed a number of RWIS stations in Central Florida. The weather data provider consolidated this data with the data they were providing and pushed it to the CRS software for processing. It was expected that the CRS software would use this data for a variety of purposes, such as predicting future traffic conditions, suggesting lower variable speed limits when weather conditions were severe, and posting weather-related traveler information messages. Because of the problems with the primary functionality of the CRS software (e.g., calculating travel times, posting DMS messages), little attention was paid to the use of weather data. FDOT is considering re-introducing weather data to their traffic management processes after they gain more experience with the use of SunGuide. More information on the iFlorida weather data is in section 11 of this report.

Providing weather data to an infostructure

• The weather data will be reliable. Anecdotal reports indicated that the weather data was reliable. However, the CRS software disable weather data processing for long periods of time and the CFDW did not correctly archive the data, so it was not possible to verify this.
• The weather data will be accurate. The confirmation of the accuracy of the weather data was deemed outside the scope of this evaluation.
• The weather data will be useful. Little or no use was made of the iFlorida weather data.

Using weather data for variable speed limits

• Document the effectiveness of using weather data to determine appropriate speed limits. Variable speed limits were not used during the iFlorida operational period. Future plans for variable speed limits will base speed limit suggestions on existing traffic conditions, not on weather conditions.

Using weather data for bridge closures

• Document the effectiveness of using weather data to determine when to close bridges because of high wind conditions. Latencies between wind speed observations and the arrival of those observations at the D5 RTMC limited the usefulness of the wind speed data for bridge closure decision making.

Using weather data for traveler information

• Document the effectiveness of using weather data for traveler information. Little use was made of weather data for traveler information. FDOT did sometimes post DMS messages related to heavy fog, though the available weather data was not used as a source of that information.

Other evaluation activities

• Document the uses of iFlorida weather data. Little use was made of the weather data.
• Document lessons learned in using weather data in an infostructure. Some lessons learned were noted related to weather data.

13.3.7. Traveler Information Operations Hypotheses

Before iFlorida, FDOT operated a 511 system that provided traveler information for a portion of I 4 near Orlando. A website was available that listed I-4 travel times, though the availability of this website was not advertised and it was little used. An extensive collection of DMS signs was also deployed along I-4. iFlorida extended the 511 system to include all limited access roads and several key arterials in the Orlando area, created a much more sophisticated traveler information website, and was intended to provide more sophisticated tools for managing DMS message. (The DMS message management tools in the CRS software did not work well.) It also established a statewide 511 system and included statewide data on the traveler information website.

Detailed information on the iFlorida 511 systems and traveler information website is in section 10 of this report. Section 6 provides information on FDOT's management of DMS messages.

Central Florida 511

The Central Florida 511 system experienced a large drop in calls soon after the iFlorida system became operational in November 2005, and call volumes never reached pre-iFlorida volumes. This, despite the fact that the Central Florida 511 system included many additional roads not covered by the previous 511 system, which was limited to I-4. Most callers were interested in information on I-4 and I-95. Some callers interested in information on Orlando toll roads, and the fewest number of callers requested information on Orlando arterials. Few callers could be classified as frequent callers. It appeared that most callers called infrequently in response to observed traffic conditions rather than frequently for trip planning purposes.

• The increase in the quantity and quality of information available will increase 511 usage. The quantity of 511 information increased, though 511 usage decreased. There were concerns that the CRS was miscomputing some travel times, which would have reduced 511 data quality. But, data archives were not sufficient to test this.
• 511 advertising will be an effective way to encourage 511 use. A jump in 511 usage occurred when local media covered the start of iFlorida operations in November 2005, though usage dropped quickly afterwards.
• Customers will value the characteristics of the 511 system (e.g., the menu structure, the quality of voice recognition). FDOT received many complaints about the new menu structure and the capabilities of the voice recognition system soon after the new 511 system began operation. Analysis of call logs indicated that problems with the voice recognition continued throughout the deployment.
• The 511 system will improve traveler mobility. No direct measures of the impact of the 511 system on traveler mobility were computed. However, aalysis indicated that few 511 users called the system was part of their regularly trip planning process, where travel time information would be most effective at improving mobility. Most calls seemed to originate from travelers already on the road after observing unexpected traffic conditions. For those callers, information on travel times would be of limited value for increasing mobility, and information on possible alternate routes might have been more useful.

Central Florida traveler information Website

The CRS software provided a traveler information Website that included statewide and regional maps that displayed information about incidents and congestion, a travel time calculator for the Orlando area, a list of currently displayed DMS messages, a list of current construction activities, a link to images from traffic surveillance cameras, and a link to other traffic information Websites.

• The increase in the quantity and quality of information available will increase Website usage. Website usage remained low throughout the iFlorida operational period.
• Website advertising will be an effective way to encourage Website use. Most advertising concentrated on 511 instead of Website usage.
• Customers will value the characteristics of the Website user interface. FDOT received few comments regarding the Website user interface. However, FDOT was not satisfied with the Website user interface provided by the CRS software.
• The Website system will improve traveler mobility. No measures of the impact of Website usage on traveler mobility were computed. Low usage rates for the Website meant that the site had little overall impact.

Statewide 511

The Statewide 511 system was new to Florida. Although it covered a much broader area than the Central Florida 511 system, it received only about one-third as many calls each day and many of these calls ended with a request to access a regional 511 system.

• The increase in the quantity and quality of information available will increase 511 usage. The Statewide 511 system did not generate a large number of calls and call usage increased little during the iFlorida operational period.
• 511 advertising will be an effective way to encourage 511 use. The media campaign accompanying the start of iFlorida operations in November 2005 resulted in a large number of calls to the Statewide 511 system during the first several weeks of operation. This usage quickly dropped to about 1,000 calls per day and remained at about that level throughout the remainder of the iFlorida operational period.
• Customers will value the characteristics of the 511 system (e.g., the menu structure, the quality of voice recognition). The problems with the voice recognition system already noted for the Central Florida 511 system also applied to the Statewide 511 system. Because a user based did not already exist when the Statewide 511 system began operation, it did not generate as many complaints about the menu structure as did the Central Florida 511 system.
• The 511 system will improve traveler mobility. No direct measures of the impact of the 511 system on traveler mobility were computed.

Statewide traveler information Website

A single application supported both the Central Florida and Statewide Traveler Information Websites, and the observations related to the Central Florida Traveler Information Website noted above apply to both.

Other evaluation activities

• Document lessons learned in operating the iFlorida traveler information systems in an infostructure. The original plans for the iFlorida traveler information systems called for coordinated control of some iFlorida traveler information. For example, the 511 system was going to include information related to the Orlando International Airport, and GOAA was going to have access to iFlorida systems for maintaining this information. Shared control of traveler information capabilities with other organizations was expected. In the final system, GOAA developed its own phone information system, and the iFlorida 511 system provided a linkage to that system. There was no coordinated control of iFlorida traveler information.

13.3.8. Security Project Hypotheses

The iFlorida Model Deployment included five projects related to transportation security. Evaluation hypotheses related to these five projects are discussed in the lists below. More details are provided in section 12 of this report.

Bridge security

FDOT deployed a video surveillance system at two bridges in Florida. The intention of these systems was to automatically monitor the locale around each bridge and generate alarms if the monitoring software detected suspicious activity near a bridge. FDOT and/or FHP staff, warned by the alarm, could access the security video to determine if a response was necessary. These systems generated a large number of false alarms, so that staff regularly muted the alarms.

• The bridge security system will be an effective tool for automatically identifying threats. Tests indicated that the system could identify threats, though the number of false alarms generated was high.

Traffic modeling to assess alternate routes

FDOT planned on using archived iFlorida data to support traffic modeling to assess alternate routes that could be used in case a bridge is damaged and can not be used. The problems with CFDW software limited the data available in the iFlorida data archives, so FDOT postponed this project until the SunGuide data archives were available.

• Traffic modeling will be an effective tool for assessing the viability of alternate routes in case of a bridge failure. The modeling had not been completed when the evaluation period ended.

On-board video surveillance on LYNX buses

FDOT deployed a wireless broadband network along a portion of I-4 and LYNX equipped buses that used that portion of I-4 with video surveillance equipment and equipment to use that wireless network to transmit the bus video back to FDOT and LYNX. The system worked sporadically, although it failed to work during several planned demonstrations.

• The system will decrease the time required to identify, characterize, and verify an emergency event. The system did not work consistently and these capabilites were not tested.
• The system will be effective at preventing and mitigating security incidents on LYNX buses. The system did not work consistently.

The D5 RTMC vulnerability assessment

A vulnerability assessment of the D5 RTMC was conducted, and a follow up assessment was performed.

• The vulnerability assessment will help to decrease the vulnerabilities at Florida RTMCs. The vulnerability assessment identified a number of vulnerabilities, and the follo up assessment indicated that many of the vulnerabilities had been addressed.

The Daytona International Speedway emergency evacuation plan

A study generated an emergency evacuation plan for the Daytona International Speedway and identified some general features that could be considered to improve evacuations at many venues.

• Improvements at the speedway will facilitate faster and more reliable evacuations. Because the evacuation plan was developed in conjunction with a project to refurbish the speedway infield, a before and after comparison of evacuation capabilites could not be performed.
• Improvements at the speedway will facilitate faster and more reliable access for emergency services. The evacuation plan identified specific access routes for use by emergency services.
• Document lessons learned in preparing the emergency evacuation plan and applying it to other venues. Several lessons learned were identified by reviewing evacuation plan documentation.

13.3.9. Data Availability Hypotheses

One of the objectives of the iFlorida deployment was to create a central repository of traffic information that included methods that different organizations could use to access iFlorida data. This would include access to archived, historical data as well as access to real-time data. The CFDW software, which was to create this data archive, did not work as intended. It did not create a useful archive of historical data and it did not provide good tools for accessing either historical or real-time data.

FDOT remedied this, to some extent, by saving archives of much of the iFlorida raw data. For example, they saved logs that listed the DMS messages that were displayed and text files that listed the loop detector readings from I-4 and I-95. Because these data were saved in a variety of formats (e.g., Access databases, text files, XML files), the data was difficult to access and use. Also, the data did not include any information about the quality of the data - data from loop detectors producing erratic data was archived in the same way as loop detectors that produced reliable data. Appropriate use of the data required required analysts to test for data quality problems before making use of the data.

Operating the CRS / CFDW

• Document the costs, benefits, and lessons learned in operating the CRS / CFDW. The CRS / CFDW did not operate as expected.

Data quality

• The iFlorida data will be accurate. The raw data appeared to be accurate, though the CRS sometimes miscalculated travel times and archived the miscalculated travel times in the data archives.
• The iFlorida data will be reliable. The CFDW data was not reliable because the CFDW software was unreliable. FDOT did archive a significant amount of raw iFlorida data, and these archives were reliable.
• The quality of the iFlorida data will be high. The data quality was not high because the CFDW software did not consistently archive the data - there were large gaps in the available data. The FDOT archives of the data did not include any information about data quality (e.g., marking data as suspect if from a detector that was producing erratic results).

Data accessibility

• Good interfaces will exist for accessing iFlorida data. No interface existed for accessing real-time data and the interface for accessing data from the CFDW was slow and difficult to use. FDOT data archives were in a variety of formats, making them difficult to use.
• Broadband wireless Internet access will be a useful tool. The broadband wireless system on I-4 did not work reliably.
• Business and data management practices will encourage use of iFlorida data. The problems with the CFDW software made iFlorida data inaccessible, and no users (other than the evaluation team) emerged. FDOT did not develop business and data management practices related to the iFlorida data.
• iFlorida data will be widely used. The data was difficult to access and little used.
• iFlorida data will be an effective aid to those who use the data. The data was difficult to access and little used.

Impact of iFlorida on traffic and congestion

• iFlorida will reduce congestion. The fact that the iFlorida deployment did not result in an increased coordinated traffic management activities meant that its ability to reduce congestion was limited.
• iFlorida will improve network reliability. The iFlorida project was to include a network reliability analysis, but this project was postponed because of limitations in the archived data.
• iFlorida will reduce incident-induced delays. The fact that the iFlorida deployment did not result in an increased coordinated traffic management activities meant that its ability to reduce incident-induced delay was limited.

Impact of iFlorida on safety

• iFlorida will reduce accident rates. The fact that the iFlorida deployment did not result in an increased coordinated traffic management activities meant that its ability to reduce accident rates was limited.