ITS - Intelligent Transportation Systems Report ITS Home Page
Table of Contents

4. System Conception

The system conception stage consists of two major activities:

Some of the key questions that must be addressed during this stage are identified in Table 4-1 (modified from Systems Engineering Reference 1).The results are then documented in a Concept of Operations, a formal document that provides a user-oriented view of the Integrated Corridor Management concept and any associated ICM Systems. It is developed to help communicate this view to the corridor stakeholders and to solicit their feedback.

Table 4-1. Key Operational Concept Questions
Needs Analysis
  • What is wrong with the current situation?
  • What needs does the ICMS fill?
  • Have we clearly articulated the need?
  • Do all corridor stakeholders have a common understanding of the Corridor goals and objectives?
Concept of Operations
  • Is our concept consistent with any Architecture(s) with which it must interact?
  • Have we identified all intended users of the ICMS?
  • How will each intended user interact with the ICMS?
  • How is this different from the current situation, if at all?
  • Do the intended users understand their role in the ICMS?
  • Have we coordinated with all other agencies affected by the ICM program and system?


Inventory Exisitng Systems/Data Collection

This process step includes several activities, including:

Inventory

The process of developing a corridor inventory begins with collecting existing information from a variety of sources, including the Transportation Improvement Program (TIP), the Long Range Transportation Plan, the Regional ITS Architecture, any network-specific ITS plan outreach materials, and operational procedures. The inventory should identify each asset — including transportation management centers, roadside and transit systems (e.g., field devices and communications networks), traveler information systems, and other ITS attributes — and provide a brief description that explains the attributes of each asset (e.g., associated organization or network, existing or planned, functionality, standards used). The inclusion of future improvements in the corridor inventory is important because they may factor into the development of an ICMS.

In addition to the technical assets, the inventory should also address the current operational procedures and institutional framework within the corridor. Examples of this information include the following:

The initial inventory should be reviewed with appropriate stakeholders to verify its accuracy and to collect additional inventory information.

Physical and Operational Data

Information on the physical attributes and operations of the corridor are necessary to identify needs, refine the boundaries, and select the most appropriate ICM strategies. Information and data in this regard may include the following:

Regional ITS Architecture

As noted above, one of the sources for inventory information is the Regional ITS Architecture. It is generally assumed that the corridor(s) in question will be part of a larger region for which a Regional ITS Architecture has been developed in accordance with FHWA Rule 9402 (Reference 7) and the associated FTA Ruling (FTA National ITS Architecture Policy Section 5.d.6).

Integrated corridor management builds upon regional management; in this context, an ICMS may be considered a "sub-regional architecture." As such, the development of an Integrated Corridor Management System (and the ICMS architecture) should be compatible and consistent with the regional ITS architecture, which requires an understanding of the various attributes that comprise the regional architecture and the associated management functions. Moreover, the regional ITS architecture may be very useful in developing the corridor management concept and resolving various operational, institutional, and technical issues. For example:

While any integrated corridor management system must be compatible and consistent with the regional ITS architecture, it must be emphasized that corridor management and regional management are not the same thing. The major differences lie in their size and how their respective boundaries are defined, the extent to which individual network operations (and the cross network linkages and junctions) within a corridor are integrated together, and how this integrated corridor is managed and evaluated on a day-to-day basis. Similarities and parallels exist between regional and corridor management with respect to institutional integration (i.e., the coordination and collaboration between network owners and operators) and technical integration (i.e., communications links, interfaces, standards, etc. to support information sharing), but due to the enhanced and expanded operational features of corridor management, additional institutional and technical integration may be required within a corridor as compared to regional management. The differences and similarities between regional and corridor management in terms of their respective integration needs are summarized in Table 4-2.

Table 4-2. Comparison of Regional and Corridor Management
Attribute Region Corridor
Facility Types Includes all surface transportation facilities such as streets, bridges, tunnels, transit routes, airports, ports, etc. Several if not all of the facility types in a region. The corridor-specific facilities are distinguished by the fact that they serve the same or similar travel markets, are adjacent, and are readily accessible from each other.
Boundaries Geographically defined (e.g., jurisdictional and agency boundaries, MPO) No predefined size or scale.
Operationally defined (travel markets and mobility needs, travel patterns, adjacent networks and cross-network linkages). In the context of the ICM Initiative, a region is comprised of several corridors (i.e., a corridor is a sub-set of the region)
Stakeholders Agencies that manage and operate the transportation facilities. Also includes other agencies that are involved with these facilities or have an interest in regional transportation issues (e.g., law enforcement, emergency service providers, MPO). Many if not all of the same regional stakeholders. No additional stakeholders (required by corridor management; but not for regional management); although the relative interest and involvement by stakeholders, and the actual stakeholder representatives, may differ.
Institutional Crosses geographic, political and institutional boundaries. Crosses geographic, political and institutional boundaries; though likely less than within the region.
Operational Focus In general, information sharing and coordination of agencies that operate the various networks within the region, supporting regional management of individual network activities. Builds upon regional information sharing and coordination to provide integrated operations along the various corridors within the region. This includes operational integration of adjacent networks and cross-network linkages on a daily basis (e.g., accommodating or promoting cross-network shifts, balancing the capacity-demand relationship).
Performance Focus Network-based measurements (freeway, arterial, bus, rail). Indirect relationship to customer/user performance. Common measurements across corridor networks. Direct relationship to customer/user performance.
Technical Focus Regional ITS Architecture to support information sharing and regional coordination. ICMS builds upon the regional ITS architecture, but may have additional information sharing requirements (e.g., command and control, response plan details)


Current Corridor Conditions, Problems, And Needs

Before corridor goals and objectives can be established and the associated ICM approaches and strategies prioritized, the problems within the corridor and the needs of the stakeholders must be understood. Using the inventory information and data gathered from the previous activity, coupled with stakeholder discussions, the corridor needs are identified and documented. This effort should include operational, technical, and, institutional deficiencies and constraints, thereby providing insight as to the types of problems being faced in the corridor, and leading to a conclusion as to the overall potential of applying ICM to the corridor.

Stakeholders represent a major and important source for identifying and defining corridor issues, needs, and constraints. Their input should be elicited via interviews and/or workshops. The results should then be consolidated and edited, combining similar issues (i.e., repetitions of the same need and/or issue) and eliminating any issues and needs that are not relevant to the management and operation of the corridor. It may also be worthwhile to categorize and summarize the resulting list by the different types of corridor integration. For example, operational, including specific scenarios (e.g., incident management, traveler information, emergencies) and related concerns; technical (e.g., standards, field devices); institutional (e.g., coordination, procedures, organization, decision making); and any cross-cutting issues and needs.

An analysis of the gathered data should provide quantitative measures of the operational issues and needs within the corridor, such as:

The results of this process (stakeholder elicitation, quantitative analyses) should be presented to the stakeholders for review and comment. A workshop setting may be very beneficial in that it can encourage continuing discussion and feedback until all agree that their and the corridor's needs have been captured. Since generally the needs cannot all be met, and sometimes may even be conflicting, they should be further analyzed (perhaps during the workshop) to identify the highest priority issues and needs on which to focus the ICM program and system.

Corridor Type

A related activity is to identify the corridor "type." ICM Technical Memorandum 5.1-3 discusses several corridor characteristics that may be used to classify corridors and includes a matrix for identifying corridor types and their aspects. In summary, a corridor may be defined by the following characteristics:

Corridor Vision and Goals

The purpose of a vision statement is to portray the future ICM system and its operation for a specific time horizon, providing a platform for establishing goals and objectives. The vision statement must also be simple, easy to read and accessible to a wide audience.

The ICM vision should be developed through an iterative process involving all the corridor stakeholders. Such a consensus building approach is very important for a corridor-based approach to transportation management and operations involving multiple agencies and stakeholders, both public and private. NCHRP Synthesis 337: "Cooperative Agreements for Corridor Management" (Reference 12), stresses the "importance of establishing a shared vision of the corridor and for each party to look at the corridor as a whole-not just from within or outside of the right-of-way (or, more specifically, their individual facilities). The willingness of each party to work toward a common vision and to compromise for mutual benefit can form the basis of a lasting and effective agreement on corridor management."

The corridor goals and objectives are formulated with a view to address the current corridor conditions, deficiencies, and needs, and to help achieve the long-term vision. They also provide the framework for defining ICM approaches and strategies. The differences between goals and objectives may be summarized as follows:

The last bullet is very important. Objectives, being more precisely defined than goals and therefore permitting validation, provide a means by which the effectiveness of alternative strategies can be evaluated against a benchmark or each other. They also provide the basis for developing corridor-wide performance measures. In essence, the ICM objectives should be observable (i.e., accomplishment of the objective can be observed, with no doubt as to whether the objective has been met or not) and measurable (i.e., one can state that it was 100 percent accomplished, 50 percent accomplished, etc). At the same time, the objectives should not be to confining; that is, there should be some flexibility to allow for changes in the overall situation. If the objective can only be achieved under optimum conditions, then it is too confining.

Identify Potential ICM Approaches and Strategies

This process step involves an assessment of whether or not Integrated Corridor Management can address the operational deficiencies and needs within the corridor, followed by an identification of the specific ICM approaches and strategies to be implemented, including how they satisfy the corridor's goal and objectives.

An approach can be defined as "the means or method used in dealing with or accomplishing something." Accordingly, an ICM approach may be viewed as the overall method of achieving operational coordination on a corridor-wide basis, as defined and agreed to by the corridor stakeholders. A strategy is a specific plan of action within the broader context of the overall approach, with multiple strategies associated with each approach.

The level of integration (i.e., operational, institutional, technical) required within the corridor will depend greatly on the particular approach and the associated strategies selected by the corridor stakeholders. The affiliated level of network and stakeholder coordination may be viewed as moving along a continuous spectrum, from basic information sharing, to ad hoc relationships built around specific issues or special events, to more formal collaborative relationships with mutually agreed-upon objectives and strategies, and finally joint ownership and control of transportation facilities and services. The following ICM approaches have been defined to identify segments of that integration and coordination spectrum:

Multiple strategies are associated with each approach, as listed in Table 4-3 (with further descriptions provided in Technical Memorandum 5.1-3.). It is emphasized that these strategies focus on the operation of the corridor (comprised of multiple adjacent networks) as a whole, and the cross-network linkages and junctions. Moreover, these ICM approaches and the associated strategies are not mutually exclusive; in fact, they tend to build upon one another and, in some cases, are pre-requisites. For example, information sharing is essential to the success of the other approaches, and promoting cross-network shifts may require capacity (operational) modifications to handle the additional users on alternative networks. Moreover, these ICM approaches may also represent a staged sequence (temporal) to ICM deployment (e.g., starting with information sharing, and then moving on to integrated corridor operations over time).

It is noted that Technical Memorandum 5.1-3 includes several matrices that can be used to match a specific corridor type with the appropriate ICM operational approaches and strategies. This represents only an "initial screening," however; the "final" selection of ICM strategies can only come from a consensus by the stakeholders after cooperative identification and analysis of the specific needs for improving travel in the corridor. Moreover, it is very important to map (i.e., make "traceable") each selected ICM strategy to the corridor goal(s) and objective(s) and to the corresponding need(s) it addresses.

Table 4-3. ICM Operational Approaches and Strategies
Information Sharing/Distribution
  • Manual information sharing.
  • Automated information sharing (real-time data).
  • Automated information sharing (real-time video).
  • Information clearing-house/Information Exchange Network between corridor networks or agencies (e.g., information is displayed on a single graphical representation of the corridor, showing real-time status of all the corridor networks and connections).
  • A corridor-based advanced traveler information system (ATIS) database that provides information to travelers pre-trip.
  • En-route traveler information devices owned and operated by network agencies (e.g., DMS, 511, transit public announcement systems) being used to describe current operational conditions on another network(s) within the corridor.
  • A common incident reporting system and asset management (GIS) system.
  • Shared control of "passive" ITS devices, such as CCTV.
  • Access to corridor information (e.g., ATIS Database) by Information Service Providers (ISPs) and other value-added entities.
Improve Operational Efficiency of Network Junctions and Physical Interfaces
  • Signal priority for transit (e.g. extended green times to buses that are operating behind schedule).
  • Signal pre-emption or "best route" for emergency vehicles.
  • Multi-modal electronic payment.
  • Transit hub connection protection (holding one service while waiting for another service to arrive).
  • Multi-agency or multi-network incident response teams and service patrols and training exercises.
  • Coordinated operation between ramp meters and arterial traffic signals.
  • Coordinated operation between arterial traffic signals and rail transit at-grade crossings.
Accommodate and Promote Cross-Network Route and Modal Shifts
  • Modify arterial signal timing to accommodate traffic shifting from freeway.
  • Modify ramp metering rates to accommodate traffic shifting from arterial.
  • Modify transit priority parameters to accommodate more timely bus and light rail service on arterial.
  • Promote route shifts between roadways via en-route traveler information devices (e.g. DMS, HAR, "511") advising motorists of congestion ahead, directing them to adjacent freeways or arterials.
  • Promote modal shifts from roadways to transit via en-route traveler information devices (e.g. DMS, HAR, "511") advising motorists of congestion ahead, directing them to high-capacity transit networks and providing real-time information on the number of parking spaces available in the park and ride facility.
  • Promote shifts between transit facilities via en-route traveler information devices (e.g. station message signs and public announcements) advising riders of outages and directing them to adjacent rail or bus services.
  • Re-route buses around major incidents.
Manage Capacity — Demand Relationship Within Corridor (Real-time/Short-term)
  • Lane use control (reversible lanes or contra-flow).
  • Convert regular lanes to transit-only or emergency-only.
  • Add transit capacity by adjusting headways and number of vehicles.
  • Add transit capacity by adding temporary new service (e.g., express bus service, "bus bridge" around rail outage or incident).
  • Add capacity at parking lots (temporary lots).
  • Increase roadway capacity by opening HOV/HOT lanes and shoulders.
  • Modify HOV restrictions (increase minimum number, make bus only).
  • Restrict ramp access (metering rates, closures).
  • Convert regular lanes to truck-only.
  • Coordinate scheduled maintenance and construction activities among corridor networks
  • Variable speed limits (based on TOD, construction, weather conditions).
  • Modify toll and HOT pricing.
  • Modify transit fares to encourage ridership.
  • Modify parking fees.
  • Variable truck restrictions (lane, speed, network, time of day).
  • Restrict or reroute commercial traffic.
Manage Capacity — Demand Relationship Within Corridor (Long-term)
  • Low cost infrastructure improvements to cross-network linkages and junctions.
  • Re-routing rail transit to alternative rail networks.
  • Guidelines for work hours during emergencies or special events.
  • Peak spreading.
  • Ride-sharing programs.

Refine Corridor Boundaries

This step represents a more quantitative analysis for delineating the corridor boundaries. It builds upon the initial boundaries identified as part of the concept exploration stage, taking into account the information gathered during the system conception stage (e.g., inventory of existing systems and network characteristics, identification of current operational conditions and deficiencies, needs analysis, corridor goals and objectives, selected ICM approaches and strategies, institutional framework). Potential activities in this regard (some of which may have already been done) include the following:

Based on these operational analyses (which can likely be done via simple calculations in a spreadsheet format), the corridor boundaries may be further refined and adjusted; for example, expanding the corridor boundaries for selected operational scenarios (e.g., major incidents) to increase the amount of spare capacity, reducing the corridor width due to excessive travel time penalties, or identifying scenarios which may require a regional (corridor-to-corridor shifts) approach.

Another option is to model and simulate the corridor (and any alternative boundaries) under a variety of operational scenarios and combinations of ICM approaches and strategies. This level of detail and analysis is not required for the Concept of Operations, although it is addressed as part of the requirements stage of the overall process.

Performance Measures and Metrics

Performance measurement is important for the several reasons: it provides the basis for identifying the location and severity of problems such as congestion, service delays, and high accident rates within the corridor; it permits the evaluation of the effectiveness of the implemented corridor management strategies in meeting the operational goals and objectives for the corridor; it allows a comparison of operations from year to year as well as a comparison of performance relative to other areas or corridors; and it provides information to decision makers, stakeholders, and to the public (e.g., justification for the continued operation or expansion of the ICMS project). Performance measurement must be viewed as a continuous process focused on assessing the progress made towards achieving the operational goals identified for the corridor. In essence, if you don't measure results, you can't tell success from failure; if you can't see success, you can't reward it; and if you can't see failure, you can't correct it.

Several references provide guidelines for selecting performance measures and the attributes of good performance measures as summarized below:

By definition, a corridor is comprised of several different networks, including roadway and transit modes. Each of these separate modes and facilities can be expected to have their own set of performance measures. The selected measures may be the same for each mode, and presentation of the data may be made on a parallel basis, as shown in Table 4-4.

Table 4-4. Modal Performance Measures
Performance Measurement Type Highway Measures Transit Measures
Quantity Person Throughput (# of passengers) Person Throughput (# of passengers)
Vehicle Miles of Travel Vehicle Miles of Travel (train miles)
Average Vehicle Occupancy (persons/vehicle) Average Vehicle Occupancy (persons/train)
Quality Average Travel Time Average Travel Time
Average Travel Speed Average Travel Speed
Density (Vehicles/lane mile) Density (Passengers/seat, percent)
Time Heavily Congested (percent) Time Heavily Congested (percent)

In other instances, the mode-specific performance measures may not have any relationship to one another or to corridor operations as a whole. For example, a roadway network may utilize the volume/capacity ratio or level of service; while transit modes may use measures such as boardings per revenue hour or revenue mile, total operating cost per revenue hour or revenue mile, net deficit per boarding (difference between operating cost per boarding and revenue per boarding), and crowding (passengers per seat for peak and off peak).

Integrated corridor management requires performance measures that are "mode-neutral," reflecting overall corridor mobility and reliability (e.g., person-based or trip-based utilizing travel times and delays). Moreover, three dimensions of corridor operations should be tracked with performance measures: source of congestion or problem, temporal aspects, and spatial detail. Customer satisfaction measures should also be considered. It is emphasized that these "corridor-wide" performance measures are in addition to any network-specific performance measures. As such, the relationship between the corridor performance measures and network-specific measures need to be addressed.

In addition to the performance measures for the corridor, consideration should also be given to the development of "success thresholds" for these measures. These thresholds provide an indication that the corridor goals have been achieved. As such, they should be viewed as long-term targets that reflect the future vision of how the corridor will operate. Upon deployment of the ICMS, any movement toward the target performance values will indicate that ICMS is having the desired effect.

In all likelihood, one or more of the corridor goals will not readily lend themselves to quantitative measurements, such as goals that address institutional integration and all stakeholders sharing a "corridor view." For such goals, a more qualitative approach is necessary. This will involve conducting a periodic assessment that provides the means by which the corridor transportation agencies can measure the effectiveness of their coordination and integrated operations from a high-level, institutional view.3 Examples of questions to be addressed may include:

To be effective, such assessments should be conducted as a group exercise, including as many stakeholder representatives as possible.

Proposed Changes

This process step focuses on what is needed to implement the selected ICM strategies. This effort results in a high-level list of asset-based "requirements"4 for the ICMS, providing a sense of the overall scope for the ICMS concept. These needed assets are then compared to the existing or planned assets within the corridor to identify the proposed changes and additions to the current technical, operational, and institutional situation within the corridor. Moreover, the proposed changes will aid in the development of ICMS requirements and the definition and scoping of specific projects required to deploy and implement the ICMS.

Table 4-4 presents a list of potential asset needs for a corridor. This list is not intended to be complete, nor will every corridor and ICM concept require all the assets identified therein. These potential ICMS "requirements" are classified as follows:

These various assets are not necessarily independent or separate from one another. There are several relationships across columns; for example, the Market Package "Network/Probe Surveillance" requires one or more of the items included in the "Network Subsystems & Technologies" column (e.g., traffic detectors, CCTV, road weather sensors), which in turn provide several of the elements listed in the "Information" column (e.g., link volumes and travel times, video images, air quality). The items included in the "Communications Subsystems" column are then necessary to technically integrate all of these systems and devices into a corridor-based system, while the "Other" items support corridor integration from an operational and institutional basis. There are also dependencies within columns, particularly for the various Market Packages (as described in the National ITS Architecture documentation - Reference 15).

The next step is to compare these needed ICMS assets to the existing and near-term assets within the corridor (as obtained from the inventory/data collection step). There are many ways of performing this analysis and then presenting the results. One example is to modify Table 4-4 (or similar list) to show only those assets necessary for the proposed ICM strategies, and highlight those assets that are already operating within the corridor or are future assets based on current improvement plans. Consideration should also be given to those assets that are only partially deployed within the corridor as compared to fully deployed. Those assets and issues that are not highlighted represent the proposed changes and additions.

Table 4-5. Potential ICMS Asset Requirements
Network Systems (Market Packages) Network Subsystems & Technologies Information Communication Subsystems Other (Operational)/Performance
  • Network/Probe Surveillance
  • Surface Street control
  • Freeway Control
  • HOV Lane Management
  • Traffic Information Dissemination
  • Traffic incident Management
  • Traffic Forecast & Demand Management
  • Emissions Monitoring / Management
  • Parking Facility Management
  • Reversible Lane Management
  • Roadway Closure Management
  • Transit Vehicle Tracking
  • Transit Fixed Route Operations
  • Transit Passenger and Fare Management
  • Transit Traveler Information
  • ISP Traveler Information (broadcast, interactive, route guidance)
  • HAZMAT Management
  • Emergency Call Taking and Dispatch
  • Emergency Routing
  • Roadway Service Patrols
  • Transportation Infrastructure Protection
  • Early Warning
  • Wide Area Alert
  • Disaster Response & Recovery
  • Evacuation & Re-entry Management
  • Disaster Traveler Information
  • ITS Data Mart/WarehouseMaintenance/Construction Vehicle & Equipment Tracking
  • Road Weather Data Collection
  • Weather Information Processing and Distribution
  • Work Zone Management
  • Maintenance & Construction Activity Coordination
  • Other (e.g., Asset Management System)
  • Traffic detectors/roadway surveillance/vehicle probes
  • CCTV (video surveillance)
  • Traffic signal control/monitoring (TOD schedule)
  • Traffic signal control/monitoring (traffic adaptive)
  • Ramp Meters (local control)
  • Ramp Meters (central control)
  • HOV by-pass
  • DMS – roadway
  • Internet Traveler Information
  • Automated Incident Detection
  • Incident Detection (call-in, other)
  • Incident Response Plans/Guidelines/Teams
  • Incident Reporting System (GIS, common display)
  • Air quality sensors
  • Road Weather Information Sensors
  • Parking Surveillance/occupancy
  • Transit Vehicle Location/GPS
  • Transit Schedule Performance Monitoring
  • Passenger Counting Equipment
  • Electronic Fare/Parking Payment Equipment
  • DMS – transit
  • Transit Public Address System
  • Transit Trip Planning System
  • Spare transit vehicles/operators
  • Telephone-based ATIS (511)
  • Transit priority equipment (Intersection & Transit Vehicles)
  • Public Safety CAD
  • Emergency vehicle priority/preemption (Intersection/Vehicles)
  • Service Patrol Vehicles
  • Real-time conditions data base/common displays
  • Maintenance Vehicle Location AVL/GPS

Roadways (Freeway, Arterial, Managed Lanes)

  • Link congestion levels
  • Link volumes
  • Link occupancies
  • Link/spot speeds
  • Link travel times
  • Intersection approach volumes
  • Ramp queues
  • Average Vehicle Occupancy

Transit

  • Transit schedules
  • Transit vehicle location
  • Schedule or headway status/deviation
  • Transit vehicle headways
  • Link Travel Times
  • Priority requests
  • Next Vehicle Arrival
  • Average Waiting Time
  • Transit Fares
  • Average Vehicle Occupancy

Equipment/Device Status

  • Locations
  • Surveillance/detectors
  • DMS
  • Other Traveler information Devices
  • Ramp meter
  • Traffic Signals
  • CCTV
  • Electronic toll/fare/parking equipment
  • Available transit vehicles/location

Other

  • Video images/snapshots
  • Video control
  • Parking space availability
  • Incident location
  • Incident status/details
  • Maintenance/construction events
  • Special events
  • Electronic payment account status
  • Emergency vehicle location
  • Maintenance vehicle location
  • Parking fees
  • Contact lists
  • Air quality
  • Road surface condition
  • Center-to-Center
  • Center to field
  • Roadside to vehicle
  • Center to vehicle
  • ITS standards for data formats and data transfer functions
  • Video transport standards (digital, analog)
  • Voice communications
  • Subsystem Capacity for data distribution
  • Subsystem Capacity for video distribution
  • Subsystem capacity/frequencies for voice communications (including interoperability)
  • Interfaces to network systems
  • Interfaces to emergency service systems (CAD)
  • Interfaces to proprietary/legacy systems
  • Interfaces to ISPs (data and video export)
  • Interfaces to financial transaction network
  • Interfaces to Internet
  • Security firewalls
  • Regional Traffic Control (MP)
  • Regional Parking Management (MP)
  • Multi-Modal Coordination (MP)
  • Regional/Sub-regional ITS Architecture
  • Information Exchange Network/Common displays for data entry/display
  • Data aggregation/storage of processed data for subsequent analysis
  • Availability of spare network capacity
  • Corridor Models (simulation)
  • Accuracy of data/information
  • Vehicle location accuracy
  • Surveillance coverage
  • Response plans
  • Online decision support (for selecting response plans)
  • Definitions of responsibilities of agencies
  • Common policies for incident reporting and response
  • Special Event Plans
  • Common fare collection technology
  • Integrated back office systems
  • Dynamic fare pricing capability
  • Priority logic at intersections
  • System back up/disaster recovery

System Concept

The focus of this process step is to combine the information from the previous activities to provide a general description of the corridor under ICMS operations. This description should provide all stakeholders with both a consistent picture of what is envisioned for the corridor and a basis on which to identify their respective roles and responsibilities. The system concept must also address alignment with the Regional ITS Architecture, and the key system implementation issues (operational, institutional, technical), including how they may be resolved.

Regional Architecture

The ICMS concept should be compared to the Regional ITS Architecture to identify any possible issues and needs that may arise between the ITS Regional Architecture and the implementation of the ICMS concept. Specific considerations include the following:

At the same time, the ICMS concept may identify issues and needs that require revisions to and/or expansion of the Regional ITS Architecture.

Operational Scenarios

Operational scenarios should be developed describing how the ICMS will function under various conditions. These scenarios also describe the responsibilities and activities from the viewpoint of the primary stakeholders (e.g., network owners and operators, public safety). Potential operational scenarios include daily operational scenario (e.g., recurring congestion), scheduled event scenario (planned special events or work zone operations), incident scenarios (roadway and transit incident), and major event scenarios (e.g., evacuation).

These examples need not be all inclusive, but they should address the underlying assumptions, identify the sequence of events, and describe the expected responses and actions for each stakeholder, including which stakeholder(s) assume a lead role for these activities. Developing and describing ICM operational scenarios provides an opportunity to lay out the ICMS and explain how it will work once it is in operation. It can be very helpful in promoting an understanding of ICMS processes and operations, given certain corridor events, and showing the stakeholders how the new ICMS will affect them. Operational scenarios also represent a useful tool for setting or managing user expectations for the ICM program.

Implementation Issues

The "proposed changes" identified in the previous process step will undoubtedly include several implementation issues. It is critical that the system concept identifies all such corridor and ICM concept issues, including those related to the selected strategies. Many of these issues involve choices that need to be addressed and subsequently resolved during later stages of the systems engineering process (e.g., design, procurement, and implementation). In all likelihood, it will not be feasible to resolve all the system issues and questions at the concept level. Nevertheless, these implementation issues and their possible solutions need to be identified so all stakeholders have a joint understanding of the issues and their possible impact on the successful development and implementation of the ICM concept. Potential implementation issues, which parallel integration, as previously defined, are summarized in Table 4-5. Additional information is provided in Technical Memoranda 3.4 and 5.4.

In all likelihood, the institutional framework by which the corridor's ICM concept will be implemented, operated, managed, and maintained will represent a significant implementation issue. The Concept of Operations therefore needs to explain how the institutional framework will be established, the responsibilities of the unit(s) that compose the framework, the composition of leadership and staff, the distribution of decision-making authority, and how the framework will facilitate necessary external corridor interactions. The proposed institutional framework must be an approach that can be implemented and backed by all the corridor stakeholders.

Table 4-6. Potential ICMS Implementation Issues
Operational Issues
  • Development of operational response plans (or scenario plans) for numerous scenarios and events that can be expected to occur within the corridor. Considerations in this regard include type / severity of event or incident; location(s); criteria for identifying the event or scenario; process for confirmation; specific strategies to be implemented and in what sequence; changes to network - based systems (timing plans, transit headways, pricing), etc.. These specific response plans need to be documented (e.g., "Operations Manual) and agreed to by all the involved and affected agencies / network owners, and continuously updated.
  • Up-to-date database of contact personnel, resources, and their locations.
  • Updates to network operational parameters (signal timing, transit schedules).
  • Identifying available data and other information that should and should not be shared between agencies (e.g., personal information on drivers involved in an incident as input to police CAD).
  • Policy towards route/modal shifts. Should the approach be relatively passive (i.e., provide traveler information to the corridor users as to conditions within the corridor and the ICMS accommodates any user-determined network shifts); or should a more proactive strategy be adopted (i.e., shifts to alternative routes and modes are promoted via the traveler information disseminated to the users). Also, when and under what circumstances should each policy be utilized.
  • Procedures and protocols1 for identifying route/modal shifts when spare capacity exists on multiple networks.
  • Policies for implementing route/modal shifts (as well as demand/capacity management strategies) when sufficient spare capacity is not available within the corridor (or cannot be provided in a time frame comparable to the situation).
  • Common policies for incident response " reporting (including coordination with the formal "Incident Command Structure."
  • Pricing (fares, parking, tolls, HOT) strategies and policies.
  • Procedures and protocols for the shared use of resources and / or shared control of ITS devices, including resolution of multiple (and conflicting) requests for the same device (e.g., signal priority, DMS message, camera control).
  • Resolution of multiple (and conflicting) requests for the same device.
  • Priority strategy protocols between transit and emergency vehicles and control devices (traffic, transit, and emergency operations staff).
  • Polices for disseminating traveler information in a consistent manner across networks such that the users can make informed decisions regarding the travel decisions (i.e., route, mode, time of day).
  • Video distribution/censoring policy.
  • Safety concerns with ICM strategies.
  • Corridor modeling (e.g., evaluate impact of strategies and operating parameters).
  • Corridor-wide performance measures and metrics.
  • Marketing and outreach.
  • Ongoing operations and maintenance of the ICMS (e.g., responsibilities for funding and support, hours of operation of ICMS, updating response plans, configuration management.2

Technical Issues

  • Overall ICMS logical and physical architecture (e.g., centralized with ICMS-based center and direct control of network systems and devices; decentralized (peer-to-peer) with information sharing between individual network centers and systems, and network managers control devices in accordance with response plans; hybrid with an ICMS that requests actions by the individual network centers and systems; co-located TMCs, virtual ICMS center.)
  • Required enhancements to the individual network-based systems in support of integrated corridor management (i.e., a high-level definition of additional field equipment necessary for the ICMS, and their placement).
  • Expanded surveillance coverage and/or additional detection technologies (e.g., along the cross-network connections, network junctions such as park and ride lots, and/or the individual networks themselves) to optimize the ICM strategies and to support ICM performance monitoring. Related issues in this regard include the detector technologies, the specific information they provide, accuracy, and distribution or placement within the corridor.
  • Capabilities and upgrades to legacy systems.
  • Avoidance of proprietary interfaces to limit the different types of interfaces.
  • Data processing, aggregation, and display for system operators and for travelers.
  • Data processing, aggregation, and archiving for subsequent analyses.
  • Real-time calculation of available capacity, and location within the corridor.
  • Expanded video coverage, including the distribution/placement of video collection points.
  • Expanded coverage of ATIS devices, including the distribution/placement of devices.
  • Communication links or technologies between network-based systems and ICMS (C2C).
  • Communication subsystem capacity for data and video distribution.
  • Other communication links or technologies (C2F, roadside to vehicle).
  • Communication subsystem for voice communications (including interoperability among all agencies).
  • Communications subsystem configuration (including possible shared use of agency communication resources.
  • Data compatibilities and center-to-center standards (e.g., NTCIP, TCIP, IEEE for incident management, ATIS), including data dictionaries, message sets, protocols, and interfaces.
  • Network system interfaces (e.g., "translators" for legacy systems).
  • Video sharing and video switching standards.
  • Communications to ISPs.
  • Secure back up/disaster recovery.
  • Firewall barriers for Internet-based systems.
  • Common fare collection technology.
  • Real-time decision support (i.e., software-based response plan selection/management tools are available that continuously look at the various, changeable network performance parameters; analyze and compare these data to response plan metrics; and then implements the most appropriate pre-planned response plan either automatically or with operator confirmation).
  • Configuration management.
Institutional Issues
  • Identification and distribution of responsibilities (e.g., lead, support roles) between the corridor stakeholders for all activities associated with the planning, design, procurement, implementation, testing and acceptance, and operations and maintenance of an ICMS.
  • Organizational and administrative framework/structure that supports ICMS operations and coordination within the corridor; that is, the set of relationships, institutions, and policy arrangements that shape ICMS activities and funding (e.g., ad hoc relationships, informal working groups that meet regularly, formally established joint working groups with assigned responsibilities, funded entity (i.e., a "corridor manager") with full-time staff and well-defined responsibilities).
  • Compatibility of ICMS technologies and standards with agency IT requirements.
  • ICMS funding mechanisms (e.g., in-kind contribution of resources, pooled funding, funded legal entity).
  • Policies and procedures for data sharing, access rights, filtering, etc.
  • System procurement/implementation approach, including individual agency responsibilities in this regard.
  • Inter-agency liability.
  • Policies and arrangements with private entities (parking, ISP).
  • Federal involvement.
  • Inter-agency agreements between the different stakeholders that document the resolution of the various operational, technical, and institutional issues, and explain the associated details.
  • Updating the inter-agency agreements.
1 In this context, the term "protocols" refers to operating procedures, plans, and organizational arrangements. As discussed later, it also can refer to technical ITS standards for transmitting information between network systems within the corridor.
2 Configuration management is a cross-cutting activity that is discussed in a subsequent section herein.

Concept of Operations

The Concept of Operations (ConOps) is a formal document that provides a user-oriented view of integrated corridor management, the ICM approaches and strategies, and the associated operations. It is developed to help communicate this view to the stakeholders and to solicit their feedback. In essence, the ConOps documents the results and findings from the "system conception" stage, laying out the ICM concept, explaining how things are expected to work once it is in operation, and identifying the responsibilities of the various stakeholders for making this happen. The ConOps answers the following questions:

The ConOps does not delve into technology or detailed requirements of the ICMS, but it does address the operational scenarios and objectives, information needs, and overall functionality. The ConOps must also address the institutional environment in which integrated corridor management must be deployed, operated, and maintained. Paraphrasing the "IEEE Guide for Concept of Operations Documents" and the FHWA document "Developing and Using a Concept of Operations in Transportation Management Systems," a ConOps offers several benefits, including:

An ICMS Concept of Operations for a "generic corridor" has been developed (Technical Memorandum 2.3 ) as an example of an ICM ConOps that can be used by agency and network owners as the basis for developing their own corridor-specific and real-world ConOps. It is emphasized that this generic document is intended as guidance, not as a "template." Moreover, the generic corridor itself should not be construed as the optimum configuration for implementing ICM. It is only a tool to facilitate the development of this ConOps example.

Other references5 for developing a concept of Operations are identified in the Appendix. Finally, it should be emphasized that just as the example generic ConOps does not follow verbatim the ConOps layout identified in these references; it is not necessary for the user to perfectly match the structure of the generic ConOps document.



1 In the context of ICMS being a system of already deployed network transportation management systems, it is assumed that much of these data will already be available from these network systems and that minimal, if any, new data collection will be required.
2 This rule, which became effective in April 2001, requires the development of a "regional ITS architecture," which is defined in the rule as "a regional framework for ensuring institutional agreement and technical integration for the implementation of ITS projects or groups of projects. The regional ITS architecture is based on the National ITS Architecture and consists of several parts including the system functional requirements and information exchanges with planned and existing systems and subsystems and identification of applicable standards, and would be tailored to address the local situation and ITS investment needs."
3 Several self-assessment tools have been developed by FHWA for this purpose. In particular, the "Roadway Operations and System Management" self-assessment tool can be adapted to reflect ICM concepts, thereby providing the means by which the corridor transportation agencies can measure the effectiveness of their coordination and integrated operations.
4 The ICMS requirements, as used in the parlance of systems engineering, are developed in the next stage of the process.
5 In particular, Reference 10: "Developing and Using a Concept of Operations in Transportation Management Systems."

Previous | Next