Lesson

Define your agency's expectations of a new system and a robust set of system requirements and then choose the software that meets your requirements.

Utah DOT's experience using configuration management.


4/1/2003
Salt Lake City,Utah,United States


Background (Show)

Lesson Learned

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.


Lesson Comments

No comments posted to date

Comment on this Lesson

To comment on this lesson, fill in the information below and click on submit. An asterisk (*) indicates a required field. Your name and email address, if provided, will not be posted, but are to contact you, if needed to clarify your comments.



Source

Intelligent Transportation Systems at the 2002 Salt Lake City Olympic Games: Traffic Management and Traveler Information Case Study

Author: Mark Nuaimi (Iteris)

Published By: Utah DOT

Source Date: 4/1/2003

EDL Number: 13851

URL: http://ntl.bts.gov/lib/jpodocs/repts_te/13851.html

Other Lessons From this Source

Lesson Contacts

Lesson Contact(s):

Mark Nuaimi
Iteris, Inc.
714-774-5000
mnn@iteris.com


Agency Contact(s):

Lawrence Jessie Glazer
FHWA
213-202-3955
jesse.glazer@fhwa.dot.gov

Lesson Analyst:

Jane Lappin
Volpe National Transportation Systems Center
617-494-3692
jane.lappin@volpe.dot.gov


Rating

Average User Rating

0 ( ratings)

Rate this Lesson

(click stars to rate)


Lesson ID: 2005-00052