Skip to content
U.S. Department of Transportation

4 Creating a Planning-Supportive Architecture


If the regional ITS architecture is to be used to support planning for operations, it must be relevant and easy to use. It must assist transportation planners in understanding and solving the tough integration choices facing States and metropolitan areas. In order to be relevant, the architecture must be clearly connected with the transportation planning process. Section 4.1 describes an approach for connecting the architecture with transportation planning and provides examples of regions that have made this connection in a tangible way.

Why Make the Connection?

A documented connection between architecture and planning links the objectives identified in the planning process (what the region needs to accomplish) with the existing and planned ITS components in the region. The connection is a basis for many of the opportunities identified in Chapter 3. The result is better planning, an improved architecture, and ultimately a better surface transportation system that employs ITS specifically to meet the region's objectives.

The regional ITS architecture has a reputation for requiring a steep learning curve with specialized terminology and expansive lists of items that are difficult to sort through. Section 4.2 presents techniques that regions have used to make the architecture more approachable and user-friendly for all users, with particular focus on the planning community.

Finally, there is a gap between the needs of transportation planners to support effective planning for integration and the information that is required to be included in a regional ITS architecture. Regions can fill the gap with an ITS/operations plan as described in Section 4.3.

Regions can follow the advice in Sections 4.1-4.3 and create an architecture that is connected with the planning process, is user friendly, and is augmented with an ITS/ operations plan. This will lead to an architecture that can be used effectively, but one more factor should be considered to optimize architecture use – the timing of the architecture updates. To achieve the most benefit, the architecture update should be scheduled specifically to support the transportation planning process as described in Section 4.4.

The techniques described in this chapter can be viewed from two perspectives: 1) They capitalize on the strengths of the architecture and make sure the integration it describes is available to planners when they need it, in a readily consumable format, and 2) They also seek to address the challenges that have encumbered the use of the architecture in some regions. Many of the techniques described here were also mentioned in Chapter 3 as various opportunities for architecture use were highlighted. This section collects together the most successful ideas that we have encountered, and a few additional ideas that appear to have merit, but have yet to be implemented.

4.1. Making the Architecture Connections to Planning Explicit

In Section 2.4, we identified the connections between the planning for operations approach and the regional ITS architecture development process. These connections enable the opportunities for using the architecture to support planning for operations that are discussed in Chapter 3. The connections are important because they establish the relationship between the objectives identified in the planning process and the existing and planned ITS components in the region. In this section, we take a closer look at how the connections should be documented to make the architecture more useful to planners.

The potential connections identified in Section 2.4 are summarized in Table 3 along with a summary of how to make each connection "explicit." By explicit, we mean that planning outputs and architecture outputs are linked in a table, preferably supported by a database or equivalent application that allows the connection to be managed. You need to document the connection and then maintain the connection using tools so that you can quickly and easily identify disconnects and understand the implications of changes to the planning outputs, architecture outputs, or both.

The number of documented connections should be kept to a minimum since each documented connection creates overhead in the architecture maintenance effort. Fortunately, the architecture components are all linked to each other, so one or two links to the architecture will support access to all architecture components. Although the best approach will vary for each region, we will focus here on two connections that are highlighted in the table.

Table 3: Planning to Architecture Connections.
Planning for Operations Component Related Architecture Component Making the Connection Explicit
Goals and Objectives -- Link architecture to objectives
Performance Measures -- Link performance measures to objectives
Operations Needs Needs Link needs if lists maintained
Strategies Services Stylized number 1.Link strategies with service packages
Programs and Projects Projects and the related subset of the regional ITS architecture: interfaces, functional requirements, etc. Stylized number 2.Link programs/projects in the STIP/TIP to regional ITS architecture projects

Figure 23 shows the two key connection points in the context of the planning and architecture processes. As shown, connection 1 is used to link the architecture with the metropolitan/statewide transportation plan as it connects strategies from the planning process with services in the architecture process. This connection would be established and then maintained for each update of the MTP/LRSTP and major update to the architecture. Connection 2 would link the architecture with the projects identified in the STIP/TIP. Since project definitions and the STIP/TIP are updated more frequently than the MTP/LRSTP and strategies, the second connection would be subject to more frequent maintenance. Both connections may be facilitated by the ITS/ operations plan(s) for your region, as described in Section 4.2. These two maintained connections would support the broader set of connections described in Section 2.4 and the opportunities described in Chapter 3. For example, connection 1 can also be used to link objectives to projects since the regional ITS architecture typically already includes a linkage between service packages and projects; objectives are connected to service packages, which are in turn connected to projects. As a planner, these connections will help you establish the relationship between programmed projects and the operations objectives.

Figure 23: Key Connections in the Context of the Planning and Architecture Processes.
This figure shows the two key connection points in the context of the planning and architecture processes. Connection 1 is used to link the architecture with the metropolitan/statewide transportation plan as it connects strategies from the planning process with services in the architecture process. Connection 2 would link the architecture with the projects identified in the STIP/TIP.

Stylized number 1. Documenting a Connection to Needs and Services.

First and foremost, the regional ITS architecture must reflect the goals and objectives of the region. This may seem like a statement of the obvious to readers of this primer since we have made this point several times; in Section 2.4 as we presented the connections between planning for operations and architecture and again in Chapter 3 when we described the opportunities to use the architecture to support development of regional goals and objectives. Although it may seem obvious, you may be surprised to find that your regional ITS architecture does not include such a connection. Relatively few regional ITS architectures have documented this connection to date.

If the objectives-driven performance-based approach to planning for operations is used, then there will be clear linkages between goals, objectives, and strategies. Needs are also defined as part of the planning for operations approach, but the needs are frequently documented in narrative form rather than as a discrete list of items that can easily be linked to the regional ITS architecture. In the regional ITS architecture, needs and services are also typically linked. If all of these linkages are in place, then a single connection between objectives or strategies from planning for operations and needs or services from the architecture is all that must be established to ground the regional ITS architecture in the regional goals and objectives and also establish the key connection between strategies and services. Figure 24 shows a few of the alternative connections. In the figure, only two sample rows are shown for each potential connection although there will typically be a few hundred rows in a complete, defined connection between a transportation plan and a regional ITS architecture.

To establish an explicit connection:

Figure 24: Connecting Objectives and Strategies with Needs and Services.
This diagram illustrates alternatives to connecting the metropolitan or statewide transportation plan to the regional ITS architecture.  If an objectives-driven, performance-based approach is used to develop the MTP/LRSTP, then the plan and the architecture can be linked by associating objectives in the MTP/LRSTP with services in the architecture that help to achieve those objectives.  Alternatively, the operations strategies in the plan can be associated to the services in the architecture to connect the plan and the architecture.
Figure 25: Connecting the STIP/TIP Projects with the Architecture.
Diagram illustrates three different approaches that are commonly used to make a connection between projects (in TIP/STIP) and the regional ITS architecture:  link projects with ITS in the TIP or STIP to projects from sequencing in the regional ITS architecture, the architecture portion (inventory, interfaces, etc.) of the regional ITS architecture, or services within the regional ITS architecture.
Figure 26: MRCOG Regional ITS Infrastructure Geodatabase.33
Conceptual diagram illustrates the central regional ITS infrastructure geodatabase that MRCOG is developing that will reside on the internet at a central web site and be accessed by stakeholder agencies: Rio Metro, City of Albuquerque, NMDOT, Bernalillo County, City of Rio Rancho, MRCOG, and ABQ Ride.
At the national level, the objectives categories identified in Advancing Metropolitan Planning for Operations The Building Blocks of a Model Transportation Plan Incorporating Operations: A Desk Reference are linked to the National ITS Architecture. If you have not yet built a connection between architecture and objectives, then these connections will provide a head start. Visit the "Planning View" on the National ITS Architecture web site for more information.32 The Minnesota Statewide ITS Architecture links high-level polices from the Statewide Transportation Plan to ITS Development Objectives and ITS Project Concepts that are defined as part of the architecture. An excerpt from the table that is included in Volume 1 of the statewide architecture is shown in Chapter 3 (see Figure 15).

The Minnesota Statewide ITS Architecture links high-level polices from the Statewide Transportation Plan to ITS Development Objectives and ITS Project Concepts that are defined as part of the architecture. An excerpt from the table that is included in Volume 1 of the statewide architecture is shown in Chapter 3 (see Figure 15).

Stylized number 2. Establishing a Connection Using Projects.
The most common use of a regional ITS architecture is during programming when projects are scoped, project applications are prepared by project sponsors, and the applications are evaluated by the MPO and/or the State DOT. Specific connections between the programs/projects in the MTP/LRSTP and the STIP/TIP and the projects defined in the regional ITS architecture project sequence will facilitate this use. An ITS/operations plan can align the regional ITS architecture project sequence with the planned and programmed projects or the connection can be documented as part of the regional ITS architecture. In either case, a traceable project-oriented link is created that connects the architecture with the project scoping and programming process.

Figure 25 shows three different approaches that are commonly used to make a connection between projects and the regional ITS architecture. The approach should allow the specific components of the architecture – the services, operational concept, functional requirements, interfaces, associated ITS standards, and agreements – to be identified for a specific project. All three of the approaches shown in the figure allow the user to identify these architecture components due to the links in the regional ITS architecture, but there are differences in the difficulty the user will have in identifying the components and the precision of the fit between the components that are identified and the real scope of the project. Here is a quick discussion and comparison of the three approaches:

The specific nature of projects can pose a challenge when they are defined in terms of the regional ITS architecture. For example, a regional ITS architecture may include only a few general inventory elements to represent the traffic signal systems that are implemented by local agencies in a metropolitan area. These same general elements may be included in many different projects, representing implementations in different locations and by different agencies. The Turbo Architecture software allows more specific architecture elements to be defined for a specific agency and a specific subset of the traffic network. These "element instances" may be used to more specifically define the scope of a particular project without adding too much detail to the regional ITS architecture. Element instances allow you to bridge the gap between the higher level regional ITS architecture and specific projects.

Some regions have taken the next step and are beginning to use a geographic information system (GIS) to extend the architecture to add location specificity for projects while maintaining the linkage to the overarching regional ITS architecture framework. For example, the Mid-Region Council of Governments in Albuquerque, NM is developing a central ITS infrastructure "geodatabase" in GIS (Figure 26). Facilitated by the ITS subcommittee, this system will establish a common framework for near-term ITS infrastructure mapping and deployment summaries and will promote infrastructure consistency and coordination among all stakeholders. The geodatabase will utilize the state of the art in GIS applications and will reside on the internet at a central web site and will be accessed via the internet "cloud." It will provide a centralized location for viewing, mapping, and summarizing regional ITS deployment information for all stakeholders. The links to the regional ITS architecture provide the framework necessary for this level of integration.

4.2. Keeping it Planner-Friendly

There are a number of techniques that can be used to make a regional ITS architecture easier to use for transportation planners. Fortunately, the techniques that are used to make the architecture "planner friendly" also improve the user experience for all users as the techniques address the common challenges identified in Table 4. Each of the techniques is explored further in the remainder of this chapter.

Table 4: Techniques for Making the Architecture Planner-Friendly.
Challenge Technique
The regional ITS architecture is a specialized topic area with its own terminology and concepts. User Aids
  • Provide links to resources like the Regional ITS Architecture Guidance Document and other resources.
  • Include a glossary of terms.
  • Provide contact information for those with questions
  • Include training with your next regional ITS architecture update.
The sheer amount of information in the architecture can be daunting – hundreds or even thousands of functional requirements and interfaces. Users can get lost and never find the information they were seeking. User-Friendly Organization
  • Provide a roadmap.
  • Segment the regional ITS architecture documentation into "views" for different types of users.
  • Include navigation queues.
  • Provide summary level information with the opportunity to "drill down" into the detail.
The content can be difficult for planners to pick up and use. Planner-Friendly Content
  • Provide summary level graphics suitable for executive summary/presentations.
  • Provide a planning view, including links to the MTP/LRSTP.

User Aids

Using the regional ITS architecture can be a challenge due to its specialized terminology and concepts that are unfamiliar to most planners. Very few regional ITS architecture users consider themselves to be architecture experts; most need some background information to support their use of the regional ITS architecture. Users access the regional ITS architecture infrequently, so even users that were involved in the regional ITS architecture development may need a quick refresher on the terminology or background on regional ITS architecture concepts. Consider the following techniques for providing assistance to potential architecture users, including planners and non-planners alike.

User-Friendly Organization

Most regional ITS architecture documents are several hundred pages in length. Regional ITS architecture web sites include hundreds or even thousands of pages. All users of the regional ITS architecture must be able to find what they need in the broad set of documentation. Fortunately, there are several techniques that have proven effective in assisting the user in finding the information they seek.

Planner Friendly Content

4.3. Adding the Planning Context – ITS/Operations Plans

The regional ITS architecture is focused on defining the integration opportunities for the transportation systems in the region. While it includes a few strategic elements like the project sequencing, the regional ITS architecture typically does not define the strategic vision for operations and the overall approach for how the integrated regional transportation system will be implemented geographically, over time. This missing strategic element is important to the planning process, which seeks to identify and prioritize projects for implementation in specific locations and in specific fiscal years.

Figure 27: An ITS/Operations Plan Can Connect
the Regional ITS Architecture with the
Region's Transportation Plan and Program.

Conceptual diagram shows a bridge where the metropolitan or statewide plan or improvement program is on the left side and the regional ITS architecture is on the right side.  The ITS/operations plan is the bridge that connects the two sides.

Recognizing the gap between what is required to be included in a regional ITS architecture and the strategic planning needs for ITS, many regions have developed an ITS strategic plan (sometimes called an ITS deployment plan) as a companion to the regional ITS architecture. Although the name of the plan varies from region to region, all of these plans articulate the strategy for how ITS will be deployed over time in the region. These plans include the detailed strategies that directly support the STP/MTP. They provide a bridge between the integration-oriented architecture and the planning-oriented MTP, LRSTP, and STIP/TIP.

More recently, regions have also developed operations-focused planning documents including transportation systems management and operations (TSM&O) plans that fill a similar strategic planning need but from an operations perspective. These plans help to tie the management and operation of the transportation system to the enabling technology. Rather than try to specify whether a region should create an ITS strategic plan, a TSM&O plan, or some combination of the two, we use the general term "ITS/ operations plan" to refer to the range of plans that can fill this role. The focus here is on the information that could be included in an ITS/operations plan to bridge the gap between the architecture and the planning process. At the end of this chapter, the unique role of a regional concept of transportation operations (RCTO) is discussed along with its relationship to the regional ITS architecture and the metropolitan or statewide transportation planning process.

The elements of an ITS/operations plan that add a planning context to a regional ITS architecture are shown in Figure 28 and discussed in the following paragraphs.

Figure 28: Adding Planning Context with an ITS/Operations Plan
Diagram shows an ITS/operations plan that adds a planning context to a regional ITS architecture.  The elements of an ITS/operations plan that can connect the metropolitan transportation plan or long-range statewide transportation plan and the regional ITS architecture are vision, goals and objectives, needs, funding considerations, and M&O strategies.  Project specifics such as location or extent, costs, and benefits are elements of an ITS/operations plan that can connect the metropolitan or statewide plan and improvement program to the regional ITS architecture

ITS/Operations Vision: The ITS/operations plan provides a detailed vision for transportation operations in the region, expanding on the broader transportation vision that is articulated in the transportation plan.

Goals and Operations Objectives: In Section 4.1 we established a connection between the goals and objectives in the MTP/LRSTP and the architecture. The goals and objectives may also be documented and expanded in the ITS/operations plan. Specific operations objectives may be defined in more detail in the ITS/operations plan. The specific operations objectives can then be included in the MTP/LRSTP.

Funding Considerations: The regional ITS architecture is not fiscally constrained, but the transportation plans and transportation improvement programs are. The ITS/operations plan considers funding sources and funding requirements for ITS/ operations deployments so that the strategy is consistent with anticipated funding. Operations Needs: The operational needs for the region are frequently defined in the ITS/operations plan and used as a basis for the services that are identified in the regional ITS architecture. The operations needs defined in the ITS/operations plan are also included in the MTP/LRSTP.

FHWA is currently developing guidance to conducting benefit-cost analysis of operational strategies. In addition, an accompanying decision support tool called Tool for Operations Benefit-Cost Analysis (TOPS BC) is also being developed. When completed, the tool will be placed on the U.S. DOT Planning for Operations web site at http://www.plan4operations.dot.gov/. Until then, or for additional information, readers may contact the FHWA Office of Operations at 717-221-4422 or email jim.hunt@dot.gov.

Management and Operations Strategies: A range of management and operations strategies suitable for inclusion in the MTP/LRSTP may be defined in detail in the ITS/ operations plan. These strategies can also be linked directly to the ITS services in the regional ITS architecture as described in Section 4.1. The strategies are supported by detailed definitions for the prioritized and time-sequenced set of projects that are also defined in the plan.

Interoperability is a laudable goal, but you have to have the equipment in the right place. If the equipment is not on your most heavily used corridor with the most delay, you can be very interoperable, but it isn't going to do much for you. Eventually, it all needs to go on a map.

Richard Perrin, Genesee
Transportation Council

Detailed Project Definitions: Projects are defined in terms of the regional ITS architecture by collecting together the inventory elements, functional requirements, interfaces and other related components that are included in the project. The regional ITS architecture identifies the integration opportunities, related ITS standards, and other information relevant to the project, but it does not provide sufficient information to estimate costs or benefits, which require more specificity on where and how the project will be implemented. The ITS/operations plan provides the detailed project definitions, locating each project geographically, and estimating the project costs and benefits.

Project Location/Extent: Before you can estimate project benefits or costs, you must locate the project on a map. Individual project locations and the net coverage provided by the planned deployments is key information that is included in an ITS/operations plan. For example, the Southeast Michigan Council of Governments and Michigan DOT developed a Regional ITS Deployment Plan that includes a series of maps like the one shown in Figure 29 that locates the existing ITS infrastructure and planned ITS projects for each county in the region.

Project Costs/Benefits: Ultimately, project prioritization is based on the anticipated project costs compared with the contribution the project will make to the operations objectives. The regional ITS architecture is typically silent on project costs and benefits, but this information can be included in the ITS/operations plan. For example, the MDOT/SEMCOG ITS Deployment Plan includes a cost/benefits analysis using the ITS Deployment Analysis System (IDAS) software tool for each identified project.

Figure 29: MDOT/SEMCOG ITS Deployment Plan – Livingston County Proposed
ITS Deployments.34

A map from the Michigan DOT/Southeast Michigan Council of Governments ITS Deployment Plan that depicts the Livingston County Proposed ITS Deployments.  This figure is an example of an ITS plan that shows the location of existing ITS infrastructure and planned ITS projects for each county in the region.

The Northern Virginia regional ITS architecture includes an online ITS Solutions Decision Support System that provides detailed cost/benefits analysis for ITS projects on their architecture web site as shown in Figure 30.35

In addition to these items, an ITS/operations plan should also include: 1) the relationship to other plans, and 2) an explanation of how and when the ITS/operations plan will be updated. The connection to other plans should describe the relationship between the ITS/operations plan, the MTP/LRSTP, STIP/TIP, and the regional ITS architecture, documenting relationships like the ones described in this chapter. The update plan for the ITS/operations plan should be consistent with the plan for updating the architecture and MTP/LRSTP. See Section 4.4 for more information.

Figure 30: VDOT ITS Decision Support Tool – Cost and Benefit Data 36
Screenshot of the VDOT ITS Decision support Tool.

Regional Concept for Transportation Operations (RCTO)

A regional concept for transportation operations (RCTO) is a specific type of strategic operations plan that is growing in popularity across the U.S. as planners and operators in a region look for a way to guide their work together in advancing management and operations. The RCTO can also provide a planning context to the regional ITS architecture. The architecture can be used to help implement the M&O strategies or services identified during the development of the RCTO.

An RCTO is a management tool used by planners and operations practitioners to define a strategic direction for improving regional transportation management and operations in a collaborative manner. The use of an RCTO is growing in regions of different sizes across the U.S. An RCTO focuses on operations objectives and strategies within one or more management and operations functions of regional significance such as traveler information, road weather management, or traffic incident management.

By implementing an RCTO, partners put into action within 3 to 5 years operations strategies that they will sustain over the long term. Central to an RCTO, the operations objective defines the desired outcome, the "what," in specific and measurable terms. The motivation supports the operations objective by grounding the collaborative action in regional needs, agency goals, or operational concerns. The other four elements – approach, relationships and procedures, resource arrangements, and physical improvements – work in concert to define "how" the partners will attain the operations objective.

The regional ITS architecture is an important tool to support the implementation of the RCTO, especially the physical improvements or technology that must be put in place to achieve the operations objectives of the RCTO. There are several ways to combine the use of the RCTO and the regional ITS architecture to support planning for operations. One of those pathways is depicted in Figure 31 using an example from the fictitious region of Kesla Valley. The example shows how an RCTO focused on traffic incident management can support planning for operations and in turn, be supported by a regional ITS architecture.

Figure 31: Connecting an RCTO, a Plan, and an Architecture.
Diagram depicting the connection between the Kesla Valley 2035 Metropolitan Transportation Plan and the Kesla Valley RCTO for Traffic Incident Management.

The Kesla Valley RCTO for Traffic Incident Management was developed to help achieve the regional operations objective of cutting delay by five percent over 10 years. This objective was created and agreed upon as part of the update to the region's metropolitan transportation plan. Incidents were determined to be a significant contributor to delay and congestion on the Kesla Valley freeways and arterials. In response, the MPO planners teamed up with the operations management staff from the State DOT, the county, three cities, and public safety agencies to create and implement an RCTO. They formed specific, measurable operations objectives to improve traffic incident management and then devised an overall approach to achieve the RCTO objectives. They defined the necessary relationships and procedures, resource arrangements, and physical improvements.

The RCTO participants identified several physical improvements that required deploying, integrating, and using ITS across several agencies in the region and so they turned to their regional ITS architecture to define the projects that would need to be implemented and how the technology and data flows could be integrated into the regional context. A new service package, Traffic Incident Management System, was added to the Kesla Valley Regional ITS Architecture and the collaborating participants walked through a detailed operational concept for the desired functionality, the interconnects, and the information flows. The partners used the ITS standards already defined in the architecture to ensure that their projects would be compatible with new and existing technology deployments. The RCTO participants used this information to develop three projects to be submitted for approval and funding in the Kesla Valley TIP 2012 – 2017.

Once the projects are implemented, the Kesla Valley architecture will be updated to reflect these new systems that can be built on in the future. The participants also examined the architecture to see where data may be available to track incident clearance time related to the RCTO's operations objective.

In general, a regional ITS architecture enables the regionally coordinated implementation of an RCTO, specifically the ITS that supports the RCTO's approach, but there are many other connections that can be explored by regions looking to get the most out of their investments.

4.4. Scheduling Updates to Optimize Use

Figure 32: Architecture Updates to Support
Planning.

Conceptual diagram shows that a baseline update to the regional ITS architecture is performed to support each MTP/LRSTP update and that a minor projects-focused update of the architecture, with perhaps an architecture addendum, is done to support each new STIP/TIP.

Although FHWA Rule 940 and the accompanying FTA policy do not require a specific update cycle for the regional ITS architecture, it is good practice to align the architecture update schedule with the schedule for the MTP/LRSTP and STIP/TIP updates. One good approach is shown in Figure 32. In this approach, a baseline update is performed to support each MTP/ LRSTP update, and a minor project-focused update of the architecture is done to support the STIP/TIP. The remainder of this chapter explores these updates in more detail.

Baseline Architecture Update to Support the MTP/LRSTP

The regional ITS architecture should be updated as needed to support each update of the MTP/LRSTP. This regular update cycle keeps the architecture up-to-date and consistent with the transportation plan. Note that the baseline architecture update is not necessarily a "major" update. The update might require only minor changes if there has not been significant change in goals and objectives, stakeholder participation, or the scope of what is covered by the National ITS Architecture and regional ITS architectures since the last update. The question is whether the regional ITS architecture should be updated, before, at the same time as, or after the related transportation plan.

Table 5 briefly compares the three options. If the architecture is updated before the MTP/LRSTP, then the plan can leverage information included in the updated architecture, but the architecture may not be consistent with the current plan since it was developed in advance. If the plan is updated before the architecture, there is exactly the opposite dynamic. The architecture will be consistent with the plan, but the plan will not be able to incorporate any information from an up-to-date architecture. This "chicken and egg" situation leads us to consider another option, which updates the architecture in parallel with the MTP/LRSTP update. This can be a viable approach because the typical architecture update requires 6 to 9 months of calendar time, which can be nested in the longer MTP/LRSTP update schedule. The question is whether or not the benefits of the parallel update justify the additional stress, potential schedule conflicts, and overlapping resource needs associated with the parallel development. The answer is dependent to some extent on the region. For example, the parallel development approach requires planning staff availability to support the parallel efforts.

Minor Architecture Update to Support the STIP/TIP

The most volatile part of the regional ITS architecture is the project sequencing, which changes frequently as current projects are implemented and new projects are identified. Establishing a good connection between the region's projects and the architecture as described in Section 4.1 can facilitate the architecture maintenance that is required. Minor project-oriented updates of the architecture should be implemented more frequently to align the architecture with programming activities. This update will be project-focused, ensuring that the list of projects identified by the architecture is consistent with the current set of projects programmed in the STIP/TIP. The Mid-Region Council of Governments (MRCOG) and New Mexico DOT have adopted the practice of releasing an "architecture addendum" with each TIP that focuses on updating the project sequencing and documenting the linkage between the regional ITS architecture and projects programmed in the TIP. These modest, focused updates are performed in-house, without consultant support. Figure 33 is an excerpt from the addendum document that shows the connection between TIP projects and market packages in the Albuquerque Metropolitan Planning Area (AMPA) regional ITS architecture. An additional column in the table, not shown here, provides expanded descriptions of each of the associated market packages.
Table 5: Architecture and Transportation Plan Update Scheduling Options.
Option Pros Cons

1. Architecture Updated In Parallel with MTP/LR STP

Timeline shows the Architecture is updated in parallel with MTP/LR STP

Consistent with Plan and Plan Leverages Architecture

Opportunity to base architecture on current regional goals and objectives (See Section 3.2).

Opportunity to incorporate archived data services/flows to support performance measures (See Section 3.8).

Opportunity to leverage overlapping activities like M&O strategy selection for the MTP/LRSTP with service selection in the architecture. (See Section 3.4).

Opportunity to reflect integration strategies, projects, and other outputs back into the MTP/LRSTP.

Resource and schedule demands of parallel activities.

Scheduling the parallel activities to take advantage of the connections can be a challenge.

2. Architecture Updated Before MTP/ LR STP

Timeline shows the Architecture is Updated Before MTP/LRSTP

Plan Leverages Architecture

Opportunity to review architecture services as an input to selection of M&O strategies. (See Section 3.4).

Opportunity to reflect integration strategies, projects, and other architecture outputs back into the MTP/LRSTP.

Architecture not based on the current plan.

3. Architecture Update After MTP/LR STP

Timeline shows the Architecture is Updated After the MTP/LR STP

Architecture Consistent with Plan

Opportunity to base architecture on current regional goals and objectives (See Section 3.2).

Opportunity to incorporate archived data services/flows to support performance measures (See Section 3.8).

Opportunity to review M&O strategies as an input to selection of architecture services. (See Section 3.4).

Plan developed without input from a current architecture.

Figure 33: Excerpt from AMPA Regional ITS Architecture Addendum.37
Screenshot of an ITS Architecture addendum. The addendum document shows the connection between TIP projects and market packages in the Albuquerque Metropolitan Planning Area (AMPA) regional ITS architecture. The excerpt shows table with projects named in the TIP, the TIP year, the lead agency, the recommended market packages in the regional architecture, and the agency-proposed project market packages.


31 Additional information about Turbo Architecture is available in Appendix A. [ Return to note 31. ]

32 Planning View is planned for inclusion in Version 7.0 of the National ITS Architecture. [ Return to note 32. ]

33 Image courtesy of the Mid-Region Council of Governments. [ Return to note 33. ]

34 Michigan Department of Transportation and Southeast Michigan Council of Governments, Regional ITS Deployment Plan, November 2008. Available at: http://www.mi.gov/documents/mdot/SEMCOG_Region_ITS_Deployment_Plan_271573_7.pdf, last access December 20, 2011. [ Return to note 34. ]

35 Virginia Department of Transportation, Northern Region Operations ITS Decision Support Tool. Available at: http://www.vdot-itsdst.com/, last accessed December 20, 2011. [ Return to note 35. ]

36 Virginia Department of Transportation, Northern Region Operations ITS Decision Support Tool. Available at http://www.vdot-itsdst.com/, last accessed December 20, 2011. [ Return to note 36. ]

37 Mid-Region Council of Governments, AMPA Regional ITS Architecture, Addendum Version 1.1, April 2009. Available at: http://nmrailrunner.com/PDF/TIP/AMPA%20Regional%20ITS%20Architecture%20Addendum%20v%2011fw.pdf, last accessed December 19, 2011. [ Return to note 37. ]

previous | next