Freeway Management and Operations Handbook
Chapter 14 – Transportation
Other TMC documentation includes the following:
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.
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:
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.
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:
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.
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.
Change Management, or Control, is the process by which:
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.
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:
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.
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.
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.)
|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.|
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:
|New York State Department of Transportation||New York State Police||Monroe County Airport Authority||Monroe County Department of Transportation|
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.
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.
2. TMC Pooled Fund Study (PFS) web site (http://tmcpfs.ops.fhwa.dot.gov).
12. "Applied Systems Engineering for Advanced Transportation", CITE (Course Registration is available through the CITE website at www.citeconsortium.org.)
15. "Configuration Management for Transportation Management Systems", 2003 (Available from the TMC Pooled Fund Study website http://tmcpfs.ops.fhwa.dot.gov