1. Introduction and Background

This Implementation Guidance for Integrated Corridor Management (ICM) has been developed as part of Phase 1 (Foundational Research) for the Federal Highway Administration and the Federal Transit Administration (FHWA / FTA) Integrated Corridor Management Initiative. The basic premise behind the ICM initiative is that independent, individual network-based transportation management systems and their cross-network linkages (Figure 1-1) can be operated in a more coordinated and integrated manner, thereby increasing overall corridor throughput and enhancing the mobility of the corridor users. This Implementation Guidance document identifies and discusses the process steps needed to support the development, implementation, and operation of an ICM system. It is intended as a guide for transportation professionals who will be involved in some stage of the life-cycle for an Integrated Corridor Management System (ICMS).

Conceptual diagram of a generic corridor.
Figure 1-1. Schematic of Generic Corridor

This Implementation Guidance should be viewed as a "summary" document. Key issues, considerations and activities are identified herein, but with relatively brief discussions. More detailed information is provided in several supporting documents, including the following work products prepared during the Phase 1 Foundational Research:

Task 2.3. Generic ICM Concept of Operations: This is a high-level Concept of Operations (Con Ops) for a "generic" 15 mile-corridor, consisting of freeway, arterial, bus and rail networks, and serving a central business district. The document's primary purpose is to provide an example of an ICM Con Ops that can be used by agency and network owners as the basis for developing their own corridor-specific and real-world Concept of Operations.
Task 2.4. Requirements: This represents a high-level requirements document for the ICMS to be installed along the generic corridor identified in the aforementioned Con Ops.
Task 3.1. Develop Alternative Definitions for Corridor and Integrated Corridor Management (ICM): This Technical Memorandum discusses key attributes that were identified for possible inclusion in definitions used for the ICM initiative. It also presents final versions of these definitions, incorporating comments by FHWA and the stakeholders.
Task 3.2. Develop Criteria for Delineating a Corridor: This Technical Memorandum presents several guidelines and concepts that need to be considered when determining and delineating corridor boundaries. Its also discusses several approaches for utilizing these concepts and guidelines to identify the boundaries of a corridor.
Task 3.3. Relationship Between Corridor Management and Regional Management: This Technical Memorandum compares and contrasts Integrated Corridor Management and Regional Management, identifying the similarities, differences, and relationships between Integrated Corridor Management and Regional Management.
Task 3.4. Identify Integrated Corridor Management institutional Strategies and Administration: This Technical Memorandum focuses on "institutional integration" and the associated issues and alternatives, such as organizational structures that support coordination and collaboration, participating institutions and the stakeholders, processes for funding and staffing ICM, and inter-agency agreements.
Task 3.5. Integrated Corridor Management Program Planning and Funding: This Technical Memorandum addresses potential funding alternatives for Integrated Corridor Management projects.
Tasks 5.1, 5.2, 5.3. Corridor Types; and ICM Approaches and Strategies: This Technical Memorandum discusses several corridor characteristics that may be used to classify corridors, and identifies those attributes that are most critical in terms of screening and selecting the appropriate ICM approaches. This is followed by a discussion of these operational approaches, including definitions of several ICM strategies for each overall approach. Matrices are also provided for matching a corridor with a specific corridor type and then identifying potential ICM operational approaches and strategies.
Task 5.4. Identify ICM Approaches and Strategies Requirements and Issues: The focus of this Tech Memo is to identify high-level requirements and potential operational, technical, and institutional implementation issues associated with the ICM approaches and strategies.
Task 5.5. Identification of Analysis Needs: This Technical Memorandum identifies existing capabilities to model ICM within corridors, and identifies gaps in current tools that must be addressed in order to allow for effective modeling of ICM.

Additional documents covering the systems engineering process and related activities are also referenced. These various documents, including links to web sites where they may be downloaded, are listed in the Appendix.

Background and Definitions

Definitions are important as they provide the basis for a common understanding, thereby facilitating communication and discussion among ICM stakeholders.

Integrated Corridor Management

Integrated corridor management consists of the operational coordination of multiple transportation networks and cross-network connections comprising a corridor, and the coordination of institutions responsible for corridor mobility. The goal of ICM is to improve mobility, safety, and other transportation objectives for travelers and goods. ICM may encompass several activities. For example:

Cooperative and integrated policy among stakeholders.
Concept of operations for corridor management.
Communications among network operators and stakeholders.
Improving the efficiency of cross-network junctions and interfaces.
Mobility opportunities, including shifts to alternate routes and modes.
Real-time traffic and transit monitoring.
Real-time information distribution (including alternate networks).
Congestion management (recurring and non-recurring).
Incident management.
Travel demand management.
Public awareness programs.
Transportation pricing and payment.

Integrated Corridor Management may result in the deployment of an actual transportation management system (ICMS) connecting the individual network-based transportation management systems (complete with ICMS central hardware and servers, data base, decision support software, joint sharing of command and control activities, etc.); or integrated corridor management may just be a set of operational procedures agreed to by the network owners with appropriate linkages between their respective systems. Regardless of the type of "system" deployed, the process steps and associated activities identified herein are directly applicable.

Corridor

From the perspective of the ICM initiative, a corridor has been defined as a largely linear geographic band defined by existing and forecasted travel patterns involving both people and goods. The corridor serves a particular travel market or markets that are affected by similar transportation needs and mobility issues. The corridor includes various networks (e.g., limited access facility, surface arterial(s), transit, bicycle, pedestrian pathway, waterway) that provide similar or complementary transportation functions. Additionally, the corridor includes cross-network connections that permit the individual networks to be readily accessible from each other. The term "network" is used in the corridor definition to denote a specific combination of facility type and mode.

Integration

The definition of ICM includes the term "coordination" multiple times. Such coordination, and the associated network interconnection and cross network management, requires "integration," a term defined in the dictionary as "making into a whole by bringing all parts together." In the context of ICM, integration is a bridging function between the various networks that make up a corridor, and involves processes and activities that facilitate a more seamless operation. In order to implement ICM, the transportation networks within a corridor (and their respective ITS systems) need to be "integrated" in several different ways, specifically:

Operational integration may be viewed as the implementation of multi-agency transportation management strategies, often in real-time, that promote information sharing and cross-network coordination and operations among the various transportation networks in the corridor, and facilitate management of the total capacity and demand of the corridor.
Institutional integration involves the coordination and collaboration between various agencies and jurisdictions (network owners) in support of ICM, including the distribution of specific operational responsibilities and the sharing of control functions in a manner that transcends institutional boundaries.
Technical integration provides the means (e.g., communication links between agencies, system interfaces, and the associated standards) by which information and system operations and control functions can be effectively shared and distributed among networks and their respective transportation management systems, and by which the impacts of operational decisions can be immediately viewed and evaluated by the affected agencies.

It is emphasized that the various issues associated with operational, institutional, and technical integration are closely related and interdependent; for example, operational integration can be more effective when technical integration has been implemented; successful technical and operational integration typically require institutional integration (and the associated managerial support and funding) as a prerequisite; while ongoing operations and maintenance (considered an operational integration issue) is equally important to the long term technical success of an ICMS.

A Systems Engineering Approach

The ICM Implementation Guidance is based on the principles of "systems engineering," a formal process by which quality is continuously promoted. Systems engineering may be described as a "requirements-driven development process"; that is, the user (i.e., stakeholder) requirements are the overriding determinant of system concept and design, component selection and implementation.

The systems engineering process is often shown as a "V" (Figure 1-2) as a way of relating the different stages in the system life cycle to one another. A key feature of the V model is how it explicitly shows the relationship between work done on each side of the V; for example, the testing activities on the right side of the V are based on the results (e.g., needs, goals and objectives, performance measures, concept of operations, requirements) from the corresponding steps on the left side of the V. Moreover, at any specific stage where deliverables are produced (i.e., the right side of the V), those who are responsible for validating conformance to these documents are engaged to review the results and to begin development of their validation and verification plans.

Diagram of the systems engineering 'V'
Figure 1-2. "V" Diagram

Following the systems engineering process can help ensure that the correct system is designed, and that the system is built correctly. The specific ICM-related functions and process steps associated with each stage are listed in Table 1-1 and described in subsequent chapters. While this may look like a sequential approach, wherein each activity is completed before beginning the next, the actual process is an iterative one, with multiple activities frequently performed in parallel (and possibly some steps accomplished "out of sequence"). Moreover, as the stakeholders move through the process, gathering and analyzing additional information, initial concepts developed during previous steps may be modified. For example, the initial corridor boundaries may be adjusted based on a quantitative analysis of spare capacity and the frequency of events necessitating ICM, with subsequent adjustments possible as a result of detailed modeling of the corridor. These modifications to the corridor boundaries may, in turn, result in the identification of new stakeholders (and related integration issues) or different ICM strategies. This "two steps forward and one step back" is a normal part of the overall process.

Many different processes can be used to plan, develop, design, and deploy an Integrated Corridor Management System. The objective of this ICM Implementation Guidance is not to prescribe a single process that should be universally adopted. If the corridor stakeholders already have a proven process, and it generates the necessary documentation and provides linkages between system testing and system concepts / requirements, then that process should be used. If such a process does not exist, then the process and functions described herein represents a good starting point, with adjustments being made to meet the specific needs of the corridor and its stakeholders.

**Table 1-1. ICMS Development Process**
Stage/Process Steps	References
CONCEPT EXPLORATION Functions: Identify Need for Corridor Management Establish Corridor Stakeholder Group Identify Potential Corridors and Initial Boundaries Result: Stakeholders, Potential Corridor & Boundaries	ICM 3.1, 3.2, 3.4 References 1, 2, 3, 4, 5, 7, 8, 9
SYSTEMS ENGINEERING MANAGEMENT PLAN Functions: Develop management plan for developing the ICM Result: ICM Program Management Plan	References 1, 2, 3
SYSTEM CONCEPTION Functions: Needs Analysis and ICM System Concept, including: Inventory Existing Systems/Data Collection Identify Current Corridor Conditions, Problems, and Needs Establish Corridor Vision and Goals Identify Potential ICM Approaches and Strategies Refine Corridor Boundaries Create Performance Measures and Metrics Define Proposed Changes Develop a System Concept Align with the Regional ITS Architecture Identify Operational Scenarios Identify Implementation Issues (Operational, Technical, and Institutional) Result: Concept of Operations	ICM 2.3, 3.1, 3.2, 3.3, 3.4, 5.1-3, 5.4 References 1, 2, 3, 4, 5, 7, 8, 9, 10, 11, 16
REQUIREMENTS Functions: High level ICMS Requirements Detailed ICMS Requirements Traceability between requirements and needs/concepts Performance Analysis Result: Requirements Document, Revised Corridor Boundaries, Initial ICMS Traceability Matrix	ICM 2.4, 5.4, 5.5 References 1, 2, 3, 4, 5
ICMS HIGH - LEVEL DESIGN Functions: Decompose requirements into alternative architectures Identify and define system interfaces, interconnects, information flows, and overall topology Evaluate / select ICMS Standards Develop ICM System Architecture Consistency with Regional ITS Architecture Continue resolving institutional - related issues (organizational structure, funding, stakeholder responsibilities) Result: High - level Design Document (ICMS Architecture, interfaces, information flows, standards), Design Reviews	ICM 5.4 References 1, 2, 3, 4, 5, 7, 8, 15
ICM DETAILED DESIGN Functions: Decompose each system and sub-system into individual hardware, software, database, etc. components Identify component technologies and design features Evaluate COTS solutions Enhancements or additions to existing ITS systems within the corridor. Design and specify system components System design traceability Which components address which requirements? Are these allocations appropriate and complete? Continue resolving institution-related issues (organizational structure, funding, stakeholder responsibilities) Results: System, Sub-systems, and Component Designs (documented in an ICMS Design Report)	ICM 5.4 References 1, 2, 3, 4, 5,
PROCUREMENT Functions: Define project sequencing and funding Determine the most appropriate procurement mechanism Develop necessary ICMS procurement documents Address Intellectual Property Issues Develop overall program plan for building, operating, and maintaining the ICMS (Budget & Schedule) Operations and Maintenance Plan Resolve remaining institutional - related issues (organizational structure, funding, stakeholder responsibilities) Agreements Results: ICMS Procurement Documents, Project Plan, Operations and Maintenance Plan, Interagency Agreements, ICMS	ICM 3.4, 3.5, 5.4 References 1, 2, 3, 4, 5, 8, 12, 13, 14, 16
IMPLEMENTATION & DEPLOYMENT Functions: Transform the ICMS design(s) into an operating system Software engineering and coding; hardware fabrication System integration and testing and verification Unit, sub-system, system System deployment, verification and acceptance System validation Training and Documentation Development of Responses and Scenario Plans Results: Integration Plan, Verification Plan, Validation Plan, Ops Manual, Maintenance Manual, Response / Scenario Plans	ICM 5.4 References 1, 2, 3, 4, 5, 16
OPERATIONS AND MAINTENANCE/EVALUATION Functions: On-going operations and maintenance of ICMS in accordance with the Operations and Maintenance Plan Performance measurement and evaluation of corridor as a whole Update and Refine ICM strategies and operational procedures/response plans as appropriate Consider expanding ICMS (using systems engineering process) Review and update Institutional Agreements Ensuring that they are up to date as the system and its operation evolves. Results: Improved corridor performance	ICM 3.4, 5.4 References 1, 2, 3, 4, 5, 12, 16
CONFIGURATION MANAGEMENT - Crosscutting Process	Reference 1, 2, 3, 4, 5, 6

Previous | Next