Intelligent Transportation Systems at the 2002 Salt Lake City Olympic Games: Traffic Management and Traveler Information Case Study
The Utah Department of Transportation contracted for several reports on the development, deployment, and operation of ITS in the Salt Lake City Region. CommuterLink is a network of traffic sensors, closed-circuit television, variable message signs, highway advisory radio, freeway ramp meters, internet information site, and other traffic-management and traveler information services, all of which are integrated into a Traffic Operations Center. CommuterLink’s purpose was to provide advanced transportation management and traveler information capabilities in the Salt Lake City area. The 2002 Winter Olympic Games in Salt Lake City added new functional requirements and a firm deadline for deployment.
This case study was performed to examine UDOT’s procurement and deployment efforts related to ITS in the region. UDOT followed a unique approach to contracting this deployment. The case study provides an overview of the successes and lessons learned related to configuration management, software selection, the system environment, staff and management roles in the development process, and meeting heavy system demand. This report presents findings from the ITS "Case Study" which primarily focused on deployment efforts before the 2002 Winter Olympic Games. A companion document, the Olympics “Event Study,” assesses how the CommuterLink system was used during the Olympic Games.
Choose software that meets your agency's particular requirements.
In particular, think carefully about using software developed for another agency. While the decision to utilize the Georgia DOT (GDOT) NaviGAtor ATMS software application provided a number of compelling advantages – reduced deployment cost, lower risk, faster deployment schedule -- to the CommuterLink System deployment, there were also some disadvantages that arose from that decision:
Dependency on Operating System: Given that the GDOT system was a Unix deployment, this mandated that the UDOT deployment also be Unix based. Based upon the inputs from project stakeholders, this yielded a more complex design than was probably necessary given the evolution of IT processing.
Commercial-Off-The-Shelf (COTS) Package Changes: One of the key components to the GDOT software application was no longer supported by the commercial vendor. Given the decision by the map vendor to no longer support their product, UDOT had to integrate a new mapping application to the ATMS software. However, another partner on the NaviGAtor ATMS development team (Oregon DOT) had already integrated a new mapping application to the NaviGAtor system and UDOT was able to port that functionality to their use.
Operational Differences: The role of the TMC operators is dramatically different in Utah as compared to Georgia –UDOT operators are empowered to make real time decisions relative to incident management approaches. In the Georgia application, the incident management capability of the system limits the ability of the operators to create VMS messages. The system proposes potential VMS messages from a pre-approved library of messages. In Utah, the operators are viewed as the specialists in the incident management activity and would have preferred an approach that allowed them more flexibility in creating messages to suit the situation.
Lacking Diagnostic Information: The NaviGAtor system also does not currently provide diagnostic information to the operator about field element status. Staff with software development experience are required to access this information within the system – a simple user interface is not provided.
Incident Management Tailored for GDOT: There are a number of attributes/settings that are defined for the GDOT needs. One example cited is the incident management code for "road kill." There is no equivalent in UDOT or a desire to categorize "road kill."
Functionality Tied to Hardware Configuration: UDOT staff discovered that some of the functionality of the NaviGAtor system was tied specifically to the hardware configurations of the Atlanta ATMS system. Specific examples include the manner in which video switching / viewing / transport took place. In Utah, the communications design allowed for redundant fiber communication paths for transporting video from the field hubs to the TMC. The NaviGAtor system was designed to control only a single source feed and could not automatically switch control and viewing as the feeds shifted from primary to back-up conditions. This required UDOT staff to hardcode changes to the configuration when the primary feed was lost – changes were made to return the code once the feed was restored. While this demonstrates a software compatibility issue between NaviGAtor and the UDOT TOC configuration, it highlights a key need when reusing a software solution – determine the dependencies on hardware solutions and adapt the hardware design to match the software or customize the software to match the hardware.