U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590
202-366-4000


Skip to content U.S. Department of Transportation/Federal Highway AdministrationU.S. Department of Transportation/Federal Highway Administration

California Division

Home / About / Field Offices / California Division / Systems Engineering Guidebook for ITS

Home What's New Systems Engineering Guidebook Views Search Glossary Resources Feedback Site Map

3.2.1 Interfacing with Planning and the Regional ITS Architecture

 

OBJECTIVE:

Intelligent Transportation Systems at the project level are to be consistent with, and leverage from, the regional ITS architecture. The regional ITS architecture provides a framework that supports transportation planning and programming for ITS projects. This step describes what to expect from the regional ITS architecture and how to use the products at the project level. An existing regional ITS architecture provides products that can be leveraged for concept exploration, feasibility analysis, and project level developments.

DESCRIPTION:

Before the project level development begins, groundwork is laid in the planning process and the development of a regional ITS architecture. The regional ITS architecture includes a list of stakeholders, a system inventory, an identification of regional needs and transportation services that meet those needs, a high-level operational concept, functional requirements, and regional interconnections and information exchanges. The project will refine and expand products from the regional ITS architecture. For example, it may expand an agency-level stakeholder to identify maintenance, IT, and operations divisions that were not specified at the regional level. As the project is defined, additional needs and approaches may be identified that were not envisioned at the regional level. Providing feedback to the planning process and the regional ITS architecture is essential so that the regional ITS architecture continues to provide an accurate high-level depiction of ITS implementation and vision for the region.

CONTEXT OF PROCESS

Shows the flow for Phase [-1].  Summaries are described for inputs, constraints, and enablers into the phase;  activities of the phase; and outputs from the phase.  The flow is described in detail in the accompanying text.

PROCESS FOR INTERFACING WITH PLANNING AND THE REGIONAL ITS ARCHITECTURE

Inputs:

Regional ITS architectures describe the framework for integration. The project must fit into these architectures or the architectures must be changed to reflect new regional consensus.

Project goals and objectivesidentify the purpose of the project and what it is intended to accomplish.

Control:

FHWA Final Rule and FTA Policy specifies the requirements for developing and maintaining a regional ITS architecture and the requirements for using a systems engineering analysis for ITS projects.

Enablers:

Stakeholder involvement focuses the project on local needs.

Elicitation draws out and clarifies local project needs.

Outputs:

Portion of the regional ITS architecture identifies the parts of the regional ITS architecture selected for development on this project. This output defines the basic scope of the project in context with other ITS systems that exist or will exist in the region.

Recommended regional ITS architecture changes should be submitted to the architecture maintainer for consideration in future updates to the regional ITS architecture.

Process Activities:

Identify existing regional ITS architectures and other resources from the planning process.

Many states and regions have developed state and regional ITS architectures. These architectures provide a good starting point for project development and must be used to support project systems engineering analysis, per the FHWA Rule/FTA Policy. In some cases, more than one regional ITS architecture may apply. For example, a major metropolitan area may be included in a statewide architecture, a regional architecture for the metropolitan area, and sub-regional architectures that are developed for a particular agency or jurisdiction. Identify the regional ITS architecture that applies to the project, coordinating with the architecture maintainers in the region as necessary. Coordinate with Planning to take advantage of all previous work that has been done.

Identify the portion of the regional ITS architecture for the project.

Any given ITS project will implement only a small subset of the regional ITS architecture. The regional ITS architecture necessarily addresses many regional needs and issues that are outside the scope of the project. For example, in a simple signal system that does not interface with ramp meters, the aspects of the regional ITS architecture that address freeways are not relevant. The first step is to identify the portion of the regional ITS architecture that applies to the project. Using this subset of the regional ITS architecture, document any constraints that the architecture may place on the design, including ITS standards that are identified that may be applicable to the project.

Using a regional ITS architecture will provide a project that is consistent with other systems in the area, meets requirements for federal funding, and can be developed more efficiently and quickly using the regional ITS architecture content to get started. A good regional ITS architecture will provide region-level information that can be used and expanded in the project development, providing a good starting point for concept exploration and initial project development.

Check consistency and submit architecture changes.

Confirm that the project fulfills a portion of the regional ITS architecture. If the project provides capabilities beyond the regional ITS architecture, the regional ITS architecture should be updated to more accurately reflect the ITS project. These changes should be submitted to the maintainer of the architecture.

Illustrates that the interface with the planning and the regional ITS architecture  takes place in the Regional Architecture section of the Vee Development Model.

Where does interfacing with Planning and the regional ITS architecture take place in the project timeline?

Is there a policy or standard for ITS project planning or the regional ITS architecture?

The FHWA Final Rule/FTA Policy requires a regional ITS architecture for any region currently implementing or planning ITS projects. All ITS projects must adhere to this regional ITS architecture. The Rule/Policy also requires that the development of a regional ITS architecture be consistent with the statewide and metropolitan planning process.

Which activities are critical for the system’s owner to do?

  • Coordinate with Planning
  • Identify applicable regional ITS architectures
  • Identify the portion of the regional ITS architecture that applies to the project
  • Verify consistency and submit any needed architecture changes to the architecture maintainer

How do I fit these activities to my project? [Tailoring]

The process might require a step to show compliance with the FHWA final rule 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. Chapter 7 of the Regional ITS Architecture Guidance Document provides additional guidance for architecture use in project implementation.

What should I track in this process step to reduce project risks and get what is expected? [Metrics]

Potential inconsistencies between the regional ITS architecture and the project

Checklist: Are all the bases covered?

check Have all applicable regional ITS architectures been identified?
check Have all applicable resources from the planning process been identified?
check Has the planned development been checked against the regional ITS architecture to avoid consistency problems during development?
check Have any needed architecture changes been reported to the architecture maintainer?
check Have all the project-applicable portions of the regional ITS architecture been utilized?

 

Regional ITS architecture components and potential project use

  • Architecture scope - determine if the project should be covered by the architecture scope
  • Stakeholder identification – Ensure appropriate agencies are involved. Expand list to identify specific divisions, groups, etc. that should be involved.
  • System inventory - Identify the system(s) that will be implemented or enhanced by the project. Also identify interfacing systems that may be impacted.
  • Needs and services - Confirm that the project will address the regional needs and services documented in the architecture. Identify the ITS service(s) that are supported by the project and related regional needs.
  • Operational concept – Expand on the broad agency roles and responsibilities identified in the architecture to define specific roles and responsibilities for development and the operations & maintenance of the project in the Concept of Operations.
  • Functional requirements – Use the high-level functional requirements from the architecture as a starting-point for the project system requirements. Project system requirements will add specificity, detail, and include other types of requirements.
  • Interfaces/information flows – Review the interfaces defined in the architecture to identify integration opportunities that should be addressed in the current project and/or accounted for in future iterative development. Identify and define selected interfaces in increasing detail during project development.
  • Maintenance plan – Submit needed architecture changes or enhancements to the architecture maintainer through the identified process.
  • Agreements – The list of agreements may include existing and planned agreements that are necessary for the project. Define any agreements that are necessary for the project and begin work immediately on these long lead-time documents.
  • Standards identification – The ITS standards identified in the architecture will provide a comprehensive list of national ITS standards that will have to be tailored to include only standards (and the portion of standards) that are actually relevant to the project and also augmented to include regional and project-level standards that may also apply.
  • Project sequencing - If the sequence of projects in the architecture includes the target project, this will facilitate identifying the portion of the regional ITS architecture that applies. If not, the need for an update to the project sequencing can be reported to the architecture maintenance organization.

Are there any recommendations that can help?

The regional ITS architecture is often developed using the Turbo Architecture software, which structures the information, and provides a link with the National ITS Architecture. If Turbo Architecture is available, this tool can also be used to select the subset of the regional ITS architecture that applies to the project through it’s project architecture capability. The relevant portion of the regional ITS architecture can be exported as diagrams, reports, or textual files that can then be incorporated into the initial project documentation.

Tip. Several States have developed a statewide ITS architecture that provides a framework that covers the entire state, covering gaps between regional ITS architectures that are frequently focused on the metropolitan areas. The statewide architectures focus on state level services, such as commercial vehicle operations, or services that benefit from interregional coordination, such as trip planning. Projects that implement these broader services should be related to the statewide architecture, if one exists. The goal is to complement the activities of the metropolitan planning organizations by creating a framework for connections between regions and state-level services. The process requires consensus building among a diverse group of stakeholders representing the varied interests throughout the state.

Challenges to traditional planning and ITS project development

Coordination between planning and operations is essential in regional ITS architecture development. The ITS projects that are identified in the long range transportation plan and the Transportation Improvement Program [TIP must meet the purpose and needs identified through planning, be operationally viable, and be maintainable through the project’s life cycle. Considering each of these factors early in project development requires the combined expertise from many domains, including planning, operations, and maintenance. The regional ITS architecture also provides a project sequence that can be used as a tool to define the relationship and dependencies between projects early in the process.

Checklist

 

Federal Highway Administration | 1200 New Jersey Avenue, SE | Washington, DC 20590 | 202-366-4000