U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590
202-366-4000
California Division
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 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. |
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?
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?
Have all applicable regional ITS architectures been identified? | |
Have all applicable resources from the planning process been identified? | |
Has the planned development been checked against the regional ITS architecture to avoid consistency problems during development? | |
Have any needed architecture changes been reported to the architecture maintainer? | |
Have all the project-applicable portions of the regional ITS architecture been utilized? |
Regional ITS architecture components and potential project use
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.
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.