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	Link strategies with service packages
Programs and Projects	Projects and the related subset of the regional ITS architecture: interfaces, functional requirements, etc.	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.

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:

• Determine the best connection point in the MTP/LRSTP. If your region has adopted the objectives-driven performance-based approach, then objectives and/or strategies are likely to be the best connection point(s). If this approach has not yet been adopted, then goals or policies or another plan component may be the most effective connection point, depending on how the MTP/LRSTP is structured in your region. Generally, you want to connect with the most detailed, discrete list of items included in the MTP/LRSTP that are traceable back to the regional goals.
• Similarly, identify the optimal connection point in the architecture. This connection point will also vary but most frequently will be either needs or services. Needs are an ideal connection point if they are a focus in your regional ITS architecture since they will be a basis for the services that are included in the architecture. If a good list of needs is not included in the architecture, then ITS Services are normally the best connection point as they are almost always well documented in the regional ITS architecture.
• Establish and document the connection. This means you need a table that links the selected planning component and architecture component. You can build this table of connections using the Turbo Architecture "Planning Tab"³¹ or alternatively, in another database application or tool. Note that you could also create a table in a word processor or publishing application, but such a table would be more difficult to maintain.
• Use the table to identify inconsistencies and needed changes. If you build the table in Turbo Architecture or another database application, then you can easily run queries or reports to identify disconnects (e.g., services not supported by objectives and objectives that have no supporting services) and more easily keep the table up to date as both the planning and architecture components evolve over time.
• Publish the table so that it is easy to follow the connections. Ideally, a user will be able to traverse the established connections. For example, the user should be able to move from a particular objective to the service(s) that support that objective. Similarly, a user should be able to navigate from a particular service to the objective(s) that the service supports. This structure adds organization to the regional ITS architecture "toolbox" of services since it effectively organizes the architecture by the goals and objectives that are important to the region. This capability lends itself to a web-based presentation, but it can also be achieved with a well-organized set of documentation that includes services sorted by goal and/or objective.

Figure 24: Connecting Objectives and Strategies with Needs and Services.

Figure 25: Connecting the STIP/TIP Projects with the Architecture.

Figure 26: MRCOG Regional ITS Infrastructure Geodatabase.33

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.³² 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).

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:

• Link to the projects in project sequencing. This approach makes it easy on the user since the user only has to find their project in the sequence. Assuming that each of the projects in the sequence also include a definition in terms of the regional ITS architecture, this approach will also yield an accurate initial scope for the project in architecture terms. Some regions specifically reference the projects listed in the STIP/TIP in the project sequencing documentation included in the regional ITS architecture. The challenge here is that not all regional ITS architectures define the projects in the project sequence in terms of their scope within the regional ITS architecture. For these regions, the user must directly access the regional ITS architecture to understand how their project fits in the region, effectively using approach 2.
• Link directly to the components of the regional ITS architecture that support the project. This approach requires the user to manually identify the subset of the regional ITS architecture related to the project. This activity is much easier if Turbo Architecture is used, but most regional ITS architecture users do not have Turbo installed and don't know how to use it. The benefit of this technique is that the user is required to look at the regional ITS architecture and make specific choices about how their project fits (e.g., should the interface to maintenance be included now or deferred to a future project). In approach 1, these choices are made as part of the regional ITS architecture (or ITS/operations plan) update.
• Link to the service (or services) that correspond to the ITS project. In this approach, the user combs through the service packages that are included in the regional ITS architecture. See Figure 28 in Section 4.3 for an example table that links STIP/TIP projects with regional ITS architecture service packages. Like approach 1, this is a fairly easy exercise for the user, who looks through a list to find the service that is the closest fit for his or her project. Assuming that the regional ITS architecture documentation includes a complete definition of each service, the user can use the service to access the relevant regional ITS architecture components for the project. The challenge is that the service will often not be a perfect fit for the project, requiring the user to tailor the list of regional ITS architecture components to match the anticipated scope of the project. As in approach 2, this tailoring effectively requires a project ITS architecture to be developed, although in this case, the service package provides a head start. This tailoring can be done by hand for a simple project; users will find that using Turbo Architecture greatly facilitates the work involved in tailoring more complex projects.

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.

• Provide links to resources. Every regional ITS architecture should include a list of resources like this primer and the Regional ITS Architecture Guidance Document as well as other resources specific to your region. If your regional ITS architecture includes additional background information, then consider packaging this information so that it can be easily referenced.
• Include a glossary of terms. The regional ITS architecture documentation will only communicate effectively if the users understand the terminology that is used. An acronym list and a glossary should be included in the documentation. It also helps to provide the definitions in context where possible. For on-line regional ITS architecture documentation, JavaScript can be used to provide definitions in a popup window so that a user can hover over an unfamiliar term and view a definition without leaving the current web page, as shown.
• Provide contact information for those with questions. Most regions have at least one or two individuals who can answer user questions about the regional ITS architecture. Provide contact information for those individuals as the last line of support for users.
• Include training with your next regional ITS architecture update. Many regions that hire a consultant to support a regional ITS architecture update also include training as part of the update. Training that is specific to your regional ITS architecture and regional planning and project development processes can be very helpful. Consider cost-effective ways to make the training available online. For example, webinars can be recorded and archived for future use.

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.

• Provide a roadmap. The architecture documentation should include a guide or roadmap to the architecture, preferably directed toward different types of users and anticipated uses of the architecture. For example, the roadmap might direct planners to linkages with the MTP/LRSTP, guide operations staff to documentation that presents the architecture by agency or system element, and point engineers/ project development staff toward project-oriented views of the architecture. Not only should the roadmap be featured prominently at the beginning of the architecture documentation, it should also be one of the first pieces of narrative that is outlined. Thinking about the roadmap early in the process will result in documentation that is better organized and more user-oriented. In your first draft of the roadmap, as you try to explain the user-friendly organization, you may find that it is not as friendly as it should be or does not fulfill all of the anticipated uses, suggesting overall changes that should be made in the architecture documentation.
• Segment the regional ITS architecture documentation into "views" for different types of users. This technique goes hand-in-hand with the roadmap. Most users are interested in a narrow subset of the architecture that is related to a particular stakeholder organization, inventory element, or service. Planners may be interested in a narrow subset most relevant to them and they may also be interested in top-level views that cover the breadth of the architecture in a user-friendly, approachable manner. Views are provided to facilitate use by different types of users. For example, the Minnesota Statewide ITS Architecture is segmented by service package bundle, grouping traveler information, traffic management, transit, commercial vehicle operations, public safety, and maintenance oriented portions of the architecture into separate volumes.
• Provide summary level information with the opportunity to "drill down" into the detail. It is good practice to provide summary level information and make the details available to the users that wish to delve into it. Most regional ITS architecture documents are structured so that the architecture is described at a relatively high-level in the body of the document and large tables of functional requirements and interfaces are relegated to appendices. In regional ITS architecture web pages, top-level pages provide a summary of each aspect of the architecture – stakeholders, inventory, services, etc. – with links to pages that provide more detail in each area.
• Provide Navigation Queues. With any complex web site or document, the user will benefit from navigation queues that help the user keep track of where they are in the material. This is particularly true of regional ITS architecture web sites where pages of service packages, projects, and inventory can all look very similar to the uninitiated. Web site navigation queues include highlighted menu entries and navigation breadcrumbs – the hyperlinks at the top of many web pages that show the path from the home page to the current web page (e.g., Home > Roadmap > Find My Project). For documents, including the current chapter information in each page header will suffice.

Planner Friendly Content

• Provide summary level graphics suitable for executive summaries/presentations. Many regions have recognized that the regional ITS architecture benefits from "executive summary" level descriptions and graphics that present the integration opportunities identified in the architecture in an accessible way. These graphics can be used in the architecture documentation and included in higher level documents such as the MTP/LRSTP that will be read by many who are unfamiliar with ITS architecture.
• Provide a planning view, including links to the MTP/LRSTP. An architecture view that is oriented towards planners would include access to: 1) the architecture organized by the objectives/strategies in the metropolitan/statewide Transportation Plan, 2) the architecture organized by project to facilitate use in evaluating project applications, and 3) the portion of the regional ITS architecture that supports data collection, performance monitoring, and any other interfaces that are of central interest to the planners in the region.

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.

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

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.³⁴

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.³⁵

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 ³⁶

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.

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.

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	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	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	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.³⁷