Photos of cars on freeway, speeding sign

Freeway Management and Operations Handbook

Chapter 14 – Transportation Management Centers
Page 5 of 5

14.3.4 Documentation

Operating manuals document the procedures used by an agency to deal with the operations of their transportation system. The Management and Operations Committee of the ITS Council of ITE developed an Annotated Outline for a Traffic Management Center Operations Manual. It can serve as a checklist for an agency's manual and includes the sections noted in Table 14-9.

Table 14-9: Operators Manual Table of Comments
  1. Emergency and Other Contact Numbers
  2. Daily Operation
    2.1 Management Center Functions
    2.2 Personnel
    2.3 Hours of Operation
    2.4 Staffing
    2.5 After Hours On-Call Roster
    2.6 Remote Operation
    2.7 Security Procedures
    2.8 Maintenance Checklist
    2.9 Startup/Shutdown
    2.10 Failure Recovery
    2.11 Agency/Jurisdictional Contacts
    2.12 Notification Procedures
    2.13 Contact With Media
  3. Control System Operation Procedures
    3.1 Operator Interface
    3.2 Operational Procedures
    3.3 Incident Management
  4. Maintenance Procedures
    4.1 Routine Maintenance
    4.2 Preventive Maintenance
    4.3 Spare/Backup Equipment
    4.4 Emergency
    4.5 Contract Maintenance
  5. System Operations Logs
    5.1 Operations
    5.2 Maintenance
    5.3 Events
    5.4 Systems Reports
    5.5 Traffic Data
    5.6 Risk Management
  6. Operational Concepts
    6.1 Traffic Control Concept Strategy
    6.2 Traffic Monitoring
    6.3 Data Analysis And Warehousing
    6.4 Interagency Coordination
    6.5 Inter-jurisdictional Coordination
    6.6 Emergency Procedures
  7. TMC Description/System Field Devices
    7.1 Location
    7.2 Access/Security
    7.3 Layout
    7.4 Fire Suppression
    7.5 Power Source/Location
    7.6 HV/AC
    7.7 Data Communications
    7.8 Voice Communications
    7.9 Network Communications
    7.10 Field Device Descriptions

Other TMC documentation includes the following:

  • System Administration Manuals: System administration documentation for a TMC includes manuals, papers and plans of the equipment and infrastructure that exist at or are attached to the TMC. These can include manuals for individual subsystems within the TMC or the network plans, configuration and layout of the LANS and WAN, as well as database schema, configuration and maintenance needs.
  • Maintenance Manuals: Maintenance manuals are necessary for all of the hardware in the TMC. These documents are typically provided by the hardware suppliers and are vital for use in training the maintainers of the TMC hardware.
  • Other Documentation: It is important during any project related to the TMC to document the processes and developments of the project. Therefore, there should be a strong emphasis on project documentation to aid future engineers in long-term maintenance efforts. Other related documentation includes equipment warranties, acceptance test results, and software source code documentation.

14.3.5 Configuration Management

Freeway management programs (and their associated freeway management systems and TMCs) are ongoing endeavors. More often than not, the program and systems are implemented in small increments, with functions and areas of coverage being added over time. The institutional landscape – which influences policy and funding decisions – is also subject to change during the life-cycle. Changes in program and system requirements are therefore inevitable. A goal of a freeway management practitioner should not be to avoid making changes, but to keep the requirements change process under control through a process known as "Configuration Management." Configuration Management includes procedures and techniques that allow the practitioner to consider and evaluate the impacts of proposed changes, and then to track and document those changes that are made.

Configuration management is a part of the systems engineering process and a critical element in the life of any system. It is particularly important in those systems that are software intensive, such as TMCs. But configuration management principles and procedures are also applicable in the broader context of a freeway management program. The concept can and should be expanded to include operations and management strategies – not just technical systems. In other words, the term "configuration" in configuration management can refer to the entire set of items that make up a freeway management program, including policies, system hardware and software, documentation, operational procedures, freeway geometrics and associated infrastructure (e.g., signing and lighting), incident management strategies, work zone procedures, and anything else that makes up the description and embodiment of a the program.

The process is described in more detail in the document "Configuration Management (CM) for Transportation Management Systems" (Reference 15), the contents of which are summarized below. It is noted that the processes and procedures of CM have been developing in the information technology community for many years. Accordingly, Reference 10 makes use of a standard developed and refined in the IT industry – the Electronic Industries Alliance (EIA) Standard 649 National Consensus Standard for Configuration Management (ANSI/EIA-649/-1998), referred to EIA 649. Reference 15 is oriented towards ITS-based transportation management systems. But as is the case with other "systems" processes described herein, by changing a few key terms (e.g., "system" into "program", "TMS" into "freeway operations") and expanding the context, the CM process can be "converted" and used for the overall freeway management and operations program.

14.3.5.1 Introduction

There are two fundamental purposes of Configuration Management (CM) – to establish system integrity, and to maintain system integrity. A system with integrity is one in which:

  • All components are well defined and documented
  • A working baseline is always available to implement and provide transportation management services
  • Integration with other regional systems can readily be accomplished
  • A high degree of traceability exists, allowing one to easily identify how system functions are provided.

In other words, a system with integrity is one that is available and functional.

CM provides a holistic approach for effectively controlling system change. It helps to verify that changes to subsystems are considered in terms of the entire system, minimizing adverse effects. Changes to the system are proposed, evaluated and implemented using a standardized, systematic approach that ensures consistency. All proposed changes are evaluated in terms of their anticipated impact on the entire system. CM also verifies that changes are carried out as prescribed and that documentation of items and systems reflects their true configuration. A complete CM Program includes provisions for the storing, tracking and updating of all system information on a component, subsystem and system basis. This provides TMS managers with an up-to-date baseline of their system.

The CM process may be (and ideally should be) applied throughout the system life cycle. This allows TMS management to track requirements throughout the life cycle through acceptance and operations and maintenance. As changes are inevitably made to the requirements and design, they must be approved and documented, creating an accurate record of the status of the system. The general CM process is described graphically in Figure 14-12.

drawing showing an overview of the configuration management process

Figure 14-12: Configuration Management Process (Reference 15) D

14.3.5.2 CM Plan

While not shown in Figure 14-13, a CM Plan is integral to the process. The CM Plan is the document that will guide the CM Program of a particular group. Typical contents of a plan include items such as:

  • Personnel
  • Responsibilities
  • Resources
  • Training requirements
  • Administrative meeting guidelines
  • Definition of procedures
  • Tools/tool use
  • Organization CI activities
  • Baselining
  • Configuration Control
  • Configuration Status Accounting
  • Naming conventions
  • Audits and Reviews

Plans typically are established at the outset of the CM Program and undergo changes as the system evolves and areas where the plan can be improved are identified.

14.3.5.3 Configuration Identification

Configuration Identification refers to the activities and processes dedicated to creating and maintaining full documentation describing configuration items (CIs). A CI may be defined as anything that has a function in the TMS. Therefore, system components, classified in the broad categories of software, cabling, and hardware, are considered as configuration items, in addition to system requirement and design documentation. With most systems, this effort must begin with legacy systems that will be reused in the system being developed. The goal of Configuration Identification is to provide a unique identifier to each item to help track the changes to that item and to be able to understand its place in the system. This, in turn, supports traceability and the change management process.

14.3.5.4 Change Management

Change Management, or Control, is the process by which:

  • The need for a change is identified,
  • The impact of the change on the system (i.e., value, cost, schedule) is analyzed,
  • The proposed change is evaluated by a review body and, if approved,
  • The approved change is incorporated into the existing system with its appropriate documentation.

Change requests are submitted to the relevant administrative body for review. This body is normally referred to as a Change Control Board (CCB). The CCB will review the proposed change, determine its effect on the overall system and decide whether or not to proceed with it. An important part of Change Control is ensuring that the change itself is documented and that the relevant Configuration Item's documentation now reflects that change.

The primary benefit of an effective Change Control procedure is that proposed changes are evaluated in terms of their impact on the entire system. Change Control allows the changes to be reviewed by personnel with a variety of interests and areas of specialty. This minimizes the negative impacts of changes on other components of the system. Change Control also ensures that the changes are properly implemented, and within schedule and cost constraints.

14.3.5.5 Configuration Status Accounting

Configuration Status Accounting is the record keeping and reporting function of the configuration management process, ensuring that all of the relevant information about an item – documentation and change history – is up to date and as detailed as necessary. Configuration Status Accounting involves the following tasks:

  • Collecting, cataloging and maintaining all configuration documentation,
  • Tracking and reporting the status of all proposed changes,
  • Tracking and reporting the implementation status of all approved changes, and
  • Configuration of all system hardware, include those in operational inventory.

Configuration Status Accounting provides a methodology for updating all relevant documentation to ensure that the most current configuration is reflected in the Configuration Identification database, thereby providing decision makers with the most up-to-date information possible. A typical Configuration Status Accounting system involves establishing and maintaining documentation for the entire life cycle of an object. It is ideally carried out in conjunction with Change Control.

14.3.5.6 Configuration Audits

The term "audit" is traditionally thought of in the context of financial statements. Configuration Auditing is based on the same fundamental concept, but it is a process of analyzing Configuration Items and their respective documentation to verify and ensure that the documentation reflects the current situation. In essence, while Change Control ensures that change is being carried out in adherence with the CM Plan, Configuration Audits ensure that the change was appropriately carried out. Configuration Audits are used to confirm that designs or documentation achieve their goals by systematically comparing the requirements with results of tests, analyses or inspections. They are thorough examinations of Configuration Items, comparing the associated documentation and change histories to ensure that the documentation reflects the current state of the Configuration Items.

The most important goal of this process is to prevent lost time on future changes due to inaccurate documentation. If discrepancies are located between the documentation and the Item, the personnel carrying out the audit will prescribe a course of action for remedying the problem.

14.3.5.7 Baselines

The concept of a "baseline" is central in Configuration Management, and in order to effectively implement a configuration management program in a transportation management system, one must fully understand baselines. The concept of a baseline is not new or complex – in fact it has been a key foundation for many civil engineering activities in the past. In surveying, a baseline is a boundary line with fixed end points and known direction. In other words, a baseline is a well-defined, well-documented reference that serves as the foundation for other activities. A baseline in Configuration Management is the same thing – it is a stable, well documented, and thoroughly tested version of the system at some point in its lifecycle. All configuration management activities center upon ensuring that all changes to a baseline are carefully considered and documented so that future baselines will be solid.

Establishing baselines and managing changes to baselines are the key functions of configuration management. Baselines are extremely important to system managers. For example, in the event of system failure, the last established baseline can be recovered in order to maintain system availability. In addition, well maintained and managed baselines allow for smooth transitions when systems are integrated with external entities, or when new contractors or consultants are brought on board to work with the system.

The process of establishing and managing baselines involves identifying what baselines need to be established and when they should be established. The first step of this process is assessing the agency's information requirements and what system elements are to be included in baselines. The next step is determining when it is necessary to institute baselines. It is important to understand that a transportation management system will not have simply a single baseline. In fact, during the life cycle of the system, multiple baselines will be established and maintained. Baselines should typically be established at key system lifecycle milestones, as shown in Table 14-10. (Note – These system baseline definitions can be expanded to include all activities of a freeway management program as shown in the previous "funnel diagram" and discussed at the beginning of this chapter.)

Table 14-10: Baselines in the System Life Cycle (Reference 15)
Concept of Operations Baseline – This baseline is established at the conclusion of the system conception stage. In most cases, this baseline may be considered the formal concept of operations document developed for the system.
System Baseline – This baseline may be considered to be the final functional requirements developed for the system.
Subsystem Baseline – This intermediate baseline between the functional baseline and the development baseline falls after the requirements are completed and preliminary design work has established a mapping of high-level functions to system components.
Development Baseline – This baseline may be considered to be the detailed design document completed before system development begins. Once system development begins, there will be significant pressure to change system design due to a myriad of reasons (desired new functionality, changes in technology, impediments to development, etc.) It is essential to carefully control these changes to design to maintain the integrity of the system.
Product Baseline – This baseline essentially documents the "as-built" design that reflects the completed system. The product baseline is the result of the series of changes that have been made to the original developmental baseline during the system development process. Ideally, if the developmental baseline is under configuration control, the product baseline will simply be the evolution of the developmental baseline through the various system acceptance and verification tests, as governed by the configuration control board.
Operational Baseline – Given the constant pressure for change, transportation management systems are truly "living" systems. In other words, the product baseline will change with time to adapt to the necessary changes. During system operations, it is essential to maintain the operational baseline to reflect changes that have been approved through the configuration management process and implemented.

14.4 Examples

14.4.1 Regional Traffic Operations Center – Rochester, New York

Opened in the winter of 2002, the Regional Traffic Operations Center (RTOC) is a joint transportation facility that was financed by Monroe County Department of Aviation, Monroe County Department of Transportation, and the Federal Highway Administration. The RTOC tenants include staff from Monroe County Department of Transportation (MCDOT), New York State Department of Transportation (NYSDOT), New York State Police (NYSP), and the Monroe County Airport Authority (MCAA). It is a true example of inter-agency partnership and cooperation where personnel of many different agencies who share common goals are working together under one roof. Each agency came in with a different set of needs, as can be seen by this diverse list:

List of Tenants
New York State Department of Transportation New York State Police Monroe County Airport Authority Monroe County Department of Transportation
  • Highway and Traffic Signal Dispatch
  • Expressway Management
  • Traffic Signal Maintenance
  • Troop E Zone 1 Headquarters
  • Local Patrols
  • Snowplowing
  • Field Maintenance
  • Runway/Taxiway Lighting Shop
  • Highway and Traffic Signal Dispatch
  • Highway Lighting Shop
  • Traffic Signal Maintenance

The NYSDOT, MCDOT, and NYSP share a common Traffic Operations Center (TOC) area for dispatch and system monitoring functions, which serves as the centerpiece of the building. These agencies represent the designers, maintainers, operators, and law enforcers of the highway system for the greater Rochester area. The exchange of information flows readily between personnel of the various agencies, facilitating prompt resolution of trouble situations and the occasional unusual service call from a citizen. The building is further complemented by MCAA's Airport Operations unit, which similarly is focused on transportation and dispatching.

The TOC serves as the focal point for the Intelligent Transportation System in the Rochester area, including weather radar, pavement condition sensors, video images, traffic signal control, dynamic message sign control, and highway advisory radio broadcasting. Sharing of the facility has introduced a new collegial spirit as we work together to share resources, information, and problem solving skills. New and different viewpoints, approaches to problem-solving, and routine activities are food for thought and discussion. These result in new synergies that were not possible heretofore.

A large video wall display serves as the central focus of the room. Placed in an ideal location viewable throughout the TOC, the display provides the visual integration of each agency's respective systems. Control of the video wall is available, to a limited degree, to each party. The display elements available include a City/County map of various monitored signalized intersections and freeway segments, video camera data, weather data, news, and roadway sensor data. The display system is expandable and will accommodate future interfaces such as the soon-to-arrive freeway incident management mapping and database.

The RTOC facility also contains a public/media viewing area and a situation/conference room (equipped with its own video projection system). Elsewhere in the building, facilities exist for the installation and support of traffic signal and highway lighting systems. Personnel working in these areas respond to trouble calls and perform service on various traffic signals and highway lighting located within the City of Rochester, Monroe County, and New York State Region Four (which envelopes the surrounding Counties). A well-equipped Signal Laboratory performs system integration / construction services as well as electronic system repair to component level.

One specialty of the RTOC facility is highway incident/ emergency response. The NYSP are a primary response unit for freeway related incidents, while NYSDOT and MCDOT each have deployable resources and remote control of traffic signals and highway message signs. This team can provide on site investigation, maintain traffic flow both at the scene and on adjacent routes, and disseminate information as needed to provide a high level of public safety. For larger scale situations, the facility is conveniently located across the street from the Emergency Operations Center (EOC). A direct fiber optic link between the RTOC facility and the EOC allows video images to be sent to the EOC for projection onto its large screen displays.

14.4.2 Maryland CHART

The Maryland State Highway Administration's (SHA) Statewide Operations Center (SOC) is the hub of the SHA's CHART system. CHART is the highway incident management program initiated in the mid 80's as "Reach the Beach"; a program between the SHA and the Maryland State Police (MSP) to coordinate efforts to assist motorists along the busy corridors leading to the resort beaches on the coast. The program expanded into a statewide program headquartered in Hanover, Maryland where the integrated SOC is located. The 24/7 SOC is supported by part-time satellite Traffic Operations Centers (TOCs) located near College Park, Baltimore, Rockville, and Annapolis. This hub and satellite architecture provides statewide coverage, allowing information to be distributed based on geographical needs and/or expertise, and allows operations to be managed from several different locations. In essence, this centralized communications architecture, and distributed operations architecture allows for statewide control from any of the centers.

Operators at consoles in the control room can monitor traffic on freeways and arterials with the CHART System, monitor and verify incidents with a sophisticated video management system controls dozens of camera throughout the network, and manage a traveler information system of dynamic message signs (DMS), travel advisory radio (TAR), and the internet. Operators can also record TAR messages from their integrated consoles. An MSP liaison works from the center on program and management issues, while a Trooper works from a console in the control room.

During winter months, the SOC acts as the Emergency Operations Center (EOC). As the EOC, SHA maintenance personnel and traffic controllers work together to monitor remote weather information systems throughout the State, and manage snow/ice removal along with traffic, by dispatching plow and salt vehicles, distributing traveler information on roadway conditions and communicating with the media to keep travelers informed of conditions.

The 17,000 square foot, two-story SOC facility has six large screen rear projection systems on a two story high, 40 feet long projection wall. It contains five 6'x8' rear projection systems, one 9'x12' rear projection video wall and twelve 20-inch color NTSC monitors. It also houses a computer / electronics room with the central computer systems, multiple offices associated with the Program, a large training room and conference room / situation room / viewing area. A snack bar / kitchenette is available to the operators for their comfort.

The satellite TOCs are located in State Police Barracks, and operators there can perform any of the functions of the SOC. These TOCs operate from AM peak period to PM peak period, and house Emergency Service Patrols vehicles and staff, as well as Emergency Response Vehicles and staff.

A CHART workstation is also located at the Maryland Transportation Authority's TMC for their use to manage CCTV cameras and DMS along their network. If necessary, this workstation could manage the SHA's statewide network.

14.5 References

1. ITE TMC Committee web site (http://www.ite.org/tmc/index.htm).

2. TMC Pooled Fund Study (PFS) web site (http://tmcpfs.ops.fhwa.dot.gov).

3. "Traffic Technology International" 1998.

4. "TMC Operator Requirements & Position Descriptions"; TMC PFS; 2002

5. "Transportation Management center Functions"; NCHRP Synthesis 270; Transportation Research Board; Washington D.C.; 1998

6. Human Factors Handbook for Traffic Management Center Design.

7. "Guidelines for Developing ITS Data Archiving Systems", Texas Transportation Institute

8. "Freeway Management and Operations: State-of-the-Practice White Paper"; Prepared for Federal Highway Administration, Office of Travel Management; 2003.

9. "Building Quality Intelligent Transportation Systems Through Systems Engineering", Mitretek Systems, April 2002

10. "An Overview of Systems Engineering", FHWA 2-day course

11. "Developing Functional Requirements for ITS Projects", Mitretek Systems, April 2002

12. "Applied Systems Engineering for Advanced Transportation", CITE (Course Registration is available through the CITE website at www.citeconsortium.org.)

13. FHWA Rule 940, National Register, January 8, 2001

14. Transportation Management Center Concepts of Operation Implementation Guide; FHWA, December 1999

15. "Configuration Management for Transportation Management Systems", 2003 (Available from the TMC Pooled Fund Study website http://tmcpfs.ops.fhwa.dot.gov