Skip to content
Systems Engineering for ITS
Process ViewProcess
Related: Checklist

3.3.2       Regional ITS Operations Planning

 

OBJECTIVES

Place ITS operations into overall regional transportation planning.

Description

Planning processes are used to identify projects whose implementation will respond to regional needs. This step describes some of the key planning/ programming activities relevant to ITS deployments in a region. These activities include development of operations plans such as a Transportation Systems Management and Operations (TSMO) plan, development of a regional ITS architecture, which provides a plan for the integration of ITS systems in the region.

ConText

Context diagram showing the Inputs, Activities, and Outputs of the process step, which are repeated in the next rows of this table.

INPUT

Sources of Information

·        Long Range Transportation Plan

·        Regional ITS Architecture

·        Other planning /programming products

PROCESS

Key Activities

·        Develop Regional Operations Strategies

·        Create or Update Regional ITS Architecture

OUTPUT

Process Results

         TSMO Plan(s)

         Updated Regional ITS Architecture

         Other Operations Planning Documentation

 

 

Overview

ITS Projects are developed within the larger context of regional transportation planning.  The goal of the regional transportation planning process is to make quality, informed decisions pertaining to the investment of public funds for regional transportation systems and services.  Two of the key outputs of the transportation planning process are the long-range metropolitan transportation plan (MTP) and the Transportation Improvement Program (TIP). Each metropolitan planning organization (MPO) must prepare an MTP, in accordance with 49 USC 5303(i), to accomplish the objectives outlined by the MPO, the state, and the public transportation providers with respect to the development of the metropolitan area’s transportation network.  The MTP has a horizon of 20+ years and is fiscally constrained. The TIP is the mechanism that assigns federal funding to a prioritized list of specific projects to be constructed over a several-year period (usually 5 years) after the program’s approval. The TIP is considered the near-term “project implementation” mechanism of the MTP.

There are additional planning efforts that occur between the development of the MTP and the programming of transportation projects in the TIP.  One key effort is the Transportation System Management and Operation (TSMO), which is defined by CFR 23 USC 101 (a) (30) as “an integrated set of strategies to optimize the performance of existing infrastructure through the implementation of multimodal and intermodal, cross-jurisdictional systems, services, and projects designed to preserve capacity and improve security, safety, and reliability of the transportation system.”  The TSMO plan identifies the things that an agency will do operationally and the staff, facilities, equipment and infrastructure needed to do those things.  These elements constitute an operations plan.

A second output is a Regional ITS Architecture, which is defined by 23 CFR 940 as “a regional framework for ensuring institutional agreement and technical integration for the implementation of ITS projects or groups of projects”. According to 23 CFR 940.9 “a regional ITS architecture shall be developed to guide the development of ITS projects and programs and be consistent with ITS strategies and projects contained in applicable transportation plans”.  This effort defines the planned ITS deployments for a region with a 10+ year timeframe, and is not fiscally constrained, meaning that it represents an aspirational view of ITS services and projects in a region. 

 

Risks to be managed

Some of the risks addressed at this step are:

·        Institutional integration issues. Anticipate future operational needs and technology deployments (ITS) that require institutional integration and plan for deployments to address operational needs. Planning for these deployments can reduce the risk associated with coordinating effort between institutions by addressing possible integration issues.   This risk is technical and institutional in nature.

·        Technical integration issues. Agree on how the information to be shared between stakeholder ITS elements and other stakeholder ITS elements (or systems outside of the ITS) and begin consideration of open standards or documented protocols that will reduce the risks in future projects. This is a technical risk.

·        Incorrect customization. Tailoring services to regional needs can lead to significant benefits in scoping, estimation, costing etc. A mistake in tailoring however, can lead to significant challenges later in the process for the individual ITS projects involved, so it is crucial that tailoring be correct if it is relied upon for individual ITS project cost and schedule estimates. This is a technical risk.

Activities

Develop Regional Operations Strategies

A TSMO Plan can be a valuable resource to connect the strategies of the MTP to transportation operations in a region.  Creation of a TSMO plan is not a requirement for a region like the MTP, but regions throughout the nation have embraced the need to plan operation from a regional perspective, rather than as silos for each individual organization. A TSMO Plan defines a set of regional strategies across three key elements:

Figure shows the three basic elements of program planning: Strategic, Programmatic, and Tactical.  Each element is described in the following paragraphs.

Figure 11: TSMO Planning Elements

(Source: FHWA)

1.       Strategic elements: Strategic thinking is a foundation for developing a TSMO program.  It involves clearly defining the relationship of TSMO to the agency mission or regional vision. The strategic aspect of TSMO program planning provides answers to questions of “why” TSMO is important, and a high-level vision of “what” the agency seeks to achieve, along with strategic goals and objectives.

2.       Programmatic elements: The programmatic elements of TSMO program planning addresses issues surrounding organizational structure and business processes for implementing TSMO activities. This level of planning addresses “how” the program operates, resource and workforce needs, and internal and external coordination and collaboration. It identifies responsibilities of organizational units for specific TSMO services, projects, and activities, as well as use of analysis tools to guide investment decision-making.

3.       Tactical elements: The tactical elements are derived from the broad institutional and organizational issues to address specific services, programs, and priorities.

Detailed description of TSMO planning, including rationale for developing a plan, the particulars of what goes into a plan, and references to existing plans can be found at https://ops.fhwa.dot.gov/tsmo/index.htm.

Create or Update the Regional ITS Architecture

A regional ITS architecture identifies the regional ITS services (existing and planned) along with the necessary institutional integration that the regional stakeholders believe will meet their operational needs for ITS investments. The regional ITS architecture identifies the tailored ITS services for a region, and the necessary stakeholder ITS elements and their institutional information sharing dependencies for each tailored ITS service – which is one way of representing the operations plan for a region. The goal of the regional ITS architecture is to document the technological breadth, scope and integration of ITS in a region over the life of those systems.  Each ITS service is illustrated by identifying the stakeholder elements and their input and output information flows necessary to implement the ITS service (called an ITS service package, tailored for a specific region – and there may be more than one instance of each tailored service package in a region). Finally, the regional ITS architecture includes the identification of communications solutions that include published or “open” standards (or local protocols) that the stakeholders agree will be used to facilitate the implementation of those information flows, especially for those information flows that cross institutional boundaries.

A regional ITS architecture identifies the existing ITS capabilities in a region, and the ITS projects that will be deployed over time in the region. Each ITS project is made up of one or more regional tailored ITS services identified in the regional ITS architecture. In this way, the regional ITS architecture shows what is already deployed in a region, and the sequence (or timeframes) of the ITS projects that could be deployed (if/when resources for the projects are available) to build out the regional ITS architecture.

If the regional ITS architecture is to be used effectively, it must be a consensus product. That means that all the stakeholders who will be developing, operating, using, and maintaining ITS projects agree with the regional ITS architecture, and agree to use it as the guide for projects to be developed. Consensus in this context means that the developers, users, operators and maintainers (i.e. all the stakeholders) also agree to follow the regional ITS architecture in their ITS project development and deployment. If there is not this consensus in a published regional ITS architecture, then the utility of the regional ITS architecture is severely diminished, and while the regional ITS architecture might be a starting point for a project’s institutional integration, the project developers will need to now invest schedule and budget to build the consensus for the project’s integration with other projects in the region – which misses the point of having invested in developing (and maintaining) a regional ITS architecture in the first place. 

tipIf you’re developing a regional ITS architecture for your region, and there are one or more ITS services and/or interfaces for which you can’t get consensus from the stakeholders that should be using those services and/or interfaces, then do not include those services and/or interfaces in your regional ITS architecture.

Additional information about creating and updating Regional ITS Architectures can be found in the Architecture Use pages on the ARC-IT website (www.arc-it.net).

Tailoring this Step

The process might require a step to show compliance with the FHWA regulation or FTA policy. Some regions have established specific guidance for architecture use. For example, in California, the Caltrans Local Assistance Procedures Manual includes a Systems Engineering Requirements Form (SERF) that includes a requirement to map the project to the regional ITS architecture. This form must be completed by local agencies at project initiation. Other regions (e.g., Florida) and agencies (e.g., Virginia DOT) have established similar guidance.

The level of activity involved in using the architecture depends on the scope of the project (i.e., how many systems and interfaces it affects) and the quality of the regional ITS architecture. Use of the architecture will lead to greater savings in later work throughout the project by utilizing the high-level definitions included in the regional ITS architectures. The Use in Project Development section of the ARC-IT Website ( https://www.arc-it.net/html/raguide/raguide-c5.3.html#_Use_in_Project) provides additional guidance for architecture use in project implementation.

Policy or standard for Process Step

Regulation 23 CFR 940 and FTA Policy on Architecture and Standards require a regional ITS architecture for any region currently implementing or planning ITS projects. All ITS projects must adhere to this regional ITS architecture. The Regulation/Policy also requires that the development of a regional ITS architecture be consistent with the statewide and metropolitan planning process.

Traceable Content

Some of the artifacts developed by the Regional ITS Operations Planning process are identified in Table 1. This table illustrates how the outputs of this step form the bridge between the MTP, TIP and the initial steps of project development.

Table 1: Regional ITS Operations Planning Traceability

Traceable Artifacts

Backward Traceability To:

Forward Traceability To:

Regional ITS Architecture

 

Long Range Transportation Plan or Metropolitan Transportation Plan (MTP)

·        Operations Planning System Study to select alternative concepts (if needed)

·        Transportation Improvement Program (TIP)

TSMO Plan

Long Range Transportation Plan or Metropolitan Transportation Plan (MTP)

·        Regional ITS Architecture

·        TIP

 

Checklist

The following checklist can help answer the question “Are all the bases covered?” once the activities above have been planned or performed.  The checklist is not sufficient by itself.

R  Do the relevant regional ITS architectures need to be updated (based on their maintenance plans?

R  Have any needed architecture changes been reported to the architecture maintainer?

R  Have any Operations Planning documents been created?


 

 

Related: Checklist
Back to top of page